Marlin: Dual_X_Carriage proper behavior is broken

[AndrewDiehl]

M605 S0 is default.
Homed All axis.

T0 is at 0
T1 is at 400

Send following commands:

T0
G1 X10 F1000

The T0 head (left side) moves to X35 instead of X10,
Subsequently can not move the T0 head to anything less than X35 without a homing command.

X35 is the the T1 minimum position, and should not be affecting T0

Additionally,
Issuing a T1 command immediately sends the T1 head to the same position as the T0 head, causing a collision. Simply issuing T1 should not cause any movement.

[thinkyhead]

Unfortunately we haven't had any testers with a dual-x setup. If you can help us to work on this it would be very much appreciated.

[AndrewDiehl]

I will do whatever I can to help.

[AndrewDiehl]

Is there anything I can do to help right now, or just wait until its patched and try again?

[boelle]

@thinkyhead anything he can do ?

[boelle]

@thinkyhead anything he can do ?

[thinkyhead]

He can call in the geek troops to help me! I have very limited time to work on the main Marlin project than I would like these days, and I have some other issues to tackle today.

[thinkyhead]

He can call in the geek troops to help me! I have very limited time to work on the main Marlin project than I would like these days, and I have some other issues to tackle today.

[boelle]

@AndrewDiehl :-D so if you know some geek people that can help out let us know

[AndrewDiehl]

My people are all Electrical/Mechanical but no software :(

If any of your tasks involve CAD or fabrication, I'd be happy to help lighten the load.

[psyvision]

I'm watching this now as I have the T0/T1 crash issue. I'll take a look at the code later today

[boelle]

@AndrewDiehl i assume this "problem" is still present?

[AndrewDiehl]

I would assume so, as nobody has asked me to test a fix.

On Nov 2, 2016 9:48 AM, "Bo Herrmannsen" [email protected] wrote:

@AndrewDiehl https://github.com/AndrewDiehl i assume this "problem" is
still present?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/4694#issuecomment-257868688,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABOp2Bu5yqhjP2sTyPlwnhIR15CviyaWks5q6JSTgaJpZM4Jrb7r
.

[boelle]

@AndrewDiehl are you able to work with @thinkyhead to figure it out?

you test and he tries to fix?

[AndrewDiehl]

I'll be away from my machines until Friday, but generally, yes.

[boelle]

oki doke... then i think @thinkyhead will poke you when he is ready :-)

[thinkyhead]

@AndrewDiehl What time zone are you in? Perhaps we can do an online hangout or chat session where I can try patching some things and you could give feedback. I'd like to make sure all Dual X behavior is proper, includingT0/T1, parking the head, doing duplication mode, etc., and I know if I try to work it out on my own it'll be hit-or-miss.

[AndrewDiehl]

Eastern time USA.

[thinkyhead]

@AndrewDiehl I'm on Central Time currently. Do you have some availability Friday night, or over the weekend to hack on this?

[boelle]

@AndrewDiehl will you have time this weekend?

[thinkyhead]

@AndrewDiehl If I had a Dual-X machine on hand to test with this and other Dual X issues could be solved in a day. Without one I'm terribly afraid of making it worse.

[AndrewDiehl]

Sorry for the delay here,

I'm trying to make time for this on Sunday.

My newborn is being extra fussy the last few days so its been harder to find time than expected.

[AndrewDiehl]

@thinkyhead

I can do google hangouts using [email protected] or you can call 610-295-7867. For voice I may have to call back using wi-fi since my house has poor signal.

[thinkyhead]

@AndrewDiehl When you have a chance, please post a log of G28 so I can see what state the machine is in after you've homed. First, enable DEBUG_LEVELING_FEATURE and re-flash. Before homing, do M111 S247 to enable all logging except "DRYRUN." Then when you do G28 there should be some extra logging of the whole procedure.

Also post your configuration, or the relevant settings.

I'm starting to make some tweaks based on your description of the issue, but I'm being cagey because I'm not entirely sure what all the tool-change behaviors should be for every Dual X mode.

Let me see if I have the general idea anyway…

