DerAndere1 / Marlin

Optimized firmware for RepRap 3D printers based on the Arduino platform. The branch Marlin2ForPipetBot is optimized firmware for cartesian robots (lab robots, also known as liquid handling robots or pipetting robots)
https://derandere.gitlab.io/pipetbot-a8
GNU General Public License v3.0
53 stars 20 forks source link

G29 Bed Leveling Error #44

Closed HendrikJan-5D closed 3 years ago

HendrikJan-5D commented 3 years ago

Description

Steps to Reproduce

  1. [First Step]
  2. [Second Step]
  3. [and so on...]

Expected behavior: [What you expect to happen]

Actual behavior: [What actually happens]

Additional Information

HendrikJan-5D commented 3 years ago

Hello,

I am new to this forum.

As a member of 3d.hcc.nl , a hobby club of members who are involved in 3d printing, 3d scanning, cad software (fusion 360). I am involved in technical support and new developments in the 3d field. In the context of this I am building a 5 axis 3d printer. This can be done by turning and tilting the printhead, or by turning and tilting the bed.

Because I couldn't choose the best method, I decoder to built both in the 3d printer, which results in a 3d printer with 7 axes.

See https://youtu.be/rdrwuG2sWQU

All this is controlled by a BTT GTR V1.0 plus M5 V1.0 board with TMC2226 drivers and your custom Marlin-Marlin2ForPipetBot software for 6 axes. Many thanks for this!

Globally all 6 axes work, G28 also works well for all the 6 axes. But with G29 bed leveling I get the message that I have to Home first. With Marlin-bugfix-2.0.x, bed leveling works well. = ( 3 axes ) But with Marlin-Marlin2ForPipetBot it doesn't work, and I keep getting the message that I have to Home first. Can you help me to solve this problem

Kind regards, HendrikJan-5D

config files.zip

DerAndere1 commented 3 years ago

I just saw your message, thx for the report and the video (the first time I saw a 6 axis printer with my firmare, I use the firmare for different purposes.. congrats to your machine!). The most advanced branch is https://github.com/DerAndere1/Marlin/tree/6axis_PR1 but even there, G29 is probably still broken as it is still an open feature request. To test it, you have to use the default config files from that branch and adjust them to your needs again. Configs from Marlin2ForPipetBot do not work for https://github.com/DerAndere1/Marlin/tree/6axis_PR1 . No guarantees that g29 works, though, I cannot test bed leveling in hardware, so it is very difficult for me to fix this problem. One user managed to make a very old version of Marlin-6axis work with G29, A link to that firmware can be found in the last comment of the discussion at https://github.com/DerAndere1/Marlin/issues/15 . I cannot give any support for that code, though. It will probably not work with your stepper drivers, Please feel encouraged to report issues related to https://github.com/DerAndere1/Marlin/tree/6axis_PR1 at https://github.com/DerAndere1/Marlin/issues . but I only have very limited resources to move this forward. Things that are working with 6-axis-Marlin are documented here: https://github.com/DerAndere1/Marlin/wiki . things not listed there are not tested yet. If you have no experience in C++ coding, you should consider using an alternative firmware that officially supports your board and drivers. . otherwise: G29 is handled in file Marlin/src/gcode/bedlevel/abl/G29.cpp . I will also have a closer look at that file.

DerAndere1 commented 3 years ago

In the video it looks as if the printer was homing, but X Y and Z still show non-zero values. Are you sure you issued a G28 command before G29?

HendrikJan-5D commented 3 years ago

Thank you for your response.

G28 homing is performed by all 6 axes. There must be a flag somewhere that he is ready. G29 is waiting for that flag before it can start.

I am now trying to configure Marlin-6-axis-dev. To see if G29 is working But run into a bug when choosing TMC2209 for I, J, and K

See also

https://github.com/MarlinFirmware/Marlin/pull/21618

HendrikJan-5D commented 3 years ago

Hello DerAndere

With Marlin2ForPipetBot I can home and control 6 axes (and 3D print) When I configure Marlin-6axis_PR1 it goes wrong if I choose TMC2209 for the axes I, J, K instead of A4988 The errors were caused by rewriting Marlin2ForPipetBot to Marlin-6axis_PR1 and are mainly in the files settings.cpp

