IDEX Tool Change - T1 Crash into T0

[nichols89ben]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

On an IDEX set up, after switching active extruder from T0 to T1, T0 parks to the endstop, but mumps out a few mm from the max, taking some space away from T1. If the tool is changed back to T0 while set as T1, it causes T1 to try and park (presumably) at the T0 position, causing T1 to crash into T0. I

Bug Timeline

Year +, Noticed it on stock SV04 firmware, coudnt pin it down

Expected behavior

T1 park at the X2 Max position, When T0 or T1 parks, it parks at the max and doesnt bump out a few mm

Actual behavior

T1 crashes into T0

Steps to Reproduce

Home T0
Set T1
Set tool to T0

Version of Marlin Firmware

bugfix-2.1.x 2024-03-25

Printer model

SV04 Modified

Electronics

BTT Octopus V1.1

LCD/Controller

BTT

Other add-ons

No response

Bed Leveling

ABL Bilinear mesh

Your Slicer

Cura

Host Software

OctoPrint

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

Debug output during movements/collision bellow, video of the movements on the google drive link. In the video, the steps are G28, T1 (T0 parks and bumps out), set tool back to T0
Archive.zip

https://drive.google.com/file/d/1s2DzKM3vYhYLTyX_1aTZmSLBmtcjejQs/view?usp=sharing

Set Tool 1

Send: T1
Recv: echo:T1
Recv: >>> T  X161.3000 Y133.2000 Z13.5000
Recv: ...(1)
Recv: Axis X min:25.0000 max:365.0000
Recv:  T:161.70 /0.00 B:55.61 /0.00 T0:161.70 /0.00 T1:159.84 /0.00 @:0 B@:0 @0:0 @1:0
Recv: X:29.0625 Y:133.2000 Z:13.5000 E:0.0000 Count X:1859 Y:10656 Z:5400
Recv: >>> set_axis_is_at_home(X)
Recv:   current_position= X365.0000 Y133.2000 Z13.5000 : sync_plan_position
Recv: do_blocking_move_to_z(13.5000, 5.0000)
Recv: >>> do_blocking_move_to  X365.0000 Y133.2000 Z13.5000
Recv: >  X365.0000 Y133.2000 Z13.5000
Recv: <<< do_blocking_move_to  X365.0000 Y133.2000 Z13.5000
Recv: Active Extruder: 1
Recv: <<< T  X365.0000 Y133.2000 Z13.5000
Recv: ok
Recv:  T:158.59 /0.00 B:55.53 /0.00 T0:160.43 /0.00 T1:158.59 /0.00 @:0 B@:0 @0:0 @1:0
Recv:  T:157.15 /0.00 B:55.40 /0.00 T0:159.05 /0.00 T1:157.15 /0.00 @:0 B@:0 @0:0 @1:0
Recv: X:365.0000 Y:133.2000 Z:13.5000 E:0.0000 Count X:23360 Y:10656 Z:5400
Recv:  T:155.87 /0.00 B:55.34 /0.00 T0:157.78 /0.00 T1:155.87 /0.00 @:0 B@:0 @0:0 @1:0
Recv:  T:154.42 /0.00 B:55.22 /0.00 T0:156.38 /0.00 T1:154.42 /0.00 @:0 B@:0 @0:0 @1:0
Recv:  T:153.02 /0.00 B:55.11 /0.00 T0:155.00 /0.00 T1:153.02 /0.00 @:0 B@:0 @0:0 @1:0
Recv: X:365.0000 Y:133.2000 Z:13.5000 E:0.0000 Count X:23360 Y:10656 Z:5400
Recv:  T:151.68 /0.00 B:55.02 /0.00 T0:153.71 /0.00 T1:151.68 /0.00 @:0 B@:0 @0:0 @1:0
Recv:  T:150.23 /0.00 B:54.91 /0.00 T0:152.34 /0.00 T1:150.23 /0.00 @:0 B@:0 @0:0 @1:0
Recv: X:365.0000 Y:133.2000 Z:13.5000 E:0.0000 Count X:23360 Y:10656 Z:5400
Recv:  T:149.07 /0.00 B:54.82 /0.00 T0:151.02 /0.00 T1:149.07 /0.00 @:0 B@:0 @0:0 @1:0
Recv:  T:147.93 /0.00 B:54.70 /0.00 T0:149.68 /0.00 T1:147.93 /0.00 @:0 B@:0 @0:0 @1:0