• DXC_FULL_CONTROL_MODE: Simply set the current position to the position of the newly-selected nozzle, without any movement.
• DXC_AUTO_PARK_MODE: Park the active carriage and move the selected carriage into its vacated position (unless S1 -stay- is given).
• DXC_DUPLICATION_MODE: I presume there should be no movement on tool-change in this mode.

Tool-change in DXC_DUPLICATION_MODE is a curious concept. With extruder 0 active, its movements are duplicated in extruder 1. But if extruder 1 is selected, should it then become the one that is moved, while extruder 0 follows it? Or should the duplication flag (extruder_duplication_enabled) just be disabled until extruder 0 is selected again?

[thinkyhead]

@AndrewDiehl Also test this branch, which has some tweaks that may help (or not):
https://github.com/thinkyhead/Marlin/tree/rc_dualx_homing

[thinkyhead]

@psyvision @pbrgle1 @gsart84 Please join this thread…

[gsart84]

Thanks. Still got some troubles. Now zaxis moves up withoud stopping

[thinkyhead]

@gsart84. When does Z move up without stopping?

[gsart84]

After toolchange...
I do g28,
Then move t0 to x140
Then a toolchange.
First the x2 crashes in the endstop
Then z lifts up with no stopping

[psyvision]

Can someone remind me what g-code will enable logging and i'll do a log of G28 if it is still needed? @thinkyhead

@gsart84 was the tool crashing with RC7 or the branch that @thinkyhead posted above?

[gsart84]

It crashes with the branch from thinkyhead.
In rc7 after g28, when i do a movement (i.e. g1z1)
All axes do some strage slow movements to x0 y0 z10
To move the head or table i have to:

G28
M605 s0
M605 s1

And then i can move withoud pronlem

[gsart84]

M111 S247 is the code for logging.
And here the video of my problem with rc7
https://youtu.be/Y8UuKQfCeCE

[Blue-Marlin]

Likely it would be a bit more informative if you'd activated DEBUG_LEVELING_FEATURE in your config.

[psyvision]

Cheers, i'll reflash with that on! Sorry I'm new to debugging Marlin :/

[psyvision]

Okay I've put a gist together with the log in it:

https://gist.github.com/psyvision/e0dcae5087cf4c262b0f62d032469a84

G28 was okay. T1 S1 caused no movement, T1 caused no movement. T0 caused T0 to crash into T1.

My configuration is available here:

https://github.com/psyvision/BigBox-IDEX/blob/master/Marlin/

[gsart84]

@psyvision
In yout configuration adv i see you have x2-max-pos x-max-pos

So if i understand right, if my printer would be configured like yours, t1 would crash into t0.

[psyvision]

It's just shorthand for saying the max X2 position is the same as used for X max without putting the same number twice. I had seen this done for a few different IDEX printers so went with it for initial configuration.

I can get T0 to hit T1 and T1 to hit T0.

[thinkyhead]

the max X2 position is the same as used for X max

Note: On a dual setup your first carriage cannot move as far right as your second carriage (because the 2nd carriage is in the way), so X_MAX_POS should be smaller than X2_MAX_POS by the width of the carriage. Also, the second carriage can't move as far left as the first one (because the 1st carriage is in the way), so X2_MIN_POS should be larger than X_MIN_POS by the width of the carriage.

[thinkyhead]

I can get T0 to hit T1 and T1 to hit T0.

That's the great thing about DXC_FULL_CONTROL_MODE. Total freedom.

[thinkyhead]

G28 was okay. T1 S1 caused no movement, T1 caused no movement. T0 caused T0 to crash into T1.

The test branch I linked is far from ready. Thanks for giving it a test. I will look at the log more closely, and I'll keep tweaking tool_change. I may add more logging and ask for more testing.

[AndrewDiehl]

Wow! Lots to go over here.

Learning about the T0 vs T0 S1 is totally new news to me. Is this in the code comments anywhere? Its not in the marlin.main documentation nor under the Dual X Carriage define as far as I can tell. This should be in both places.

