3.5.0 rc4: weird homing behaviour in IDEX copy or mirror mode

oliof

@NeoDue homing works for me as I expect, and I home before choosing any tools.

Remember that you home axes not tools, so if you home before dallying with tools you can experiment with G28 X and G28 U before selecting tools.

Also, please note that in my setup, X homes towards minimum of axis andl U homes towards maximum of axis.

NeoDue

@oliof same here - I wonder if there are any IDEX printer that home the second hotend on the lower end of the axis The only thing that differs significantly in that part of our setups (apart from the obvious axis limit values...) is that z homes at z_max in my printer as well.

@oliof said in 3.5.0 rc4: weird homing behaviour in IDEX copy or mirror mode:

@NeoDue homing works for me as I expect, and I home before choosing any tools.
Remember that you home axes not tools, so if you home before dallying with tools you can experiment with G28 X and G28 U before selecting tools.

Ah, okay. I need to make sure I can home at any time. For example, I have to home (or rather the filament load script does it) if I want to load filament since I need to move the print heads to a specified position before doing that.

oliof

@NeoDue I could have homed the second tool to the first, but that's not a fixed target in space and I would always need to home or at least position the first tool, seems like an unneccessary complication.

I can home at any time since the tools move in opposite directions for homing. I just rarely need to do it while the machine is in use. If your printhead can move within the homed axis area, I dont see why you would need to rehome unless you manually move it in X for the filament change.

NeoDue

@oliof the filament change is not the only case. I rehome as well for any of the calibration routines I have, for cleaning the nozzles etc. All that is started via a button on the PanelDue. Whenever some move is done, I want to be sure that the print heads neither collide with the bed nor with themselves, and I automatically turn off the steppers after a while. Therefore: homing is good, and the printer shall be able to do that in any case. (That is the big advantage of having the z endstop sensor at z_max.)

Anyway: now that the homing macros are corrected, homing spits out the same values each time. Now I need to find out why the x and u carriage switches to the wrong values for copy and mirror. Let's see if your config helps me with that

NeoDue

@oliof @T3P3Tony I went through this now step by step, starting with the standard tools (with and without offset) to verify my view on "tool offset" vs. "axis position" is correct, which I found it is.

Then I went on with a standard Copy tool as T2, and here I found some things that I do guess to be (albeit not function-critical, apart from the last one) bugs, and these were the ones that had driven me off the right track initially:

if you home the printer correctly (i.e. without tools selected, not the stupid thing I did above...🫣) and then just switch to the Copy tool, the Duet gives out strange positions of X and U until you actually move the new tool for the first time. That initial calculation seems take the position of X and the position of U relative to X0Y0, adds a possible tool offset to both values, creates the sum of both, divides the result by 2 and calls that the position of X, while the U value correctly stays as it is. If it had not changed at all, I would have concluded that you must move the axis to get a change, but since it changed to unlogical values I guessed wrong.
Now if you do that for a symmetric position and symmetric tool offsets (simple example: position of X hotend at X-150 and U hotend at U150, tool offset 0 for both) you get "0" for X in any case which does not fit at all.
as soon as you actually move the tool, it will move to where it belongs but will not reliably update the displayed U position any more. Sometimes it updates U, sometimes the U value just stays the same (if I can find some logic behind the behaviour, I will add this).
axis limits are not obeyed consistently. Sometimes I do get a message "Error: G90: intermediate position outside machine limits", but if this occurs, it is once at max. As soon as I have confirmed the message, I am free to crash the hotend anywhere I like, until the next homing procedure is started. It seems to make a bit of a difference there if if I use many small motion steps (repeatedly tapping 1mm or 0.1mm on the PanelDue) instead of a large one. Remark, in case it matters: Tested with the U hotend, i.e. on the upper end of the x axis.

dc42

@NeoDue said in 3.5.0 rc4: weird homing behaviour in IDEX copy or mirror mode:

f you home the printer correctly (i.e. without tools selected, not the stupid thing I did above...🫣) and then just switch to the Copy tool, the Duet gives out strange positions of X and U until you actually move the new tool for the first time. That initial calculation seems take the position of X and the position of U relative to X0Y0, adds a possible tool offset to both values, creates the sum of both, divides the result by 2 and calls that the position of X, while the U value correctly stays as it is.

That is correct. When using the copy tool, user X is mapped to both machine X and U. When the positions of machine X and U are inconsistent with the mapping, RRF takes an average to calculate user X, and that is what will be displayed when DWC is displaying user coordinates. The U axis is not mapped so its displayed position is independent of where the machine X axis is. You may wish to include a command such as G0 X0 F6000 in the tpost file for the copy tool.

@NeoDue said in 3.5.0 rc4: weird homing behaviour in IDEX copy or mirror mode:

As soon as you actually move the tool, it will move to where it belongs but will not reliably update the displayed U position any more. Sometimes it updates U, sometimes the U value just stays the same (if I can find some logic behind the behaviour, I will add this).

Interesting. If the U head actually moves then I would expect the displayed U position to be updated too.

@NeoDue said in 3.5.0 rc4: weird homing behaviour in IDEX copy or mirror mode:

axis limits are not obeyed consistently. Sometimes I do get a message "Error: G90: intermediate position outside machine limits", but if this occurs, it is once at max. As soon as I have confirmed the message, I am free to crash the hotend anywhere I like, until the next homing procedure is started. It seems to make a bit of a difference there if if I use many small motion steps (repeatedly tapping 1mm or 0.1mm on the PanelDue) instead of a large one. Remark, in case it matters: Tested with the U hotend, i.e. on the upper end of the x axis.

I think there may be two issues here:

To prevent the X and U heads crashing into each other, you will need to reduce the X axis upper limit and increase the U axis lower limit using M208. You can do this in the tpre or tpost file for the tool. Restore them to normal in the tfree file for the tool.
Even without using M208, RRF should prevent you sending X below the low endstop or U beyond the high endstop. If that's not working, it sounds like a bug in RRF.

NeoDue

@dc42 thanks a lot for the hints!

One suggestion, if I may: it might be worthwhile including those notes in https://docs.duet3d.com/User_manual/Machine_configuration/Configuration_IDEX for other users.

@dc42 said in 3.5.0 rc4: weird homing behaviour in IDEX copy or mirror mode:

Even without using M208, RRF should prevent you sending X below the low endstop or U beyond the high endstop. If that's not working, it sounds like a bug in RRF.

Yes, that does indeed feel like one since the message does pop up but it is unreliable. I guess other tasks are more important right now when to comes to filling your schedule with tasks, but if I can help with that one, please do not hesitate to ask

Edit: by the way, the heads crashing into each other seems to be counteracted by the toolhead distance defined with G10. The Duet tries to keep that one - at least until one hotend is stopped by the end of the rail after it ignored the endstop switch.

dc42

@NeoDue I've taken a look at the code and I think the current behaviour regarding axis limits should be as follows when you use the copy tool, assuming that you don't change the M208 limits:

If you try to move to an X coordinate that would be below the X axis minimum, that should be detected and the move should be limited to the reachable X axis minimum (which is normally where the homing switch triggers).
However, if you try to move to an X coordinate that would move the U head to a point beyond the high stop, that will not be detected and limited; but after the move starts you might get a "intermediate position unreachable" error.

Is that the behaviour that you see?

NeoDue

@dc42 said in 3.5.0 rc4: weird homing behaviour in IDEX copy or mirror mode:

@NeoDue I've taken a look at the code and I think the current behaviour regarding axis limits should be as follows when you use the copy tool, assuming that you don't change the M208 limits:

If you try to move to an X coordinate that would be below the X axis minimum, that should be detected and the move should be limited to the reachable X axis minimum (which is normally where the homing switch triggers).

Yes, the X carriage obeys the x axis limit. If I let the tool run into this limit using the PanelDue, the U carriage does behave a little strange: instead of strictly keeping its defined distance (in my case 150mm) from the X carriage as I would suspect, you can move it closer to the X carriage for an additional four moves after the X carriage has stopped moving - and how close you get, depends on the travel you want to make with these moves:

if I move in 10mm steps by pressing "-10" on the PanelDue, I end up with about 130mm distance between the nozzles after four motions
if I move in 1mm steps, I end up with about 148mm distance between the nozzles after four motions
if I move in 100mm steps, I end up with just about 55mm distance between the nozzles after one motion (and I did not dare trying what happens if I press the button again, most probably the carriages crash into another)
if I start a lower motion step after a higher one (e.g. pressing "-100" once and then "-10", the U carriage moves into the opposite direction of what you would expect it to on the second button press,

The value of the U axis is not updated on moves where the X carriage is moved as well, but it is updated on those weird additional moves by the way. The value of U is somewhat random though, and even of you move back to where the X carriage moves as well, the U value keeps showing values that are off by up to several mm. I can use that as a random number generator

However, if you try to move to an X coordinate that would move the U head to a point beyond the high stop, that will not be detected and limited; but after the move starts you might get a "intermediate position unreachable" error.
Is that the behaviour you see?

Not fully - I just played a bit more with it to be sure:

if I start a move that would move the U head to a point beyond the high stop, the Duet shows me an "intermediate position outside machine limits" error before the move starts - but it does so only if I press the 10mm button (again, I do not dare pressing the 100mm button since that will probably end up with the U stepper stalling which then will cause the Duet to burn its coil. Those Mocotech steppers are weird).
If I use 1mm steps however, the machine ignores the upper limit right away in most cases, but sometimes the message does pop up there as well.

Edit: if it helps, I can share a video showing this.

dc42

@NeoDue thanks. I was able to include one quick fix in the 3.5.1 release: the U axis upper limit should now be honoured.

NeoDue

@dc42 3.5 has gone stable AND you already managed to fix that??

Thanks a lot - and congratulations! That was some really hard work for you and the whole Duet team! If I remember correctly, 3.5. had the longest beta / RC phase of all the RRF versions I saw and used in the last seven or so years.

(edit - after upgrading the printer yesterday, I just took the chance to test the updated function: crash detection works, and now U behaves exactly as X did - i.e. U does not crash into the endstop any more, but the X carriage ends up at places where it should not go. But that bug is just an inconvenience, not critical for the printer)