1241 #if AXIS_HAS_STEALTHCHOP (I) 1242 tmc_stealth_enabled.I = stepperI.get_stealthChop_status (); 1243 #endif get_stored_stealthChop 1244 #if AXIS_HAS_STEALTHCHOP (J) 1245 tmc_stealth_enabled.J = stepperJ.get_stealthChop_status (); 1246 #endif get_stored_stealthChop 1247 #if AXIS_HAS_STEALTHCHOP (K) 1248 tmc_stealth_enabled.K = stepperK.get_stealthChop_status (); 1249 #endif get_stored_stealthChop

There are also some errors in trinamic.cpp

In pins_BTT_GTR_V1_0.h I corrected the following

36 #ifdef E2END 37 #undef E2END 38 #endif 39 #define E2END 0x1FFF // EEPROM end address 24C64 (64Kb = 8KB)

Can you have a look at the other compiling errors with my configuration.

config files 6axis_PR1.zip

DerAndere1 commented 3 years ago

Thanks for finding the bugs. I guess that fixing errors in Trinamic.cpp beyond getting rid of compile errors will be hard for me, because I do not have those drivers. I would happily accept a pull request. If you have a fixed trinamic.cpp file, you could alternatively attach a zip-compressed copy of the fixed file to a comment here. Off topic: I will get in touch with 3d.hcc.nl. Sounds fun.

HendrikJan-5D commented 3 years ago

DerAndere1 , Thanks for your reply. In the meantime I have spent many hours to get the software Marlin-6axis_PR1 working. What didn't work out. Do you know who rewritten Marlin-Marlin2ForPipetBot to Marlin-6axis_PR1. Because this caused errors with the TMC2209 drivers. Your Marlin-Marlin2ForPipetBot works with the TMC2209 drivers for the axes I, J, K.

I found errors from compiler data in the following files

Settings.ccp lines 1242, 1245, 1248, 3876, 3881, 3886, 3935, 3938, 3941 get_stored_stealthChop

trinamic.h Here I miss in several places CHOPPER_TIMING_I CHOPPER_TIMING_J CHOPPER_TIMING_K

trinamic.cpp Here I miss line 303

define I_HAS_HW_SERIAL 1

define I_HAS_SW_SERIAL 1

define J_HAS_HW_SERIAL 1

define J_HAS_SW_SERIAL 1

define K_HAS_HW_SERIAL 1

define K_HAS_SW_SERIAL 1

Conditionals_post.h from 1969 onwards

ifndef I_SLAVE_ADDRESS

#define I_SLAVE_ADDRESS 0

endif

ifndef J_SLAVE_ADDRESS

#define J_SLAVE_ADDRESS 0

endif

ifndef K_SLAVE_ADDRESS

#define K_SLAVE_ADDRESS 0

endif

Errors may also have arisen because a SanityCheck has been added.

I will send You a configured working software folder Marlin-Marlin2ForPipetBot.

And a configured non-working software folder Marlin-6axis_PR1. if you change the drivers from I, J, K A4988 to TMC2209 it will go wrong.

Would you take a look at this.

config-Marlin-6axis_PR1.zip config-Marlin-Marlin2ForPipetBot.zip

DerAndere1 commented 3 years ago

Thx for looking closer into this. I just added commit https://github.com/DerAndere1/Marlin/commit/b26ef9ca3ee7e573a5a63ff9906f27a5723e3058 to the 6axis_PR1 branch that should fix the sections you mentioned. I will test-compile with your configs in the next days and fix remaining errors.

DerAndere1 commented 3 years ago

thinkyhead added commit https://github.com/MarlinFirmware/Marlin/commit/54ddd6f4621d069400c298ad9cb1b18bda4b9078 that might fix G29. Could you test in hardware?

HendrikJan-5D commented 3 years ago

I am going to reconfigure and test the modified Marlin-6axis_PR1 on my printer.

HendrikJan-5D commented 3 years ago

The last Marlin-6axis_PR1 reconfigured. Version 02000801

Made changes in pins_BTT_GTR_V1_0.h compiler errors Fixed errors in setting.cpp. Remains a notification in settings.ccp ????

firmware.bin loaded in the printer.

M122 S0 stepper info for X Y Z A B C E = ok Home X Y Z = ok Home A B C axis not working ???? G1 A10 B10 C10 works G29 returns with Home First error

I will send you the complete configured files

Marlin-6axis_PR1 test.zip

problem message after compiling