The "Unpark when using Z_SAFE_HOMING with Dual X #5175" branch fixes the park/unpark issues while in DXC_FULL_CONTROL_MODE. Changing from T0 to T1 no longer crashes the extruder heads into one another.

However, T0 is still being made to obey the X2_MIN_POS.

After homing, a move command makes T0 move to the X2_MIN_POS if the command doesn't move it past that value.

ie: my X2_MIN_POS is 35

I home my machine.
Select T0
Issue a G1 X1 F10000

T0 immediately moves to X35.

If I home and issue a G1 X100 command, T0 moves to X100.

---

The Autopark mode in 5175 is much scarier than before.

Dropbox link to my configs https://www.dropbox.com/sh/mg5z4r6i2fag7p9/AADZOaF2SrCTgiu-sVn2_Yzta?dl=0

Issuing a T1 command after homing and Setting M605 S1 now sends the Z axis down to Z0 and Back instead of up to the z hop distance. Afterwords, Selecting T0 again forces both heads past their end stops and moves the Z axis to Z0 and back

Also tried un-commenting the debugging feature you requested but I'm not using auto level and I get a compiling error.

[psyvision]

@thinkyhead I had set my X2 min/max to those values because I was observing the behaviour that @AndrewDiehl has described above, when switching to T0 it would move to X2_MIN and could never go further left (i.e. back into it's dock/park position). Putting it at 0 and X2_MAX = X_MAX (as BCN3D have done with the IDEX Sigma firmware, although heavily modified) allowed me to get the carriages in the appropriate places.

[boelle]

@AndrewDiehl @thinkyhead what output did you get from the testing session?

[wallacezhang]

@psyvision @AndrewDiehl @thinkyhead have you solved the T0/T1 crash issue? I'm suffering this issue now, don't know where I'm wrong, would you like to help? thanks a lot.

[gsart84]

RC 8 / RC bugfix work perfect.
You have to adjust configuration.adv the right way. For a example you can download my configuratin in my github...

[wallacezhang]

@gsart84 I downloaded your RC8 firmware and tested in my printer, the T1 carsh into T0 still. any thought?

[gsart84]

@wallacezhang
ok, hm, i do not know where the problem. my printer is working perfect with the configuration you use!

[gsart84]

is it a custom printer? witch board? i use a rumba board, have 2 endstops and have a x offset of 40mm from nozzle to heatbed...

[wallacezhang]

@gsart84 my printer is Prusa i3 structure, I also use Rumba board. here is my issue when uploading your firmware:

1. when T0 finish printing, it'll go home normally, but T1 moves to print very slowly, moreover, T1 doesn't start to print when it go to the place of model.
2. when switch to T0 again, T1 can't go home normally, I have to cut power, so as to avoiding T0/T1 crash.
   do you think it's the issue of firmware or slicing?

[gsart84]

Do you use dxc auto park mode?
With auto park mode, there is no problem with simplify3d and cura. Do not use a tool change skript.
Your problem seems to me like wrong settings with your offsets. I know this problem with slow movements. The Only one slow movement that remains on my printer, is moving y after homing x and y after printt is finished. Cant solve this issue.

[gsart84]

Attention if you use my firmware, check the invertet stepper motors, i hope you adjust this firmware correctly for your movements

[wallacezhang]

@gsart84 I use your firmware directly and have such issue after uploading it.
wrong settings with offsets? which one do you mean?

[gsart84]

Sorry, i forgot to say;
My printer is a complete rework of a hellobeeprusa. Like pinting volume of 280x280,
Bltouch bed level sensor and so on.
You can not download any firmware and just flash. You have to configure it. Example: you flash a firmware, move the x in x+ direction and it goes wrong. Then you have to adjust the settings so it moves in the right direction. You can not flash my firmware without configure it like your printer. My firmware is only a example for your printer.
Sorry my english skills are to bad to explain you what i mean exactly...

[wallacezhang]

yeah, I have checked your firmware before updating.
I also have a BLTouch on my printer, and the axis direction are also same as yours, so it doesn't need to change firmware.

[wallacezhang]

here are the errors Repetier Host gives me when printing from computer directly:

[gsart84]

There is a posibility to activate something like advanced debugging mode... ask @thinkyhead.
Understandig your errorlines is a little to complicatet for me. I never see your errors exept the busy error.

[wallacezhang]

ok, thanks. @thinkyhead could you find any clue?

[wallacezhang]

@gsart84 as I see from records, you also had the issue of slowly moving before, how did you fix it?

[gsart84]

The biggest problem with slow movement after g28 is away now. This was caused using m605 s0. It was fixed by thinkyhead with rc8. Only the movements after print is finished after g28 x0 y0 is not solved

[gsart84]

@wallacezhang try this:
Start printer
-g28
-M605 S1
-M605 S0
And then try to move the printer
In this way i solved the problem with slow movements

[wallacezhang]

it seems @thinkyhead is too busy, could you send your workable firmware to my email: wallace.[email protected], I'm afraid I have downloaded wrong firmware, otherwise, it should be also workable in my printer. right?

[gsart84]

@wallacezhang the firmware you downloaded from my github is the newest i'm using. I uploaded it a few days before. Have you tryed download the newest rcbugfix and configure it like my firmware?

[wallacezhang]

yeah, I also tried rcbugfix, same issue.

[wallacezhang]

do you think it's related to extruder sequence? my left extruder is X1, right extruder is X2. and X1 is T0, X2 is T1.

[gsart84]

I think its the same.
Have you look into pins_rumba.h?
My pin configuration is like this on the board:
X2
E1
E0
Z+Z2
Y+Y2
X1

[thinkyhead]

Sorry, I have been very much focused on other tasks, but of course Marlin-related. We did a lot of work testing Dual X not long ago and patched it up a lot. I think those changes did make it into RC8, and I recall that "slow movement" might have been one of the issues we were seeing and figured out. So maybe there's a regression, or bad interaction with another option. I'll look through the threads where we were working on this stuff and see if I can find any clue.

[thinkyhead]

Ok, so in #5175 I did find the solution to the slow movement issue, which in that case was related to Z_SAFE_HOMING. The root cause of the issue was that after Z safe homing, the "parked" state needed to be unset, since the nozzle moves in that case. Just needed to add this to the homeaxis function:

      // This causes the carriage on Dual X to unpark
      #if ENABLED(DUAL_X_CARRIAGE)
        active_extruder_parked = false;
      #endif

Anyway, for more detailed logging enable DEBUG_LEVELING_FEATURE and before doing anything send M111 S247 to turn on lots of logging. Do the stuff that causes problems and post the log output here.

[gsart84]

Thanks @thinkyhead :)
I will try.