Set Tool 0 - Crash

Send: T0
Recv: echo:T0
Recv: >>> T  X365.0000 Y133.2000 Z13.5000
Recv: ...(0)
Recv: Axis X min:-55.0000 max:288.0000
Recv:  T:116.46 /0.00 B:52.11 /0.00 T0:118.39 /0.00 T1:116.46 /0.00 @:0 B@:0 @0:0 @1:0
Recv: X:168.0000 Y:133.2000 Z:13.5000 E:0.0000 Count X:10751 Y:10656 Z:5400
Recv:  T:115.53 /0.00 B:52.02 /0.00 T0:117.48 /0.00 T1:115.53 /0.00 @:0 B@:0 @0:0 @1:0
Unexpected error while reading serial port, please consult octoprint.log for details: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:4081
Please see https://faq.octoprint.org/serialerror for possible reasons of this.
Changing monitoring state from "Operational" to "Offline after error"
Connection closed, closing down monitor

[nichols89ben]

For some additional context, if anyone happens to see this. Here is the debug output with these additional options. From what I can tell, theres nothing setitng wise telling X2 to park in X1. I let it crash into X1 and after a few skips, it zoomed (very fast) to X2 home, then running into the endstop and skipping some more (assuming due to it thinking its position was different)

#define DEBUG_DXC_MODE
#define DEBUG_ECHOLNPGM
#define DEBUG_TOOL_CHANGE

Set T0

Send: T0 D
echo:T0 D
>>> T  X161.3000 Y133.2000 Z13.4500
...(0)
Active Extruder: 0
<<< T  X161.3000 Y133.2000 Z13.4500
ok
X:161.2969 Y:133.2000 Z:13.4500 E:0.0000 Count X:10323 Y:10656 Z:5380
 
Set T1

Send: T1 D
echo:T1 D
>>> T  X161.3000 Y133.2000 Z13.4500
...(1)
Axis X min:25.0000 max:365.0000
Dual X Carriage Mode AUTO_PARK
MoveX to -51.3000
>>> set_axis_is_at_home(X)
  current_position= X365.0000 Y133.2000 Z13.4500 : New Extruder
Active extruder parked: yes
  current_position= X365.0000 Y133.2000 Z13.4500 : New extruder (parked)
Offset Tool XYZ by { 0.0000, 0.0000, 0.0000 }
  current_position= X365.0000 Y133.2000 Z13.4500 : sync_plan_position
Move back Z only
do_blocking_move_to_z(13.4500, 5.0000)
>>> do_blocking_move_to  X365.0000 Y133.2000 Z13.4500
>  X365.0000 Y133.2000 Z13.4500
<<< do_blocking_move_to  X365.0000 Y133.2000 Z13.4500
Active Extruder: 1
<<< T  X365.0000 Y133.2000 Z13.4500
X:365.0000 Y:133.2000 Z:13.4500 E:0.0000 Count X:23360 Y:10656 Z:5380

Set T0 again - Crash, first smashes into left X1 Carriage, then rapidly tries to move past X2 Max and crashes into 
endstop (maybe becasue it thought it was farther left)

Send: T0 D
echo:T0 D
>>> T  X365.0000 Y133.2000 Z13.4500
...(0)
Axis X min:-55.0000 max:288.0000
X:365.0000 Y:133.2000 Z:13.4500 E:0.0000 Count X:23360 Y:10656 Z:5380
echo:busy: processing
Dual X Carriage Mode AUTO_PARK
MoveX to 365.0000
X:-4.4062 Y:133.2000 Z:13.4500 E:0.0000 Count X:-277 Y:10656 Z:5380
>>> set_axis_is_at_home(X)
> home_offset[X] = 0.0000
  current_position= X-51.3000 Y133.2000 Z13.4500 :
<<< set_axis_is_at_home(X)
  current_position= X-51.3000 Y133.2000 Z13.4500 : New Extruder
Active extruder parked: yes
  current_position= X-51.3000 Y133.2000 Z13.4500 : New extruder (parked)
Offset Tool XYZ by { 0.0000, 0.0000, 0.0000 }
  current_position= X-51.3000 Y133.2000 Z13.4500 : sync_plan_position