"resource": "/d:/Marlin-6axis_PR1 test/Marlin/src/module/settings.cpp",
"message": "iteration 3 invokes undefined behavior [-Waggressive-loop-optimizations]",
"startLineNumber": 2779,

2779 LOOP_LINEAR_AXES(a) probe.offset[a] = dpo[a]; // [ a ] gives problem notification ??????????

See changes below

corrected rules in settings.cpp

3906 const bool chop_i = stepperI.get_stored_stealthChop(); 3911 const bool chop_j = stepperJ.get_stored_stealthChop(); 3916 const bool chop_k = stepperK.get_stored_stealthChop(); 3965 if (stepperI.get_stored_stealthChop()) { say_M569(forReplay, SP_I_STR, true); } 3968 if (stepperJ.get_stored_stealthChop()) { say_M569(forReplay, SP_J_STR, true); } 3971 if (stepperK.get_stored_stealthChop()) { say_M569(forReplay, SP_K_STR, true); }

corrected rules in pins_BTT_GTR_V1_0.h

36 #ifdef E2END 37 #undef E2END 38 #endif 39 #define E2END 0x1FFF // EEPRO end adress 24C64 ( 64Kb = 8KB )

58 #define SOL1_PIN PH6 // changed from PS_ON_PIN

114 #define I_STOP_PIN PI4 // M5 M1_STOP 116 #define J_STOP_PIN PF4 // M5 M2_STOP 118 #define K_STOP_PIN PF6 // M5 M3_STOP

172 #define I_STEP_PIN PF3 173 #define I_DIR_PIN PG3 174 #define I_ENABLE_PIN PF8 175 #ifndef I_CS_PIN 176 #define I_CS_PIN PG4 177 #endif

179 #define J_STEP_PIN PD14 180 #define J_DIR_PIN PD11 181 #define J_ENABLE_PIN PG2 182 #ifndef J_CS_PIN 183 #define J_CS_PIN PE15 184 #endif

186 #define K_STEP_PIN PE12 187 #define K_DIR_PIN PE10 188 #define K_ENABLE_PIN PF14 189 #ifndef K_CS_PIN 190 #define K_CS_PIN PE7 191 #endif

267 #if ENABLED(M5_EXTENDER) 268 #define I_SERIAL_TX_PIN PG4 269 #define I_SERIAL_RX_PIN PG4

271 #define J_SERIAL_TX_PIN PE15 272 #define J_SERIAL_RX_PIN PE15

274 #define K_SERIAL_TX_PIN PE7 275 #define K_SERIAL_RX_PIN PE7

DerAndere1 commented 3 years ago

Thx. I am currently applying the changes to settngs.cpp. I do not like to mess around with board-specific pin files in the PR1 branch yet. Are the following changes specific to the PR1 branch or should the same changes be applied to upstream MarlinFirmware/Marlin, independent of 6xis support?

36 #ifdef E2END
37 #undef E2END
38 #endif
39 #define E2END 0x1FFF // EEPRO end adress 24C64 ( 64Kb = 8KB )

58 #define SOL1_PIN PH6 // changed from PS_ON_PIN
DerAndere1 commented 3 years ago

2779 LOOP_LINEAR_AXES(a) probe.offset[a] = dpo[a]; // [ a ] gives problem notification ??????????

I currently try the following workaround (untested): settings.cpp change line 2775 - 2783 to:

  #if HAS_BED_PROBE
    constexpr float dpo[] = NOZZLE_TO_PROBE_OFFSET;
    static_assert(COUNT(dpo) == LINEAR_AXES, "NOZZLE_TO_PROBE_OFFSET must contain offsets for each linear axis X, Y, Z,....");
    #if HAS_PROBE_XY_OFFSET
      LOOP_LINEAR_AXES(a) probe.offset[a] = dpo[a];
    #else
      probe.offset.set(LIST_N(LINEAR_AXES, 0, 0, dpo[Z_AXIS]), 0, 0, 0));
    #endif
  #endif

With this change, in your configuratiion.adv you need to add some zeros to the following array. E.g. if you use LINEAR_AXES 6, change to 1141 #define NOZZLE_TO_PROBE_OFFSET { 10, 10, 0, 0, 0, 0 }

I have no idea how bed probing should behave with LINEAR_AXES >= 4. Any suggestions? does it actually need to add an offset to positions of I, J, K axes? or is a fixed I-/J-/K-offset of 0 okay for all machines?

