[BUG] Dual X Carriage modes (Bugfix-2.0.x)

[DrumClock]

In AUTO_PARK mode, the carriages are exactly replaced according to the X2_MAX_POS setting (hotend offset X) and everything works in the entire range X = 0 to 240 mm.

In DUPLICATION mode, the X2 carriage hits the X + endstop
(Of course, I try the movement in the range X= 0 to 115 mm)

In MIRRORED mode, the carriages collide in the middle
(Of course I try the movement in the range X= 0 to 115 mm)

In DUPLICATION and MIRRORED mode, there between carriages X1 and X2 is a gap of 198 mm .

I tried to change the DEFAULT_DUPLICATION_X_OFFSET setting.
But whatever I write there the gap is still 198 mm.

Configuration.txt
Configuration_adv.txt

[InsanityAutomation]

There are no provisions right now for capping the softendstops in duplication mode based on the offset applied, though its something thats been tossed around before. Itll probably get done at some point.

[Roxy-3D]

@InsanityAutomation What about the 198mm gap between the two extruders in duplication mode? It would seem changing DEFAULT_DUPLICATION_X_OFFSET should change that. But he says it doesn't?

I wonder if something got broke in G28. Or... Maybe something changed in M605? Both of those used to unpark the 2nd extruder and put it in the right place, and then unpark the 1st extruder.

[DrumClock]

The axial distance between the carrier X1 and X2 is directly dependent
about setting the HOTEND_OFFSET_X value for T1

   GAP = OFFSET
198 mm = 292 mm
121 mm = 370 mm
  50 mm = 440 mm

AUTO_PARK mode must be HOTEND_OFFSET_X for T1 = 292 mm (or X2_MAX_POS)
movement is OK in the whole range of HB (0-240 mm), replacement T0 / T1 accurate.

DUPLICATION mode must be HOTEND_OFFSET_X for T1 = 370 mm
movement is limited to 0-170 mm and is OK

MIRRORED mode must be HOTEND_OFFSET_X for T1 = 440 mm
movement is limited in the range 0-170 mm - carrier X1 and X2 collide at a position of 105 mm

[DrumClock]

Changing IDEX modes only works properly from the LCD.

when using the g-code command M605 S ... carriers collide with each other and do not park as they should.

[wartness]

My problem is the same as above! At M605 S1 the two carriage took each other positions . When i send the code T0 to the printer, than the T1 goes to parking position and T0 took the actual position. This is working after start up. But when the Z axes goes to Home, the position exchange is not working anymore. During printing the T0 is working , when the T1 command is sent the T0 is stops and T1 is collide with it. ( T0 is not going to parking position. )

[DrumClock]

Due to minimal responses to solving this problem, I closed this issues. The bug is still at 1.7.2020 in Marlin FW.

[DrumClock]

I tried this setting:

Board: 		RUMBA - ATmega2560
Controller:	LCD Full graphic 128x64 pix.
Marlin: 	bugfix-2.0.x
Downloaded:	27.6.2020 at 15:17 (Prague) 
Compiled:	Visual Studio Code 

 #define X1_MIN_POS  0   
 #define X1_MAX_POS  240          
 #define X2_MIN_POS  0             
 #define X2_MAX_POS  240 
 #define X2_HOME_DIR   1           
 #define X2_HOME_POS 292

 #define DEFAULT_DUAL_X_CARRIAGE_MODE DXC_AUTO_PARK_MODE
 #define DEFAULT_DUPLICATION_X_OFFSET 120 

AUTO_PARK mode on LCD

• the movement of the carriage X1 is limited between 0 and 240
• the movement of the carriage X2 is limited between 0 and 292
  setting X2_MAX_POS has no effect on carriage X2 movement - always goes to X-max endstop
• tool change T0 and T1 is exact according. HOTEND_OFFSET_X = X2_HOME_POS

DUPLICATION and MIRRORED modes show the same errors as described previously.
With this setting, X2_HOME_POS has a gap between carriages of 198 mm and collisions occur.
Change the DEFAULT_DUPLICATION_X_OFFSET setting does not affect the gap between carriers.

[DrumClock]

Hi, @thinkyhead
please write what I should change and test.
Thanks you very much.

[thinkyhead]

Please don't @ me. I eventually find issues, but there is always a large pile.

[thinkyhead]

The motion bugs resulting from calls to M605 need to be looked into.

For testing turn on DEBUG_DXC_MODE and include a W flag in your M605 commands. With the W flag, Marlin will print verbose output to the host console. Try various values with M605 W S2 Xnnn and note the differences.

In the meantime I will look at what M605 is trying to do, and perhaps there is a simple inverted logic bug that can be fixed quickly.

