Limit manual travel on IDEX depending on the U axis position

[semi55]

@semi55 what is even more odd is that the calculated keepout zone is only applied to the minimum side, the maximum side is always -0.0 .
I have moved the U axis to U0 to demonstrate this behavior as seen in the image below:

[dc42]

@semi55 M599 is intended to set up static keeping zones, for example in config.g. so I'm not surprised that it doesn't work well when used in daemon.g.

There is also M597 but it was intended for use with multiple motion systems; so it may not work in a single motion system.

[semi55]

@dc42 Is M597 intend to work during a print job only or is this also checked when moving the axis manually?

[semi55]

@dc42 Would it be possible to use motor stall detection (M915) if nothing else is possible?
Both axis run on a 1HCL expansion board with TMC2160A controlling a Nema23 3Nm stepper motor.

That wouldn't be the most cleanest solution but better than the toolheads crashing into each other and damaging the machine in the process.

EDIT: just read some Wiki pages and saw that stall detection on CAN-FD expansion boards isn't yet supported and will probably supported with the release of 3.6.
Are there any plans on this yet?

[droftarts]

@semi55 Going back to the original question, usually on an IDEX when you have all axes homed, you limit the axis maximum of the first tool (that uses X) so that it can't reach the U carriage. Similarly, you limit the U axis so it can't reach the X carriage. Ideally, both carriages home off the bed, and can reach the edge of the bed on each side, so you'd set something like M208 X-50:200 U0:250. You then hide the U axis in DWC so it can't be moved unless the tool is selected, with M584 P3 (only shows XYZ, not U). Then make sure on your tool changes that the relevant carriages is parked out of the way of the other carriage.

See https://docs.duet3d.com/en/User_manual/Machine_configuration/Configuration_IDEX#setting-up-the-tool-change-files

Ian

[semi55]

@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.

[droftarts]

@semi55 said in Limit manual travel on IDEX depending on the U axis position:

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.

Okay, will add to this section: https://docs.duet3d.com/en/User_manual/Machine_configuration/Configuration_IDEX#configuring-new-axes
This actually contains a part about setting the axes not to overlap:

In this example, the X carriage moves along the X axis from -50 to 200 and the U carriage moves from 0 to 250. So there is a printable zone accessible to both carriages from 0 to 200.

Ian

[semi55]

@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

[semi55]

@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]

@semi55 M584 P4 will show all axes (XYZU), while M584 P3 will hide the last axis U. Yes, I think you will need to un-hide the U axis, with M584 P4, to home it (so in homeu.g), and during tool changes if you command the U axis directly, in your tool change macros. Then hide it again afterwards, with M584 P3, when you switch to a different tool. For guidance on tool change macros, see https://docs.duet3d.com/en/User_manual/Tuning/Tool_changing

I have not tested the scenario where an axis is mapped to X and then hidden, and it may be that you need to have the axis showing when it is mapped. This should be okay, as the other tool on X should be out of the way. It would only be jogging the U axis independently that may cause it to be out of position, and potentially cause a crash. Let me know if that resolves the problem.

Ian

[semi55]

@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]

@semi55 I think you can handle this by making the U axis visible at the beginning of homeu.g with M584 P4, then hide it again at the end with M584 P3.

You also want U visible when Tool 1 is in use, so you add M584 P4 to the beginning of tpre1.g (the macro called when T1 is selected). You hide U again with M584 P3 at the end of tfree1.g, when the tool is released, which also unmaps it from X. I think moving the U axis when tool 1 is active affects the X axis as well, but you'd need to check that.

Anytime you change tool, you want the tool that's being released to go to it's parked position, which should be unreachable by the other tool. You do this in the tfree#.g macro, where # is the tool number. See https://docs.duet3d.com/en/User_manual/Machine_configuration/Configuration_IDEX#setting-up-the-tool-change-files for examples.

Unfortunately, I don't have an IDEX setup to test exactly what happens. But people have been running IDEXs for a long time without encountering crash issues.

Ian