HendrikJan-5D commented 3 years ago

36 #ifdef E2END 37 #undef E2END 38 #endif 39 #define E2END 0x1FFF // EEPRO end adress 24C64 ( 64Kb = 8KB )

I got this information from the BIGTREETECH service team. and has to do with the EEprom size on the motherboard BTT GTR V1.0

58 #define SOL1_PIN PH6 // changed from PS_ON_PIN

Here you should be able to choose between a SOL1_PIN PH6 or PS_ON_PIN PH6

In Configuration.h line

1135 # NOZZEL_TOPROBE OFFSET {10, -2, 2}.

This has nothing to do with how many axles you use. This indicates the position difference between the nozzle and the probe. relative to the bed

HendrikJan-5D commented 3 years ago

Do you have any idea why I can not Home Axes A ,B ,and C

DerAndere1 commented 3 years ago

I just added some commits to 6axis_PR1 that fixed homing of A, B, and C for me. You should be able to copy and paste your last config into the current 6axis_PR1 code

DerAndere1 commented 3 years ago

Regarding the EEPROM size: What is the main symtom/error if you keep in your pins_BTT_GTR_V1_0.h file the old

#define MARLIN_EEPROM_SIZE                0x2000  // 8KB (24C64 ... 64Kb = 8KB)

? In case that causes any actual symptoms, please open a bug report at https://github.com/MarlinFirmware/Marlin/issues/

HendrikJan-5D commented 3 years ago

I got an error message related to the EEPROM version. In some versions it was already adjusted in pins_BTT_GTR_V1_0.h This information comes from the manufacturer BigTreeTech. I think it makes sense for the other configurations too. But have no experience opening a bug report.

I will test whether the homing now works with A, B, and C.

DerAndere1 commented 3 years ago

I opened a bug report at https://github.com/MarlinFirmware/Marlin/issues/21977 . If you like you can post a comment in that discussion and provide a config for latest upstream Marlin bugfix-2.0.x that reproduces the EEPROM error.

DerAndere1 commented 3 years ago

The current 6axis_PR1 is probably broken again but I provide a link to the 6axis_PR1 branch at the time of commit https://github.com/DerAndere1/Marlin/tree/2c232728ae4e80d34c7a88695f38248a8c2d0dc8 where G28 was supposed to work

HendrikJan-5D commented 3 years ago

I have copy and paste my last config files

configuration.h configuration_adv.h pins_BTT_GTR_V1_0.h

into the current 6axis_PR1 code

And then I got an Error related on my EEprom size change. removed it in pins_BTT_GTR_V1_0.h

Furthermore, I got an error regarding your changed in the BED PROBE OFFZET problem

In settings.cpp

Lines 2632 to 2640

if HAS_BED_PROBE

constexpr float dpo[] = NOZZLE_TO_PROBE_OFFSET;
static_assert(COUNT(dpo) == LINEAR_AXES, "NOZZLE_TO_PROBE_OFFSET must contain offsets for each linear axis X, Y, Z....");
#if HAS_PROBE_XY_OFFSET
  LOOP_LINEAR_AXES(a) probe.offset[a] = dpo[a];
#else
  probe.offset.set(LINEAR_AXIS_LIST(0, 0, dpo[Z_AXIS], 0, 0, 0));
#endif

endif

This has to do with line 1135 of configuration.h

define NOZZLE_TO_PROBE_OFFSET {10, -20, 2}

Which blocks further compilation

'LOOP_XYZ' was not declared in this scope identifier "LOOP_XYZ" is undefined "message": "'a' was not declared in this scope", "message": "identifier \"a\" is undefined", "message": "expected a ';'",

DerAndere1 commented 3 years ago

You last issues are expected. Currently you have to extend the array NOZZLE_TO_PROBE_OFFSET in Configuration.h with elements of vallue 0 for each extra axis. E.g. when you have LINEAR_AXES 6, then it must be of the form

#define NOZZLE_TO_PROBE_OFFSET { 10, -20, 2, 0, 0, 0 }

Regarding EEPROM size change: Can you test, if it works without the change to E2END 0x1FFF in your adapted pins_BTT_GTR_1_0.h file if you send M502 followed by M500 after uploading the new firmware version ?

HendrikJan-5D commented 3 years ago