[DrumClock]

For testing turn on DEBUG_DXC_MODE and include a W flag in your M605 commands.

How do I activate DEBUG_DXC_MODE ?

[thinkyhead]

How do I activate DEBUG_DXC_MODE ?

Add this to your config:

#define DEBUG_DXC_MODE

Looks to me as though the bugs are located in tool_change and/or dualx_tool_change. So, get the latest code and also enable DEBUG_TOOL_CHANGE before testing.

[DrumClock]

Ok, I set in configuration.h

#define DEBUG_DXC_MODE
#define DEBUG_TOOL_CHANGE

In pronterface, all you have to do is send it via the M605 W S2 Xnn
terminal and I will copy the statement to you.

[DrumClock]

Still the same .... the M605 command via the pronterface terminal does not work.
DUPLICATION and MIRRORED modes via LCD ... gap between carriages still 198 mm.

Extract from pronterface terminal:
DXC_pronterface.zip

[DrumClock]

Hi @thinkyhead
Does anyone solve this problem?
How do I know, please?
I would very much like to provide more information.

Thanks

[boelle]

How do I know, please?

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

[DrumClock]

Hi @boelle

Nothing has changed since I made a mistake on May 10.

In the DUPLICATION and MIRRORED modes, there is still a gap of 198 mm between the cars.

[DrumClock]

Bug still not fixed.

[boelle]

Bug still not fixed.

Marlin is free, you dont pay for it

Is it fair to demand anything?

Things take time arround here, if you cant live with that there are other firmwares

[DrumClock]

Hi @boelle
YES Marlin is free but is starting to have more and more bugs that were not there before.
I think I tested and provided the information you requested, but I have no feedback, is it being worked on?
I'm sorry the most, I'm trying to help but I dont have the answer .....

[boelle]

the maintainer of the project @thinkyhead is the man

[InsanityAutomation]

Attach you're config files and I'll see what it gives me. As for calculating that number, the pstr area can't mix static and calculated strings without being pushed to sram. Die to memory constraints in most boards we only do that when absolutely necessary. The first move of the print should make that irrelevant though.

[DrumClock]

Hi @InsanityAutomation
I thought of adding to Configuration_adv.h settings for MIRRORED mode:

// Default x offset in mirrrored mode (typically set to print bed width)
#define DEFAULT_MIRRORED_X_OFFSET X_BED_SIZE

// Set the maximum so that the first X-carriage cannot hit the second X-carriage
#define X_MAX_MIRRORED_POS  95 

So when selecting MIRRORED mode from LCD or M605 S3, carriages is set to X1 = 0
and X2 = X_BED_SIZE while maintaining the "G1X0" command.

GCODES_ITEM(MSG_IDEX_MODE_MIRRORED_COPY, need_g28
      ? PSTR("M605S1\nT0\nG28\nM605S2\nG28X\nG1X0\nM605S3") // If Y or Z is not homed, do a full G28 first
      : PSTR("M605S1\nT0\nM605S2\nG28 X\nG1X0\nM605S3")

X_MAX_MIRRORED_POS to restrict movement to avoid collision of carriages

[sjasonsmith]

@DrumClock this is all being done in spare time, and competes with "normal life" priorities. It is unreasonable to expect people to drop everything to work on uncommon features on your timeline. I am sure you could find people to prioritize it for some money, but you would probably have to add some zeroes to the offer. You might be able to find some people to prioritize it in exchange for a printer to use as a test bed.

[DrumClock]

Hi @sjasonsmith @thisiskeithb
If I have offended someone by my attempt to remove IDEX errors, I am very sorry.

Here I pointed out errors in IDEX modes 6 months agoand nothing happened until I tried to offer $ 20.
Unfortunately, only half of the bugs have been fixed, and since then there has been no response as to whether this continues.

I also work and 3D printers are my hobby. I build and improve them
(I also put it on thingiverse.com for free) and so I find bugs in the FW.

There is no feedback that eg issues # 2947 opened on 30 Jan 2016 is resolved, I'm quite sorry.
Then I can't be surprised that there are so many bugs open. And there is no time to deal with it.

[DrumClock]

You might be able to find some people to prioritize it in exchange for a printer to use as a test bed.

Why donate a printer now?

This "test frame" https://www.youtube.com/watch?v=WkDNu3AFBKM where you can try everything I built from leftovers in 3 hours. Perhaps anyone who is interested in 3D printing can do more than just "for printing" ....

[sjasonsmith]

The reason for my reply is the impatience. Not many people work on IDEX features, mostly because almost nobody has IDEX printers! I considered buying a printer to help you, but I would have to spend $400 for the cheapest IDEX printer around, and I already have other bugs I can work on.

As it happens, the one person really able to help you right now is just super busy, and has been all year. If you really want to propel IDEX support forward, I suggest you learn to work in the code and contribute some fixes yourself!

[sjasonsmith]

You should send people some of your test frames if you want them to help :)