[thinkyhead]

@wallacezhang By the way… welcome to Github!

[wallacezhang]

@gsart84 @thinkyhead hi, I was learning and playing with Marlin last few days, now manage to solve above issue already. thanks a lot,
now I'm trying to print in duplicate mode, but when start to print, T1 doesn't come to print with T0 together, it just stays at home. is it related to firmware or slicing?

[wallacezhang]

sorry, I'm a little dull in software. :)

[thinkyhead]

Duplication mode should be working if you've enabled…

#define DUAL_NOZZLE_DUPLICATION_MODE

…in Configuration_adv.h.

The GCode should contain M605 S2 to enable duplication.

If you have those covered then we'll need to look further.

[wallacezhang]

but if I enable #define DUAL_NOZZLE_DUPLICATION_MODE, the firmware can't be compiled successfully,
and it'll report below error:

[wallacezhang]

if I disable dual X carriage, it can compile successfully, but T1 won't heat up or move when start to print.

[thinkyhead]

@wallacezhang Oops, sorry about that. I forgot that DUAL_NOZZLE_DUPLICATION_MODE is for a single carriage dual nozzle setup. So just as it is —with DUAL_X_CARRIAGE alone enabled— you should be able to use M605 S2 to enable duplication mode.

To help isolate the issue, please grab the latest RCBugFix code from https://github.com/MarlinFirmware/Marlin/tree/RCBugFix and enable DEBUG_LEVELING_FEATURE in Configuration.h. Send the commands:

G28         ; home
M111 S247   ; enable detailed logging
M605 S2 X50 ; enable duplication mode
G1 X10 Y10  ; Test a single move in XY
M104 S50    ; Heat up nozzles

Copy the log output and paste it here for review.

[wallacezhang]

ok, here it is:

[wallacezhang]

@gsart84 do you have any ideas? I'm trying to print in duplicate mode with your firmware. when start to print, T1 can heat up, but it doesn't come to print with T0 together, just stays there. have you met such issue before?

[gsart84]

@wallacezhang
I never have duplication mode working. Only tried 2 or 3 times. Only T0 works in duplication mode.
Did you try with RCbugfix?

[wallacezhang]

so when you print in duplicate mode, your T1 doesn't start to print, either?

[gsart84]

exactly. but i dont know its my fault or is there a bug.
i hope @thinkyhead can help or any person with a dual x carriage printer.

[gsart84]

would you try to download the actual rcbugfix and test it?

[wallacezhang]

yeah, I also tried the latest rcbugfix from @thinkyhead , but same issue.

[gsart84]

ok, now we are 2 persons with not working duplication mode. i have 6 printers with dual x carriage and no one of them work with duplication mode. i think we should make na new issue thread?

[wallacezhang]

yeah, do you think it's related to firmware or slicing?

[gsart84]

i think its the firmware... anything behind the M605 S2 is not working. same result in cura or simplify. what slicer do you use?

[wallacezhang]

I think so, too.

[thinkyhead]

I'll have to add more logging to see what's occurring.

[thinkyhead]

The commentary on M605 indicates that G28 is required after M605 Sn changes the mode. Try doing G28 X after M605 S2 and see if it subsequently works.

[gsart84]

Thanks i will try tomorrow.

[gsart84]

ok, i tried this:
M605 S2
g28
G1 X10 Y10

only T0 moves.

[thinkyhead]

Does the M104 command cause both nozzles to heat up in this mode? Earlier reports are unclear.

[thinkyhead]

@wallacezhang @gsart84
I've added more logging, so get the latest RCBugFix and run that GCode again.

Be sure to use a host like _Pronterface_ instead of Repetier Host because it apparently filters out all messages that don't start with "echo:" or "error:".

Copy the text in the log window and paste it —preferably as text— for us to review.

[gsart84]

@thinkyhead , im using pronterface. i use the 2 days old rcbugfix in one one of my 7 printers and rc8 in one of this 7. M104 Does heat up both nozzles T0 and T1 in duplication mode.

G28
M605 S2
G28
M104 S50
G1 X50

only T0 is moving

[gsart84]

Connecting...
start
Printer is now online.
echo:Marlin 1.1.0-RCBugFix
echo: Last Updated: 2016-12-06 12:00 | Author: (none, default config)
Compiled: Apr 14 2017
echo: Free Memory: 2984  PlannerBufferBytes: 1264
Using tool 0.
echo:V34 stored settings retrieved (451 bytes)
echo:Steps per unit:
echo:  M92 X80.00 Y80.00 Z4000.00 E105.00
echo:Maximum feedrates (mm/s):
echo:  M203 X150.00 Y150.00 Z3.00 E25.00
echo:Maximum Acceleration (mm/s2):
echo:  M201 X700 Y700 Z100 E10000
echo:Accelerations: P=printing, R=retract and T=travel
echo:  M204 P400.00 R3000.00 T3000.00
echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s),  Z=maximum Z jerk (mm/s),  E=maximum E jerk (mm/s)
echo:  M205 S0.00 T0.00 B20000 X11.00 Y11.00 Z0.40 E5.00
echo:Home offset (mm)
echo:  M206 X0.00 Y0.00 Z0.00
echo:Hotend offsets (mm)
echo:  M218 T1 X0.00 Y0.00 Z0.00
Auto Bed Leveling:
echo:  M420 S0 Z0.00
echo:Material heatup parameters:
echo:  M145 S0 H200 B60 F0
  M145 S1 H240 B100 F0