Move back Z only
do_blocking_move_to_z(13.4500, 5.0000)
>>> do_blocking_move_to  X-51.3000 Y133.2000 Z13.4500
>  X-51.3000 Y133.2000 Z13.4500
<<< do_blocking_move_to  X-51.3000 Y133.2000 Z13.4500
Active Extruder: 0
<<< T  X-51.3000 Y133.2000 Z13.4500
X:-51.2969 Y:133.2000 Z:13.4500 E:0.0000 Count X:-3283 Y:10656 Z:5380

[InsanityAutomation]

Ill have to go through the config here to see what the trigger is. Ive got IDEX machines running a snapshot from 08-04-23 that does not exhibit this, so at a minimum its not a generic problem that far back. I will probably rebase one of these machines to current bugfix and test there before I dig into youre config tho.

[nichols89ben]

Ill have to go through the config here to see what the trigger is. Ive got IDEX machines running a snapshot from 08-04-23 that does not exhibit this, so at a minimum its not a generic problem that far back. I will probably rebase one of these machines to current bugfix and test there before I dig into youre config tho.

I appreciate it. If you need me to test something Im happy too. Ive been working on this issue for a few weeks and cant pin it down yet. Ive seen this behavior for awhile, including the stock sovol SV04 which they last updated 2021-09-03. However I just did everything stock and wasn't sure the cause because it was random.

[nichols89ben]

Ill have to go through the config here to see what the trigger is. Ive got IDEX machines running a snapshot from 08-04-23 that does not exhibit this, so at a minimum its not a generic problem that far back. I will probably rebase one of these machines to current bugfix and test there before I dig into youre config tho.

Hey, just wanted to check and see if you had a chance to take a look at it at all.

[InsanityAutomation]

Making my way down the list. Opened a few other PR's today for other items, some of them safety related so they jumped the queue. I got my branch rebased locally but didnt flash it yet. Machine was occupied with parts we need. My most accessible IDEX is also one of my largest machines at 600mm.

[nichols89ben]

Making my way down the list. Opened a few other PR's today for other items, some of them safety related so they jumped the queue. I got my branch rebased locally but didnt flash it yet. Machine was occupied with parts we need. My most accessible IDEX is also one of my largest machines at 600mm.

No problem, just wanted to check in. I will also note I noticed today this behavior happens as well when done from the Marlin LCD, move axis menu and switching from E2 back to E1

[InsanityAutomation]

Good thing is the Tenlog is running the same DWIN LCD, and I just finished porting the same landscape code to a portrait setup... Is the SV04 screen 480x272 or 800x480?

[nichols89ben]

Good thing is the Tenlog is running the same DWIN LCD, and I just finished porting the same landscape code to a portrait setup... Is the SV04 screen 480x272 or 800x480?

I actually did an overhaul and run a BTT Octopus 1.1 and a BTT TFT 70. But with the TFT 70 it was in Marlin Mode, I haven't tried the BTT TFT firmware yet

[InsanityAutomation]

Is youre toolhead actually hitting and crashing? Or just moving to that corner unexpectedly? The video cuts out before it fully stops going to T1 before trying to return to T0 where the report is a crash. It does not show the subsequent call to T0 that should park T1.

I tried on my machine without success to reproduce this issue. I tried both with and without TOOLCHANGE_NO_RETURN and could not make the heads crash together.

Reading through youre config, I see something odd.

#define X1_MAX_POS X_MAX_POS (X_MAX_POS is 288)
#define X2_MAX_POS 365 //#BEN_IDEX // The max position of the X2 carriage, typically also the home position

I believe these are backwards and may be what is causing youre crash. You are telling X1 it is allowed to go beyond where X2 parks.

If you want to compare to my config, can review here -
https://github.com/InsanityAutomation/Marlin/tree/Tenlog_DWIN

[thisiskeithb]

Closing since this was a misconfiguration issue & not a bug.

[nichols89ben]

Is youre toolhead actually hitting and crashing? Or just moving to that corner unexpectedly? The video cuts out before it fully stops going to T1 before trying to return to T0 where the report is a crash. It does not show the subsequent call to T0 that should park T1.