[DrumClock]

Believe me, if I can program, I will be happy to help you.
Unfortunately, I don't even speak English, so I use a translator.

Someone can program and some can't, even if they want to.
For me, mechanics, electronics and inventing improvements are not a problem.

[sjasonsmith]

Your test bench looks interesting. Do you have plans for it somewhere, or is it completely custom and one of a kind?

[DrumClock]

Your test bench looks interesting. Do you have plans for it somewhere, or is it completely custom and one of a kind?

It's built the way I thought. You don't need a 3d printer to verify the function.

[InsanityAutomation]

The $$ incentive was irrelevant really, and can just donate it to the marlin funding if you want. Request came in when I happened to have 30min to poke at it so I happened to see it and hit it quick. The other half needs more than a passing time investment so it'll need to wait till I'm working less than 60 hours a week. Unfortunately I've been slammed since covid put everything behind.

[DrumClock]

The other half needs more than a passing time investment so it'll need to wait till I'm working less than 60 hours a week.

Hi @InsanityAutomation
Thanks, $ 20 I donate funding to Marlin.

I found other bugs in IDEX modes, especially in X shift restrictions.
Should I post them here or start new issues?

[InsanityAutomation]

Either way is fine with me, if you open new ones tag me. If they're quick I may nab em between things.

[DrumClock]

Hi @InsanityAutomation
I thought of adding to Configuration_adv.h settings for MIRRORED mode:

// Default x offset in mirrrored mode (typically set to print bed width)
#define DEFAULT_MIRRORED_X_OFFSET X_BED_SIZE

// Set the maximum so that the first X-carriage cannot hit the second X-carriage
#define X_MAX_MIRRORED_POS  95 

So when selecting MIRRORED mode from LCD or M605 S3, carriages is set to X1 = 0
and X2 = X_BED_SIZE while maintaining the "G1X0" command.

GCODES_ITEM(MSG_IDEX_MODE_MIRRORED_COPY, need_g28
      ? PSTR("M605S1\nT0\nG28\nM605S2\nG28X\nG1X0\nM605S3") // If Y or Z is not homed, do a full G28 first
      : PSTR("M605S1\nT0\nM605S2\nG28 X\nG1X0\nM605S3")

X_MAX_MIRRORED_POS to restrict movement to avoid collision of carriages

Start new issues well.

Here I will leave this MIRRORED mode to completion.

[DrumClock]

Hi @InsanityAutomation
please automatically set the new value DEFAULT_MIRRORED_X_OFFSET (X_BED_SIZE) when selecting M605 S3.
Now the valueDEFAULT_DUPLICATION_X_OFFSETis set which is wrong.

[DrumClock]

HI @InsanityAutomation
MIRRORED mode behavior unchanged.
Tested on bugfix-2.0.x release 2021-01-03.

[DrumClock]

Hi @InsanityAutomation
could you please fix the MIRRORED mode?

[github-actions]

This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days.

[DrumClock]

Still not solved

[InsanityAutomation]

I am going to make a few things perfectly clear.

First off, you need to understand the difference between actual bugs (Things that don't work) and enhancements (new functionality, added safety protecting users from themselves, automating tasks). Bugs have bee squashed. Feature requests have been left to sit until there is time to deal with them.

There have only been 2 of us who have worked on anything IDEX over the past 2-3yrs. Take a look at my commit history over the past year since Covid, then take a look at the year prior. Quite simply this whole situation has turned life completely upside down between my day job industry being explosively busy to respond and having to do school at home with my kids and everything else. What you've offered as cash incentives wouldn't even buy you 15 minutes of my time on a commercial scale. I'm busy with Tier 1 automotive manufacturers and if you want to take my time from them, you need to be competitive. That simple.

Ive kept checking in and kept issues from closing when I could because I do feel they are good suggestions for features and the actual bugs you have reported were well traced. Nobody is arguing that point. As for the feature requests, the OEM's I deal with who make IDEX machines don't view them as major issues. They configure a separate slicing profile limiting the X size for duplicate and mirror mode so the issue of limiting head movement isn't seen. That drops it to a nice to have. I'm struggling enough keeping up with commitments that I don't have time to chase anything extra. And Ill be perfectly honest, the attitude shown dropped it even farther down my list.

I may still get to some of these eventually. But not until I can hire help at the day job to lighten the load. Unfortunately everyone in town is trying to hire for the same reasons.