echo:PID settings:
echo:  M301 P30.98 I3.43 D70.05
echo:Filament settings: Disabled
echo:  M200 D3.00
echo:  M200 T1 D3.00
echo:  M200 D0
echo:Z-Probe Offset (mm):
echo:  M851 Z-1.45
echo:SD card ok
echo:Active Extruder: 0
echo:SD card ok
>>> G28         ; home
SENDING:G28         ; HOME
echo:Active Extruder: 0
echo:busy: processing
echo:Active Extruder: 0
>>> M111 S247   ; enable detailed logging
SENDING:M111 S247   ; ENABLE DETAILED LOGGING
echo:DEBUG:ECHO,INFO,ERRORS,COMMUNICATION
>>> M605 S2 X50 ; enable duplication mode
SENDING:M605 S2 X50 ; ENABLE DUPLICATION MODE
echo:M605 S2 X50
echo:Hotend offsets: 0.00,0.00 52.00,0.00
>>> G1 X10 Y10  ; Test a single move in XY
SENDING:G1 X10 Y10  ; TEST A SINGLE MOVE IN XY
echo:G1 X10 Y10
>>> M104 S50    ; Heat up nozzles
SENDING:M104 S50    ; HEAT UP NOZZLES
echo:M104 S50

[thinkyhead]

SENDING:M605 S2 X50 ; ENABLE DUPLICATION MODE
echo:M605 S2 X50
echo:Hotend offsets: 0.00,0.00 52.00,0.00
>>> G1 X10 Y10  ; Test a single move in XY

@gsart84
Can you post a log where there is a G28 following M605 S2?
(You can leave out any G28 before the M605.)

[thinkyhead]

SENDING:M111 S247   ; ENABLE DETAILED LOGGING
echo:DEBUG:ECHO,INFO,ERRORS,COMMUNICATION

The lines above indicate you did not enable DEBUG_LEVELING_FEATURE as instructed. Please also enable that feature before flashing the board and proceeding with the test. Without it there is only minimal logging.

G28
M605 S2
G28
M104 S50
G1 X50

[gsart84]

Ok, thanks, sorry i will try after work

[gsart84]

@thinkyhead :

Boot Log

Connecting...
start
Printer is now online.
Using tool 0.
echo:Marlin 1.1.0-RCBugFix
echo: Last Updated: 2016-12-06 12:00 | Author: (none, default config)
Compiled: Apr 18 2017
echo: Free Memory: 2959  PlannerBufferBytes: 1264
echo:EEPROM version mismatch (EEPROM=V27 Marlin=V35)
echo:Hardcoded Default Settings Loaded
echo:  G21 ; Units in mm
echo:Filament settings: Disabled
echo:  M200 D1.75
echo:  M200 T1 D1.75
echo:  M200 D0
echo:Steps per unit:
echo:  M92 X80.00 Y80.00 Z4000.00
echo:  M92 T0 E105.00
  M92 T1 E105.00
echo:Maximum feedrates (units/s):
echo:  M203 X150.00 Y150.00 Z3.00
echo:  M203 T0 E25.00
  M203 T1 E25.00
echo:Maximum Acceleration (units/s2):
echo:  M201 X700 Y700 Z100
echo:  M201 T0 E10000
  M201 T1 E10000
echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo:  M204 P160.00 R3000.00 T300.00
echo:Advanced: S<min_feedrate> T<min_travel_feedrate> B<min_segment_time_ms> X<max_xy_jerk> Z<max_z_jerk> E<max_e_jerk>
echo:  M205 S0.00 T0.00 B20000 X16.00 Y16.00 Z0.40 E5.00
echo:Home offset:
echo:  M206 X0.00 Y0.00 Z0.00
echo:Hotend offsets:
echo:  M218 T1 X0.00 Y0.00 Z0.00
echo:Auto Bed Leveling:
echo:  M420 S0 Z0.00
echo:Material heatup parameters:
echo:  M145 S0 H200 B60 F0
  M145 S1 H240 B80 F0
echo:PID settings:
echo:  M301 P30.98 I3.43 D70.05
echo:  M304 P152.75 I29.32 D198.96
echo:Z-Probe Offset (mm):
echo:  M851 Z0.00
echo:SD card ok
echo:Active Extruder: 0
echo:SD card ok

