Unintentional axis movement

Veti

lets start of with the first thing. there is a M208 before the M584

See
https://duet3d.dozuki.com/Wiki/Gcode#Section_M584_Set_drive_mapping

Order dependence

M584 must come earlier in config.g than any M350 and M906 commands. If it creates new axes, it must also be earlier than any M92, M201, M203, M208, M350, M566, M574 , M667 and M669 commands.

Veti

@kerembyl said in Unintentional axis movement:

M501 ; Check config override file

also it makes sense that this should be the last command in your config. not one of the first.

kerembyl

@veti said in Unintentional axis movement:

M584 must come earlier in config.g than any M350 and M906 commands. If it creates new axes, it must also be earlier than any M92, M201, M203, M208, M350, M566, M574 , M667 and M669 commands.

I fixed the things you mentioned, problem is still there. Thank you for correction though.

Veti

if you move back to G1 X30 Y30. does it return to the same place as the original G1 X30 Y30 ?

droftarts

Is any axis compensation applied? I'm thinking more of the M556 orthogonality type. Possibly in homeall.g or bed.g?

Ian

kerembyl

@droftarts neither both of them have M556. There is no axis compensation.

@Veti Error is not consistent so i could not experiment that.

Veti

can you post a picture of your printer?

kerembyl

@veti If you tell me what exactly do you want to see i can help you better. Because product is commercial and under development.

Veti

is the movement for x and y independent?

what do the u and v axis do?

kerembyl

@veti In order to prevent confusion because of U and V axis, i edited first post and submitted simpler config file. This belongs to another device which runs on same hardware and firmware and problem still exists. What i mean is it is not relevant to creating additional axes.

X and Y axes are independent for sure. They are driven by seperate stepper with no mapping applied to each other.

Veti

does the y stepper motor actually move when doing the move from 30 to 270?

kerembyl

@veti yes from x30 to x270 it moves.

Veti

and you ruled out any mechanical issue? like moving the head manually when the duet is off to see if the movement happens as well?

without axis compensation there should be no movement on the y motor.
can you also post the config-overwrite

kerembyl

I ruled out all mechanical issues, all of our devices have this problem.

config-overwrite.g contains only PID and BL Touch parameters.

Oddly enough, this is not happening while printing. Because dimensions are true.

; Heater model parameters
M307 H0 A90.0 C700.0 D10.0 S1.00 B1
M307 H1 A435.6 C268.1 D12.2 S0.27 B0
M307 H2 A340.0 C140.0 D5.5 S1.00 B0
M307 H4 A340.0 C140.0 D5.5 S1.00 B0
M307 H5 A340.0 C140.0 D5.5 S1.00 B0
M307 H6 A340.0 C140.0 D5.5 S1.00 B0
M307 H7 A340.0 C140.0 D5.5 S1.00 B0
; Z probe parameters
G31 T1 P10 X0.0 Y0.0 Z1.50
G31 T3 P500 X0.0 Y0.0 Z0.70
G31 T4 P500 X0.0 Y0.0 Z0.00

MrsDelish

This movement only happens when you probe your bed? If that is the case there is probably a probe offset(G31) in Y set somewhere, since the i.e:
G30 X100 Y100 uses position of probe(nominal tool holder position & probe offset) , where as
G1 X100 Y100 uses active tool position(nominal tool holder position & tool offset).
Check your config.g, homeX/Z/Y.g and Bed.g for any G31 with a XY value or G10 tool offset in XY.

Veti

i dont see anything in the config that would explain that.
just to rule out any firmware problem please update to the stable 2.03

kerembyl

@mrsdelish It also happens on a device which employs manual bed leveling. (without probe)

kerembyl

@dc42 Do you have any idea about that?

dc42

@kerembyl said in Unintentional axis movement:

Firmware: 2.03beta3

Beta versions of firmware are not supported once a later beta or (as in this case) the corresponding full release has been published. So you should upgrade to 2.03 (final release) or 2.04RC1 and test again.

kerembyl

@dc42 I just have upgraded to 2.04RC1 and the problem still occurs