I tried on my machine without success to reproduce this issue. I tried both with and without TOOLCHANGE_NO_RETURN and could not make the heads crash together.

Reading through youre config, I see something odd.

#define X1_MAX_POS X_MAX_POS (X_MAX_POS is 288) #define X2_MAX_POS 365 //#BEN_IDEX // The max position of the X2 carriage, typically also the home position

I believe these are backwards and may be what is causing youre crash. You are telling X1 it is allowed to go beyond where X2 parks.

If you want to compare to my config, can review here - https://github.com/InsanityAutomation/Marlin/tree/Tenlog_DWIN

Im looking at it again, but that doesn't make sense to me yet.

• X1_MIN_POS - Set to the X_MIN_POS, -55
• X1_MAX_POS - A max coordinate so the X1 carriage can't hit the parked X2 carriage, Which in this case is X_MAX_POS
  288, anything after 288 X1 will hit X2. Im just running the X1 print head right now and it respects that limit just fine.
• X2_MIN_POS- A min coordinate so the X2 carriage can't hit the parked X1 carriage, is this case its 25, anything between -55 and 25 the print head will hit the X1 Carriage. Currently works just fine, if I try and manually move the X2 Carriage past 25 it stops at 25.
• X2_MAX_POS - The max position of the X2 carriage, typically also the home position. I assume the home position is referring to the X2 home position, which here is 365. My bed it 310, but the park position for X2 is 365 at the endstop to clear the bed.

"You are telling X1 it is allowed to go beyond where X2 parks" - The X1_Max is 288, anything past that to 365 it would run into X2 carriage, but currently it won’t go past 288.

Your settings seem similar to mine from what I can tell,
#define X1_MIN_POS -50
#define X1_MAX_POS X_BED_SIZE
#define X2_MIN_POS 15
#define X2_MAX_POS 279

I have a print going right now, but I can record the full length tomorrow. But the behavior is, if the printer is set in T1, and the command is sent to switch to the T0 head, even if parked, T1 X2 carriage move to the left where the T0 X1 carriage is parked, make contact with the X1 Carriage, continues to try and move past it (grinds the belt), then very rapidly goes to the right, assuming trying to park at the X2 max, but because of the belt grinding, thinks its in a different position so it crashes and makes contact with the X2 max pos (365) and tries to move past that.

Maybe Im missing something fundamentally, but Ive stared at this for a few hours and haven’t been able to wrap my head around how they would be backwards.

[nichols89ben]

Closing since this was a misconfiguration issue & not a bug.

I don't think this is closed yet unless there's something im not understanding. Apologies if it is

[InsanityAutomation]

Ill reopen till we dig don to the bottom of it. I do not have a sovol sv04 to directly compare, I tested on a Tenlog D3 and D6. Ill probably get a Formbot Trex 3 updated this week to check as well.

Is there a reason youre using
#define MANUAL_X_HOME_POS -51.3 // #BEN_GEOMETRY
#define MANUAL_Y_HOME_POS -0.4 // #BEN_GEOMETRY
Marlin.zip

Instead of setting X/Y_MIN? I dont see a reason to use these instead in this configuration.

I tweaked the motion limits to be in line with what ive got here. One issue is likely that the overall X_MAX_POS as clamped to the X1 pos which could cause some inconsistent behavior. I adjusted to where you should get the same numbers with the X_MAX_POS equal to the X2_MAX_POS as the settings default to.

[nichols89ben]

Ill reopen till we dig don to the bottom of it. I do not have a sovol sv04 to directly compare, I tested on a Tenlog D3 and D6. Ill probably get a Formbot Trex 3 updated this week to check as well.

Is there a reason youre using #define MANUAL_X_HOME_POS -51.3 // #BEN_GEOMETRY #define MANUAL_Y_HOME_POS -0.4 // #BEN_GEOMETRY Marlin.zip

Instead of setting X/Y_MIN? I dont see a reason to use these instead in this configuration.

I tweaked the motion limits to be in line with what ive got here. One issue is likely that the overall X_MAX_POS as clamped to the X1 pos which could cause some inconsistent behavior. I adjusted to where you should get the same numbers with the X_MAX_POS equal to the X2_MAX_POS as the settings default to.

Thank you for your help! Ive replaced both carriages, extruders, and mainboard so its more custom now than it is a sv04.