G28 Log

>>> M111 S247
echo:DEBUG:ECHO,INFO,ERRORS,COMMUNICATION,LEVELING

>>> m605 s2
echo:Hotend offsets: 0.00,0.00 140.00,0.00

>>> g28
>>> gcode_G28

  Machine Type: Cartesian
  Probe: BLTOUCH
  Probe Offset X:-35 Y:-10 Z:0.00 (Left-Front & Same Z as Nozzle)
  Auto Bed Leveling: BILINEAR (disabled)
  echo:Active Extruder: 0

    current_position=(0.00, 0.00, 0.00) : setup_for_endstop_or_probe_move
  > endstops.enable(true)
  Raise Z (before homing) to 14.00
  >>> do_blocking_move_to(0.00, 0.00, 14.00)
  <<< do_blocking_move_to

  >>> homeaxis(X)
    Home 1 Fast:
    >>> do_homing_move(X, 493.50, 0.00)
      current_position=(0.00, 0.00, 14.00) : sync_plan_position
    <<< do_homing_move(X)
    Move Away:
    >>> do_homing_move(X, -5.00, 0.00)
      current_position=(0.00, 0.00, 14.00) : sync_plan_position
    <<< do_homing_move(X)
    Home 2 Slow:
    >>> do_homing_move(X, 10.00, 25.00)
      current_position=(0.00, 0.00, 14.00) : sync_plan_position
    <<< do_homing_move(X)
    >>> set_axis_is_at_home(X)
    For X axis:
     home_offset = 0.00
     position_shift = 0.00
     soft_endstop_min = 80.00
     soft_endstop_max = 353.00
      current_position=(353.00, 0.00, 14.00) : sync_plan_position
      current_position=(353.00, 0.00, 14.00) : > AFTER set_axis_is_at_home
  <<< homeaxis(X)

  >>> homeaxis(X)
    Home 1 Fast:
    >>> do_homing_move(X, -493.50, 0.00)
      current_position=(0.00, 0.00, 14.00) : sync_plan_position
    <<< do_homing_move(X)
    Move Away:
    >>> do_homing_move(X, 5.00, 0.00)
      current_position=(0.00, 0.00, 14.00) : sync_plan_position
    <<< do_homing_move(X)
    Home 2 Slow:
    >>> do_homing_move(X, -10.00, 25.00)
      current_position=(0.00, 0.00, 14.00) : sync_plan_position
    <<< do_homing_move(X)
    >>> set_axis_is_at_home(X)
    For X axis:
     home_offset = 0.00
     position_shift = 0.00
     soft_endstop_min = -49.00
     soft_endstop_max = 213.00
      current_position=(-49.00, 0.00, 14.00) : sync_plan_position
      current_position=(-49.00, 0.00, 14.00) : > AFTER set_axis_is_at_home
  <<< homeaxis(X)

    current_position=(-49.00, 0.00, 14.00) : > homeX

  >>> homeaxis(Y)
    Home 1 Fast:
    >>> do_homing_move(Y, -442.50, 0.00)
      current_position=(-49.00, 0.00, 14.00) : sync_plan_position
    <<< do_homing_move(Y)
    Move Away:
    >>> do_homing_move(Y, 5.00, 0.00)
      current_position=(-49.00, 0.00, 14.00) : sync_plan_position
    <<< do_homing_move(Y)
    Home 2 Slow:
    >>> do_homing_move(Y, -10.00, 25.00)
      current_position=(-49.00, 0.00, 14.00) : sync_plan_position
    <<< do_homing_move(Y)
    >>> set_axis_is_at_home(Y)
    For Y axis:
     home_offset = 0.00
     position_shift = 0.00
     soft_endstop_min = -15.00
     soft_endstop_max = 280.00
    > home_offset[Y] = 0.00
      current_position=(-49.00, -15.00, 14.00) :
    <<< set_axis_is_at_home(Y)
      current_position=(-49.00, -15.00, 14.00) : sync_plan_position
      current_position=(-49.00, -15.00, 14.00) : > AFTER set_axis_is_at_home
  <<< homeaxis(Y)

    current_position=(-49.00, -15.00, 14.00) : > homeY

  Z_SAFE_HOMING >>>
    current_position=(-49.00, -15.00, 14.00) : sync_plan_position
    destination=(150.00, 142.00, 14.00) : Z_SAFE_HOMING
  >>> do_blocking_move_to(150.00, 142.00, 14.00)
  <<< do_blocking_move_to

  >>> homeaxis(Z)
      current_position=(150.00, 142.00, 14.00) : set_probe_deployed
    deploy: 1
    do_probe_raise(10.00)
    >>> do_blocking_move_to(150.00, 142.00, 14.00)
    <<< do_blocking_move_to
    Home 1 Fast:
    >>> do_homing_move(Z, -330.00, 0.00)
      set_bltouch_deployed(1)
        current_position=(150.00, 142.00, 0.00) : sync_plan_position
      set_bltouch_deployed(0)
    <<< do_homing_move(Z)
    Move Away:
    >>> do_homing_move(Z, 5.00, 0.00)
      current_position=(150.00, 142.00, 0.00) : sync_plan_position
    <<< do_homing_move(Z)
    Home 2 Slow:
    >>> do_homing_move(Z, -10.00, 1.00)
      set_bltouch_deployed(1)
        current_position=(150.00, 142.00, 0.00) : sync_plan_position
      set_bltouch_deployed(0)
    <<< do_homing_move(Z)
    >>> set_axis_is_at_home(Z)
    For Z axis:
     home_offset = 0.00
     position_shift = 0.00
     soft_endstop_min = 0.00
     soft_endstop_max = 220.00
    *** Z HOMED WITH PROBE (Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN) ***
    > zprobe_zoffset = 0.00
    > home_offset[Z] = 0.00
      current_position=(150.00, 142.00, 0.00) :
    <<< set_axis_is_at_home(Z)
      current_position=(150.00, 142.00, 0.00) : sync_plan_position
      current_position=(150.00, 142.00, 0.00) : > AFTER set_axis_is_at_home
      current_position=(150.00, 142.00, 0.00) : set_probe_deployed
    deploy: 0
    do_probe_raise(10.00)
    >>> do_blocking_move_to(150.00, 142.00, 10.00)
    <<< do_blocking_move_to
    >>> do_blocking_move_to(150.00, 142.00, 10.00)
    <<< do_blocking_move_to
  <<< homeaxis(Z)

  <<< Z_SAFE_HOMING
    current_position=(150.00, 142.00, 10.00) : > (home_all_axis || homeZ) > final
    current_position=(150.00, 142.00, 10.00) : sync_plan_position
    current_position=(150.00, 142.00, 10.00) : clean_up_after_endstop_or_probe_move
  echo:Active Extruder: 0
<<< gcode_G28

>>> g1 x50

Disconnected.

[thinkyhead]

Sorry, busy week! I will examine this log more closely tomorrow, and I might also have some extra debugging help to track this down. In any case, it will be fixed 100% guaranteed before Sunday!

[thinkyhead]

We've done several patches related to M605 and special printing modes lately. Please check the latest code and see if it's any better today.

[gsart84]

@thinkyhead
Thank you very mouch. I test it soon as possible.

[gsart84]

Fund solution to get duplication mode to work for my printer.
Updated to newest firmware,
M605 S0
G28
G29
G0X0F5000
T1
G0X80F5000
M605 S2
T0
And Start print

I think it was my fault, because my Standart Funktion is M605 S1

Now all works perfect and i Can duplicate movements from t0 to t1

Thanks

[Roxy-3D]

@gsart84 An LCD Panel menu to select the IDEX mode and nozzle offsets has been added.
And G28 has been changed to preserve the IDEX mode across the homing operation.

That should let you select a mode (like Duplication Mode) and send the printer a part that only needs the left side of the bed, and you will get a duplicate part on the right side.

[InsanityAutomation]

A ton of idex changes since this was opened 2yrs ago...

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.