@omni @kordris I got mine working with the following settings:
M591 D0 P7 C"ystop" L7 R80:115 E8 S1
What caused problems with my setup was that I've used an endstop pin from an axis where sensorless homing was enabled. Switching to an endstop without sensorless homing solved it for me.
I am using a third party controller board with a STM32 chip structure. I don't know if that has any impact on the error that I had but this might also help you if you are using an original Duet board.
@jay_s_uk Thank you very much for this incredibly swift reply. I will give this a try and come back with the result!
@dc42 I would also be interested in such a feature for safety reasons for our customers.
@jay_s_uk That worked perfectly, thank you very much!
@droftarts Thank you very much Ian for your elaborate answer. That solved it!
I've chosen the easy route and used I_O4 and I_O7 and they are working perfectly now.
@dc42 Have you already had a chance to look into this topic? Please let me know if you need any additional information; I’ll be happy to provide any necessary feedback.
Thank you very much!
@droftarts Hi Ian,
Have you had a chance to have a chat with @dc42 yet?
@droftarts I understand that mapping the axis is nesscecary for keeping the gcode simple. But with this odd behaviour it is not usable for controlling the axis manually via the jogging buttons as described above when implemented in the config.g in combination with the described problems. That is why I have implemented this before a print starts in a macro so that I can control both axis with the applied limits in "manual mode" without crashing the tools. Applying these limits is just a workaround.
There might be a couple of misunderstandings because I initially thought when the U axis isn't hidden, jogging X when tool 1 is selected moves the X axis and jogging U moves the U axis, which is apparently not the case when U is mapped to X. But having two jogging controls which can produce unpredictable movements when mixed up seems like an unsafe choice which makes this option not feasible.
Hiding the U axis makes the printer dysfunctional when tool 1 is selected, that is why I implemented the described workaround. I would much rather use the hiding feature, that would also make the workaround redundant.
Regarding updating the position when T1 is moved via an X command with M400 would only be possible when this is done automatically or otherwise the users might forget that and get unexpected behavior.
Here is my M115 output:
FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6XD FIRMWARE_VERSION: 3.5.2 ELECTRONICS: Duet 3 MB6XD v1.01 or later FIRMWARE_DATE: 2024-06-11 17:13:17
The X and U axis are conntected to 1HCL boards (I have 4 in total).
@droftarts I figured out a way easier and cleaner solution.
In "idle" mode (not printing), when for instance tool 0 is selected, I limit the minimum and maximum travel of the second axis (U) to a couple of mm's around the parking position. I do the same when tool 1 is selected but then limit the X axis in the same manner.
I do have to alter a couple of homing files and some other macros, but this works exceptionally well. I can only fully move one axis at a time when selecting tool 0/1.
Before printing, I change the limits to the original values and everything is back to normal.
After printing, I got back to the limits as described above (this gets handled through custom macros and a bit of conditional Gcode).
During this process, I stumbled on something that seems like a bug or maybe some missing information. In the IDEX configuration wiki, it is stated that when a tool uses the U carriage for X movement it needs an X3 parameter in the M563 command.
I did implement this in the config.g (because this printer is only designed to use one tool at any given time) and now I realized that this should be rather implemented in the slicer Gcode or a custom macro which gets executed before each print.
Implementing this in the config leads to really strange behavior. When tool 1 is selected, no matter if I move X or U, it always moves the U axis. If I move "X" first, the U-axis moves the asked amount. If I then move the "U" axis, it firstly goes back to the position it was before the X move and then moves the requested amount.
So should a IDEX machine be setup like this (basic example):
M563 P0 D0 H1 F1 ; tool 0 uses extruder 0 and heater 1 and fan 1
G10 P0 X0 Y0 Z0 S0 R0 ; set tool 0 offsets and temperatures
M563 P1 D1 H2 F2 ; tool 1 uses extruder 1 and heater 2 and fan 2
G10 P1 X0 Y0 Z0 S0 R0 ; set tool 1 offsets and temperatures
and mapping the second axis to different conditions ( one tool, mirror mode...) should be done in the slicer?
If this is the case, could this information be added to the wiki page (if you also think this is usefull)?
@droftarts but that would mean that when tool 1 is selected and U is visible, X would also be visible and one could manually jog X or U until the tools crash into each other? That would also pose a potential crash with the bed as the tools can have different heights.
My aim is it to only be able to move one (X) axis manually at a time:
If tool 0 is selected: only the X-axis can be moved via the jogging buttons.
If tool 1 is selected: only the U-axis can be moved via the jogging buttons.
The machine will be used in a professional environment with different users and I want to avoid that one could crash the tools into each other or into the bed as they can have different Z-heights.
The users will not use Gcode for manual movement but definitely the jogging buttons on the DWC.
Would it be possible to hide the X-axis when tool 1 is selected?
If not, would it be possible to write a plugin that controls every incoming G1 command while not printing and does something with that?
@droftarts Hi Ian,
thank you for your swift reply.
That seems doable but if I understand this correctly, I would not be able to move the U-axis when tool 1 is selected and the U-axis is hidden with M584 P3? So I have to display U and X when T1 is selected because I have to unhide all axis?
That would unfortunately defeat the purpose of the safety feature as the user should only be able to move one tool at a time and this would only be available on tool 0 when hiding the U-axis if I understand that correctly.
Can this be achived through changing the axis mapping when swapping tools i.e. mapping U as X and X as U when switching to tool 1?
Like this (swapping X and U):
When tool 0 is active:
M584 X1.0 Y0.0:0.1 Z0.2:0.3:0.5:0.4 U3.0 P3
When tool 1 is active:
M584 X3.0 Y0.0:0.1 Z0.2:0.3:0.5:0.4 U1.0 P3
I have a gut feeling that this might be not the best solution as I fear that this will interfere with offsets and other stuff
This would also require me to switch tools when homing X and U is requested for instance.
Though this would only need to be done when no print job is running so I could basically use the standard setup while printing and only swap the axis mapping when controlling the machine manually.....
@droftarts Hi Ian,
I've implemented your suggested solution, but unfortunately it does not work as intended or I misunderstood the way it should work. It apparantly seems that it disables the selected axis and not hide it.
When I put the following code in my config.g, I am not able to home the U-axis when tool 0/1 is selected.
M584 X1.0 Y0.0:0.1 Z0.2:0.3:0.5:0.4 U3.0 P3 ; set axis mapping, hide U-axis (P3)
I thought that this only hides the jogging buttons and I can still move the U-axis through G-code if needed.
When I then switch to tool 1, I am not able to move the U- or X-axis. Only X, Y and Z are displayed. Moving X results in no movement of the axis but the position in the DWC changes which is also quite strange. Trying to use M584 P0 thinking that this hides the X Axis and shows the U-axis again only results in an error (invalid number of visible axis).
Do I need to set a new axis mapping every time I switch the tools (which would probably mess up my Z-offsets)?
Am I missing something else?
Do I have to run the tool changes script when homing all axis to be able to home X and U?
Thanks in advance.
@droftarts that is true and I also have it setup this way. But with the standard configuration without the P3 addition one could move the tools into one of those overlapping areas manually and that would result in a crash. But that is fixed with hiding the second axis and setting up the tool change scripts accordingly as you suggested. I was just missing this last piece of information.
Thank you very much 
@droftarts Hiding the additional axis sounds like exactly what I need.
Thank you very much for this clean solution, I am going to implement this next week as I have no access to the printer right now.
That would also solve the problem with the difference in Z height as each tool gets probed when the axis are homes and then switching the tools also takes the offset into account, awesome!!
Would it be possible to add this information (hiding one axis in the DWC) to the wiki page of the IDEX setup? I think that this is generally a quite usefull information.