Possible bug observed after V3.3 to 3.4.1 update

AstroSmoke

Hi, I have observed a possible bug after updating from 3.3 to 3.4.1

I just updated software on Duet 3 MB6HC + SBC combinations from 3.3 to 3.4.1 on two 3D printers, both (RatRig CoreXY 3) based systems.

These printers are in a private (University) network with no internet exposure, so the updates were performed by re-imaging the SD card with the latest download revision listed as 3.4.1.
I used this file, imaged with the Raspberry Pi software, https://pkg.duet3d.com/DuetPi-lite.zip
I also observed the systems after the immediate boot-up had mixed environments of 3.3 and 3.4.1, this was solved by running M997 to force the SBC update as suggested on these forums.

The possible bug

The odd behavior was observed on both machines.

During Homing X and Y, individually and as XYZ home all, the second bump sequence was moving oddly.
In detail, observing Home X, the movement to the end stop works as expected.

G1 H1 X-625 F3600       ; Move quickly to X endstop and stop there (first pass)

However, the minor move for the bump moves unexpectedly.

G1 H2 X5 F600           ; Go back a few mm
G1 H1 X-625 F360        ; Move slowly to X endstop once more (second pass)

What was observed was the main carriage slowly moved in the +Y direction during the move-out and return to the second end stop activation.

Home Y also has the same drift in +Y, but the observation is no movement in -Y actually is performed as there is unwanted drift in +Y at the same time.

I solved the immediate problem as the example below by removing the H2 from all homing instructions, however, I suspect this isn't the intended behavior or long-term solution.

echo "Home X"
M201 X500.00 Y500.00    ; Reduce acceleration for homing moves

G91                     ; Relative positioning
G1 H2 Z5 F6000          ; Lift Z relative to current position

G1 H1 X-625 F3600       ; Move quickly to X endstop and stop there (first pass)
G1 X5 F600              ; Go back a few mm
G1 H1 X-625 F360        ; Move slowly to X endstop once more (second pass)

M201 X3000 Y3000        ; Return to full acceleration

G1 H2 Z-5 F6000         ; Lower Z relative to current position
G90                     ; Absolute positioning

G4 S3
echo "Home X Complete"

Supporting files, M122 console and system files.
Notes:
H2 has been removed from the homing files.
T0 was added to the config file to allow movement of the tool head extruder(is this a bug as well?)

console.txt
bed.g
config.g
deployprobe.g
dwc-settings.json
homeall.g
homex.g
homey.g
homez.g
pause.g
PrimeNozzle.g
resume.g
start.g
stop.g
trigger6.g

dc42

@astrosmoke G1 H2 moves are defined as individual motor moves. On a CoreXY machine an individual move of the X motor will move both X and Y. So if you want to move just X by +5mm using a G1 H2 move, you need to use this:

G1 H2 X2.5 Y2.5

(I think those X and Y values are correct, but I don't have a CoreXY machine up and running to test it on at present). To move the Y axis by +5mm you would use Y-2.5 instead of Y2.5.

If the axis has definitely been homed at that point then you can instead just omit the H2 parameter as you have done.

AstroSmoke

@dc42

Sorry, but I think you have misunderstood the issue I observed.

The problem is, whilst the motion moves in the X-axis only, Y-axis was also drifting in the plus direction.

This did not happen with the first move to the end stop with H1, only when there is the H2 move away and return to the end stop.

Originally the touch and bump were at 1mm, but I adjusted the value to 5mm to observe the problem.

I removed the H2 and the Y-axis drift stopped. I had left the 5mm moves in place to keep an eye on the homing sequences.

gloomyandy

@astrosmoke I think you have misunderstood what a H2 move does. With H2 moves X and Y no longer refer to the X and Y axis, rather they refer to individual motors. So in your code G1 H2 X5 F600 will be telling RRF to move a single motor by 5mm, in the case of a corexy a single motor move actually causes a diagonal movement of the print head (in corexy moving in just X or Y requires movement of both motors). From your description I would say that what you are seeing is the expected motion.

See:

H2 Individual motor mode. X refers to the X motor, Y refers to the Y motor, and so on. Normally used with relative motor coordinates (see G91).

From: https://docs.duet3d.com/en/User_manual/Reference/Gcodes#usage

AstroSmoke

@gloomyandy
@dc42

Ah, it just dawned on me what you and dc42 said.
Please excuse my ignorance, I am somewhat new to G codes and their nuances, specifically to coreXY movement.

Please note that I did not write the base setup code, these are typical RatRig predefined files that I have been slowly massaging into shape for my setup as I learn the structure. It appears I have observed an error in these setup files. Although I didn't notice the unintended movement prior to the 3.4.1 update.

Phaedrux

H2 should never be used in homing files for the back off moves. This is one issue that it can cause, another is that it can mask endstop issues by allowing an unhomed axis to do the back off move. Without the H2 the backoff move would give an error that the axis isn't homed rather than phantom movement in the wrong direction.

jay_s_uk

@phaedrux I think you'll find the config tool generates files with H2 used in the back off move, unless the machine is a core.. kinematic machine
https://github.com/Duet3D/ConfigTool/blob/c7efec3af7a400c4a57ae2b487b682e7374cb2d5/public/templates/homex.ejs#L21

AstroSmoke

@phaedrux

I have raised the problem on Ratrig Discord, and "H2 removal" has been raised as a pull request on git-hub for main config files. So it should be addressed in revisions, anyone else following can be pointed to updating their system homing files.

Thanks all

oliof

@jay_s_uk @Phaedrux you will also find that H2 moves are in the documentation in https://docs.duet3d.com/en/User_manual/Machine_configuration/Configuration_cartesian#homing-x-and-y
(but not in https://docs.duet3d.com/en/User_manual/Machine_configuration/Configuration_coreXY). But if it never should be used by a backoff move, it should be removed from the cartesian examples and not generated by the Configurator.

oliof

also, coincidentally, what would be the equivalent to an "unhomed" move on a Core* system (which is what H2 moves are in Cartesian)? I couldn't find an equivalent in the documentation (G91 is relative but also requires homing, right?) ... Maybe we need a H2.1 for "unhomed" move for those who insist on breaking their motion system in case of error?

deckingman

@oliof I'd have thought that the only time one would need an alternative to H2 would be on a coreXZ. i.e. the only time one needs an H2 is to lift Z prior to homing X and Y.

I remember the good old days prior to firmware 1.21 when it was easy to crash the head into the frame But one tends to learn from such mistakes so since firmware 1.21, I always put M564 H0 at the end of my config.g. Then I can nudge the axes around to my heart's content without the printer being homed and without "nanny firmware" telling me I can't do that. On a more serious note, I guess one could always put M564 H0 at the start of one's homeall.g then not have to worry about any H2 parameters.

oliof

@deckingman thanks for reminding me of M564 H0, I wasn't able to find it when I looked for unhomed moves ... that would indeed be an option for the homing files; I'll think about it.

oliof

And just for closure, the RatRig sample configuration has been updated and the H2 moves removed.