Heres an updated video, it shows everything i mentioned in my last comment
https://drive.google.com/file/d/14Va7-cpETgLRxnia31nVq41ebJAL0b01/view?usp=sharing

For the config, I was having trouble getting a consistent home/probe at the center of the bed. I watched a few tutorial videos and this was the method to use the manual home. If I recall, i commented it out and tried it again but it still behaved the same. Ill recompile and load your adjust config and re try it. Thanks again for looking at it.

[nichols89ben]

Ill reopen till we dig don to the bottom of it. I do not have a sovol sv04 to directly compare, I tested on a Tenlog D3 and D6. Ill probably get a Formbot Trex 3 updated this week to check as well.

Is there a reason youre using #define MANUAL_X_HOME_POS -51.3 // #BEN_GEOMETRY #define MANUAL_Y_HOME_POS -0.4 // #BEN_GEOMETRY Marlin.zip

Instead of setting X/Y_MIN? I dont see a reason to use these instead in this configuration.

I tweaked the motion limits to be in line with what ive got here. One issue is likely that the overall X_MAX_POS as clamped to the X1 pos which could cause some inconsistent behavior. I adjusted to where you should get the same numbers with the X_MAX_POS equal to the X2_MAX_POS as the settings default to.

I just flashed the firmware with the adjustments you made, M502 M500, then re-ran the same test in the video, but the result was identical as in the video

[InsanityAutomation]

Ok, youre selecting from the menu, I was sending gcode to the terminal. Ill see if the menu does anything different selecting heads and try to reproduce that way next.

[nichols89ben]

Ok, youre selecting from the menu, I was sending gcode to the terminal. Ill see if the menu does anything different selecting heads and try to reproduce that way next.

It actually happens from the screen on the terminal with just sending T1. I was just showing it from the screen. Also I don’t see anywhere where the acceleration is set that high for the x2 carriage

[nichols89ben]

Ok, youre selecting from the menu, I was sending gcode to the terminal. Ill see if the menu does anything different selecting heads and try to reproduce that way next.

Hey there, Just checking in to see if you where able to find anything? Is there a way to override the default tool change behavior that could just say t1 to x365 etc or something of the sorts as a workaround

[InsanityAutomation]

I could not get my machine to reproduce the behavior at all. Chris Pepper was getting the simulator to support IDEX machines, then we should be able to apply youre config directly in the simulator and see what we can get.

[ellensp]

@InsanityAutomation The Simulation of IDEX works, And while Chris was implementing it he did trigger this issue
Apply #27030 Note: the reason this is on hold is it broke delta and the 3d render gets occasional spikes, but otherwise it is usable for IDEX testing (as far as we know)

[InsanityAutomation]

@InsanityAutomation The Simulation of IDEX works, And while Chris was implementing it he did trigger this issue Apply #27030 Note: the reason this is on hold is it broke delta and the 3d render gets occasional spikes, but otherwise it is usable for IDEX testing (as far as we know)

I knew he got it working but didnt see he triggered this issue. Ill get his config that triggered it this weekend. Machine runoff today, ships Wed so hopefully light at the end of the tunnel here...

[nichols89ben]

@InsanityAutomation The Simulation of IDEX works, And while Chris was implementing it he did trigger this issue Apply #27030 Note: the reason this is on hold is it broke delta and the 3d render gets occasional spikes, but otherwise it is usable for IDEX testing (as far as we know)

I knew he got it working but didnt see he triggered this issue. Ill get his config that triggered it this weekend. Machine runoff today, ships Wed so hopefully light at the end of the tunnel here...

No worries, let me know if theirs anything I can test

[p3p]

This was only vaguely reproduced (T1 crashing into T0 when switching) due to a problem with the X_MAX endstop, the problem being that I didn't plug one into the virtual printer.., I've only ran the sim with a mostly default IDEX config, but currently it seems to be working properly.

[nichols89ben]

This was only vaguely reproduced (T1 crashing into T0 when switching) due to a problem with the X_MAX endstop, the problem being that I didn't plug one into the virtual printer.., I've only ran the sim with a mostly default IDEX config, but currently it seems to be working properly.

Ill check again and post the output but the XMAX was being triggered according to the debug pins. Posting my current configs if needed

Archive.zip