[semi55]

@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?

[semi55]

@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]

@semi55 I think you're over-thinking and over-complicating this. The whole reason to map the U axis to X is because slicing software rightly abstracts the use of tools away from what axis they actually run on. That enables slicer Gcode to be more generic, and the actual configuration and control of tools is handled by the firmware running on the machine, as it should be. None of the 'normal' slicers, as far as I'm aware, can output Gcode that targets axes other than X, Y, Z and E, and can only output tool change commands as needed. It's up to the machine configuration to interpret these.

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.

I think you are misunderstanding this. When tool 0 is selected, the normal X limits are applied, and jogging X moves tool 0. When tool 1 is selected, the U axis limits are applied to X, and jogging X moves tool 1. Tool 0 won't move. Tool 1 won't hit Tool 0 if the M208 U axis limits are set correctly, because they are mapped to X. While the U axis jogging buttons may be visible, I don't actually know what jogging the U axis would do, but I think it achieves the same thing as jogging X. When moving/jogging X, the U position is slow to update, as updating U on each move would be unnecessary overhead. U can be updated at the end of an X move with M400.

Would it be possible to hide the X-axis when tool 1 is selected?

First, you don't want to because you need it to control both tools, and second no, it's not possible. The M584 P parameter can only hide axes starting from the last axis created.

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 think this is okay, but largely unnecessary. The other tool isn't going to move. Tool 1 might possibly move if the U axis jogging buttons are available when Tool 0 is active, but this has already been dealt with by hiding them.

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.

That's correct. It's the only way to map one axis to another without re-configuring the axes with M584, which would cause other problems (deactivate axes, requires homing afterwards etc).

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.

You can, but I think it's not advisable.

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.

That's the intended behaviour. You mapped U to X. Moves in X move tool 1, which is on the U axis. Their movements are synchronised.

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.

This is possibly to do with what I described earlier, that the tool position on the U axis is not updated when it is mapped to the X axis. If you send M400, it should be updated.

So should a IDEX machine be setup like this ...

If you do this, selecting tool 0 then moving in X will move tool 0 in X. But selecting tool 1 and moving in X will cause tool 0 to move in X; tool 1 won't move, because it is connected to the U axis, and you haven't told the U axis to move, either by sending a G1 U command, or by mapping it to X. All it knows is that tool 1 uses a different extruder drive, heater and fan, not that it uses a different axis.

and mapping the second axis to different conditions ( one tool, mirror mode...) should be done in the slicer?

Apart from the problem I described above (i.e. you can't move tool 1) I think setting up the tool modes in the slicer will be more confusing, and require more maintenance and support than setting it up in config.g.

I think the only possible issue/potential bug is that you reported when the U axis is hidden all the time (except homing), when tool 1 is in use (i.e. U is mapped to X) that you get no movement when sending a G1 X... command. I thought hiding axes didn't stop them moving. I'll have to test this, and check if it is expected behaviour.

Can you confirm what hardware you are using, and which firmware version you are testing this with? Send M115 and post the response.

Ian

[semi55]

@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]

@semi55 I think the best solution would be to hide the U axis all the time. I'm checking with @dc42 if there's a bug in this part, or a workaround. Hiding U is the best option; then only one tool will move at a time using the X jog controls, and when the tool is deselected, use tree#.g to send it to its home position, so the other tool can't reach it.

The other option would be for DWC to send M400 after the jog command, if the U axis is jogged instead of X when tool 1 is selected. But this may cause stuttering if the jog button is pressed multiple times, as M400 would cause the axis to stop after each command.

Anything else will be a support problem for you, and prone to user error (eg selecting wrong machine configuration when slicing) especially having to set up a slicer with custom codes to configure the tools.

Ian

[semi55]

@droftarts Hi Ian,
Have you had a chance to have a chat with @dc42 yet?

[droftarts]

@semi55 I have highlighted it. He’s rather busy with RRF 3.6 at the moment!

Ian

[semi55]

@droftarts ok thank you very much!