Possible bug observed after V3.3 to 3.4.1 update

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