I followed your advice.

no more compiler errors

M502 SENDING: M502 echo: Hardcoded Default Settings Loaded M500 SENDING:M500 echo:Settings Stored (900 bytes; crc 48770) M503 SENDING: M503

G28 homing for all axes work G29 bed leveling works.

I need to do more tests to see if everything works. But it looks good.

Thanks for the help and support.

Is there a possibility to add an extra axle? Then I can also rotate the printer bed.

To be continued, We'll keep in touch.

DerAndere1 commented 3 years ago

The prescribed sequence of uploading Marlin, then sending M502 followed by M500 is documented on the Marlin homepage, at the beginning of section Configure/Configuration.h as well as under section Install/Troubleshooting/EEPROM errors

DerAndere1 commented 3 years ago

Support for up to 8 linear axes (later 9 or even 10) plus extruder is just ready for testing since some hours. For the progress, see https://github.com/DerAndere1/Marlin/pulls . You can download, configure and compile the firmware from branch 9axis_pull (https://github.com/DerAndere1/Marlin/tree/9axis_pull). I still exprect compile errors though.

HendrikJan-5D commented 3 years ago

DerAnder1

I configured Marlin-9axis_pull for 7 axes And get a compile error.

SanityCheck.h Marlin\src\inc macro "GANG_7" requires 8 arguments, but only 6 given

SanityCheck.h 571 constexpr float sbm[] = AXIS_RELATIVE_MODES; 572 static_asset(COUNT(sbm) == LOGICAL_AXES, "AXIS_RELATIVE_MODES must contain " _LOGICAL_AXES_STR "elements.");

This has to do with

Configuration_adv.h 912 #define AXIS_RELATIVE_MODES { false, false, false, false, false, false, false, false }

including all configured Marlin-9axis_pull files

Marlin-9axis_pull test.zip

HendrikJan-5D commented 3 years ago

When further testing Marlin-6axis_RP1 I run into the following problem. G28 home all axes G1 works for all axes G29 bed leveling works M503 indicates that M420 S0 has now become M420 S1 G1 no longer works for all axes this can be solved by M502 M500 G28 home Now I can operate all axes again

In summary: after performing a bed leveling all axes are blocked by something written in the EEPROM

DerAndere1 commented 3 years ago

Thanks for narrowing down the isse. It would be great to see logging data from the leveling. To get it, please enable DEBUG_LEVELING_FEATURE in Configuration.h, then make sure that you send M502, followed by M500 directly after uploading your configured firmware. Use a host software to send G-code to the printer via USB. Send M111 S38. Verify that the serial monitor of the host software is configured so that you can see all info and errors that are sent from the 3D printer. Then do your bed leveling / homing routine and again test G1 for all axes. Finally, please copy the logging data from the serial monitor of your host software and attach it here. By the way, I fixed compilation with LINEAR AXES 7 in branch 9axis_pull, I tested compilation with your configs.

HendrikJan-5D commented 3 years ago

After looking at the first log data I saw that the z probe offset was wrong . I made some changes in Configuration.h. 1135 #define NOZZLE_TO_PROBE_OFFSET { 10,-20, -2, 0, 0, 0 } was ( { 10, -20, 2, 0, 0 ,0}) 1330 #define Z_MIN_POS -5 ( was 0 ) 1333 #define Z_MAX_POS 257 ( was 253.90 ) This had no influence on the blocking of the X , Y and Z axis after bed leveling.

See info at the logging file

Regarding 9axis_pull error In which file did you make the corrections?

log file.zip

HendrikJan-5D commented 3 years ago

Here is some additional information. After M502

M502 SENDING:M502 reset_bed_level current_position= X0.00 Y0.00 Z10.00 A20.00 B5.00 C2.00 : Leveling ON current_position= X0.00 Y0.00 Z0.00 A20.00 B5.00 C2.00 : ...Now OFF current_position= X0.00 Y0.00 Z0.00 A20.00 B5.00 C2.00 : sync_plan_position Axis X home_offset = 0.00 position_shift = 0.00 Axis X min:-173.00 max:220.00 Axis Y home_offset = 0.00 position_shift = 0.00 Axis Y min:-217.00 max:220.00 Axis Z home_offset = 0.00 position_shift = 0.00 Axis Z min:-5.00 max:257.00 Axis A home_offset = 0.00 position_shift = 0.00 Axis A min:0.00 max:90.00 Axis B home_offset = 0.00 position_shift = 0.00 Axis B min:0.00 max:90.00 Axis C home_offset = 0.00 position_shift = 0.00 Axis C min:0.00 max:90.00 echo:Hardcoded Default Settings Loaded

DerAndere1 commented 3 years ago

One batch of changes to make 7 axes compile in 9axis_pull was this commit https://github.com/DerAndere1/Marlin/pull/49/commits/638ccdda65736a771a1a404372d1873d05ee9bb7, you see multiple files changed, indicated by the colors

DerAndere1 commented 3 years ago

Code for up to 6 axes was now merged into official MarlinFirmware/Marlin bugfix-2.0.x. I identified a hidden bug that was fixed in MarlinFirmware/Marlin bugfix 2.0.x . Wait until PR 22056 "Fix compilation after 6axis merge" was also merged into MarlinFirmware/Marlin or wait until I add the fix to the 9axis_pull branch. I will inform you when its ready.

HendrikJan-5D commented 3 years ago

I had downloaded the latest version of Marlin-9axis_pull this morning. I copied my previously configured files into this And found the following problems.

serial.cpp 118 LIST_N(DOUBLE(LINEAR_AXES), SP_X_STR, x, SP_Y_STR, y, SP_Z_STR, z, SP_I_STR, i, SP_J_STR, j, SP_K_STR, k, SP_M_STR, m, SP_O_STR, o, SP_P_STR, p, SP_Q_STR, q)) ) ; The last ) must be removed

motion.cpp 665 void do_blocking_move_to_xyzijkm_o(const xyze_pos_t &raw, const_float_t o, const_feedRate_t fr_mm_s/=0.0f/) { Should be I think xyzijk_m

I derived this from the structure of the other axes

but there are even more compile errors in it

DerAndere1 commented 3 years ago

I must have forgotten to copy those changes from my local test branch to the 9axis_pull branch. When I change motion.cpp line 665 to

void do_blocking_move_to_xyzijk_m(const xyze_pos_t &raw, const_float_t m, const_feedRate_t fr_mm_s/=0.0f/) {

it compiles. This is now fixed in branch 9axis_pull. In case it does not compile for you, try PlatformIO -> Project Tasks -> Default -> General -> Clean All, then build again. Dont forget to use your own platformio.ini, Configuration.h, Configuration_adv.h and pins_BTT_GTR_V1_0.h files

HendrikJan-5D commented 3 years ago

I have reconfigured the latest version Marlin-6axis_PR1 02000900 And am running into a compiler error.

planner.ccp

"message": "expected a ')'", "startLineNumber": 1454, "startColumn": 11,

"message": "expected ')' before 'block'", "startLineNumber": 1454, "startColumn": 82,

"message": "label \"block\" was referenced but not defined", "startLineNumber": 2027, "startColumn": 10,

1451 float high = 0.0; 1452 for (uint8_t b = block_buffer_tail; b != block_buffer_head; b = next_block_index(b)) { 1453 block_t block = &block_buffer[b]; 1454 if (LINEAR_AXIS_GANG(block->steps.x, || block->steps.y, || block->steps.z, block->steps.i, || block->steps.j, || block->steps.k)) { 1455 const float se = (float)block->steps.e / block->step_event_count SQRT(block->nominal_speed_sqr); // mm/sec; 1456 NOLESS(high, se); 1457 }

2027 && block->steps.b < MIN_STEPS_PER_SEGMENT,

Marlin-6axis_PR1 test 3.zip

HendrikJan-5D commented 3 years ago

Hardware Test Report

I tested the latest version Marlin-9axis_pull on the 7th axis.

Copied from the previous test version. configuration.h configuration-adv.h pins_BTT_GTR_V1_0

No compile errors.

7th axis no end stop 7th axis cannot homen 7th axis can rotate The bed leveling is blocked by not being able to home the 7th axis

See further information in the test report.

Test report 7e axis.zip

Marlin-9axis_pull test 3.zip

HendrikJan-5D commented 3 years ago

Marlin-9axis_pull

I see differences between axis 4,5,6 and axis 7

Conditionals_post.h

341 #if LINEAR_AXES >= 6 342 #ifdef MANUAL_K_HOME_POS 343 #define K_HOME_POS MANUAL_K_HOME_POS 344 #else 345 #define K_HOME_POS TERN(K_HOME_TO_MIN, K_MIN_POS, K_MAX_POS) 346 #endif 347 #endif 348 #if LINEAR_AXES >= 7 349 #ifdef MANUAL_M_HOME_POS 350 #define M_HOME_POS MANUAL_M_HOME_POS 351 #else 352 #define M_HOME_POS (M_HOME_DIR < 0 ? M_MIN_POS : M_MAX_POS) 353 #endif 354 #endif

DerAndere1 commented 3 years ago

Thanks for the reports and for having a look at the code. Line 345 uses a macro which expands to the same logic as the ternary operator used in line 352. So the logic is functionally equivalent for both axes. I will update the mentioned line anyway whenever I find the time to have a look at the 7th axis homing code. Won't happen this week i guess.

DerAndere1 commented 3 years ago

The bed leveling bug that broke axis movement after G29 is now fixed in upstream MarlinFirmware/Marlin bugfix 2.0.x.

HendrikJan-5D commented 3 years ago

Thanks. I'm going to reconfigure it. And test with the printer.

HendrikJan-5D commented 3 years ago

Hello DerAndere1,

I completely reconfigured Marlin bugfix 2.0 on 22-07-2021. But the bed leveling problem has not been solved. After bed leveling, the axes X , Y and Z are locked. The axes A , B and C can be operated. I made a log file of the whole test. And also send the complete configured software

test Marlin-bugfix-2.0.x.zip

logfile Marlin bugfix 2.0 bed leveling problem.zip

HendrikJan-5D commented 3 years ago

I did some additional testing. As for the bed leveling problem G29. I have completely reconfigured Marlin-bugfix-2.0.x only for the 3 axes. Even without the I , J and K axis it goes wrong after bed leveling. And the axes X , Y and Z are also blocked.

DerAndere1 commented 3 years ago

Then I would do the following things: i. Save you current configs for Marlin bugfix-2.0.x with LINEAR_AXES 3. ii. Verify that you have obtained official Marlin bugfix-2.0.x from upstream: https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x after 30th July 2021. iii. Follow these steps again:

    1. Enable DEBUG_LEVELING_FEATURE and M114_DETAIL and re-flash the firmware.
    2. Connect to your printer from host software such as Cura, Printrun or Repetier Host.
    3. Send M502 and M500 to ensure your Configurations are applied.
    4. Issue the command M111 S247 to enable maximum logging.
    5. Perform a G28 to do your standard homing procedure.
    6. Do a G29 to probe the bed. This will also enable bed leveling.
    7. Do some of the moves that revealed problems before. Take notes.
    8. Copy the log output into a .TXT file.

v. Test Marlin 2.0.7.2 (only 3 axes) and check, if axes X, Y and Z behave as expected during homing, bed leveling and G1 moves. vi. If the bug does not occur with version 2.0.7.2, we can exclude a problem in your hardware or configuration. In this case, open a bug report upstream at https://github.com/MarlinFirmware/Marlin/issues and fill in all requested data, including your configs from step i) and the log file from step iii.8. At the end of you report you should mention that with LINEAR_AXES 6, axes X, Y and Z are blocked while axes I, J, K can be moved with G1

HendrikJan-5D commented 3 years ago

DerAndere1

I have found and solved the bed level problem. My print bed is round it can tilt and turn. I use the bed leveling to measure whether the bed is inlevel and horizontal. Mechanically,the bed is perfectly level in the X direction. That is also the direction the bed tilts. So it is only important to measure in the Y direction whether the bed is leveld. I did this with 3 measuring points in a line. And here it goes wrong. The firmware cannot handle these values. I have now configured the 3 measuring points in a triangle. And all 6 axes can now be used.

You are never too old to learn something. ( 75 years )

I will now proceed to test Marlin-9axis_pull for the 7th axis. Has there been any progress since my last test report ?

If desired, I can also test an 8th axis later. I still have a separate linear axis that I can connect to the motherboard.

Thanks for the support.

HendrikJan-5D commented 3 years ago

I did some additional research at Marlin-9axis_pull. And found 2 files where I had doubts. Would you also like to check this out.

Marlin > src > inc > conditionals_post.h

At line 352, the code is different from line 345.

341 #if LINEAR_AXES >= 6 342 #ifdef MANUAL_K_HOME_POS 343 #define K_HOME_POS MANUAL_K_HOME_POS 344 #else 345 #define K_HOME_POS TERN(K_HOME_TO_MIN, K_MIN_POS, K_MAX_POS) 346 #endif 347 #endif 348 #if LINEAR_AXES >= 7 349 #ifdef MANUAL_M_HOME_POS 350 #define M_HOME_POS MANUAL_M_HOME_POS 351 #else 352 #define M_HOME_POS (M_HOME_DIR < 0 ? M_MIN_POS : M_MAX_POS) 353 #endif

Marlin > src > module > planner_bezier.cpp

From line 191 I also expect

 interp(position.m, target.m, t)
 interp(position.o, target.o, t)
 interp(position.p, target.p, t)
 interp(position.q, target.q, t)

188 interp(position.z, target.z, t),
189 interp(position.i, target.i, t),
190 interp(position.j, target.j, t),
191 interp(position.k, target.k, t)

DerAndere1 commented 3 years ago

Great that you solved the problem for 6 axes. I wanted to file a bug report at MarlinFirmware/Marlin to request documentation that AUTO_BED_LEVELING_3POINT does not work if all three points lie in a straight line, but then I found that it is already documented in Configuration.h, lines 1500 - 1501:

 * - AUTO_BED_LEVELING_3POINT
 *   Probe 3 arbitrary points on the bed (that aren't collinear)

Regarding 9 axis code: The line for the 7th axis still uses standard C++ syntax (ternary operator)

#define M_HOME_POS (M_HOME_DIR < 0 ? M_MIN_POS : M_MAX_POS)

The code for the other axes was refactored using a macro. The above line can be rewritten as

#define M_HOME_POS TERN(M_HOME_TO_MIN, M_MIN_POS, M_MAX_POS)

without change in functionality.

 interp(position.m, target.m, t)
 interp(position.o, target.o, t)
 interp(position.p, target.p, t)
 interp(position.q, target.q, t)

looks like these lines were indeed forgotten. Thanks!

HendrikJan-5D commented 3 years ago

The concept (that aren't collinear) from English to Dutch, was not clear to me that these 3 points should not lie on a line

HendrikJan-5D commented 3 years ago

Hi DerAndere. I made a video to show you the hardware test of 6 Axes Marlin-bugfix-2.0.x Version 02000901

https://youtu.be/7ZiCtQBDt-0

HendrikJan-5D commented 3 years ago

Marlin-9axis_pull

I have resolved the issues I previously reported.

Controlling and reporting the 7th axis works.

Marlin>src>pins>pins_postprocess.h

490 #if LINEAR_AXES >= 7 491 #ifdef M_STOP_PIN 492 #if O_HOME_TO_MIN <---------------------> O must be M 493 #define M_MIN_PIN M_STOP_PIN 494 #define M_MAX_PIN -1 495 #else 496 #define M_MIN_PIN -1 497 #define M_MAX_PIN M_STOP_PIN 498 #endif 499 #endif 500#endif

Marlin>src>feature>tmc_util.ccp

942 // #if AXIS_IS_TMC(M) 943 // if (print_m) tmc_parse_drv_status(stepperM, i); 944 // #endif 945 // #if AXIS_IS_TMC(O) 946 // if (print_o) tmc_parse_drv_status(stepperO, i); 947 // #endif 948 // #if AXIS_IS_TMC(P) 949 // if (print_p) tmc_parse_drv_status(stepperP, i); 950 // #endif 951 // #if AXIS_IS_TMC(Q) 952 // if (print_q) tmc_parse_drv_status(stepperQ, i); 953 // #end

This code occurs 2x and gives printout errors at ( M122 S0 )

I want to test everything even more extensively. But at first , everything seems to work.

DerAndere1 commented 3 years ago

This is fantastic!!! Thanks for the energy and time you invested in fixing these issues. I commited your proposed changes to my 9axis_pull branch. I will close this issue as fixed. Whenever you find new problems, you can open a new, dedicated report at https://github.com/DerAndere1/Marlin/issues (you can keep the bug report short). I expect more problems, but those should be discussed seperately.

Watching your video of the 6 axis test run was really satisfying. The next big step is rebasing my 9axis_pull branch onto current upstream MarlinFirmware/Marlin/bugfix-2.0.x , anyone who is good at resolving merge conflicts is welcome to help out with that task.