Doing M556 Axis compensation makes my Z-axis pos go nuts?

(re-posting this in this category instead)

I'm just finished building my new shiny Ormerod 2 and printed out the "angle parts" to make the Axis compensation.
The values i got was something like this M556 S75 X0 Y1.1 Z1 (not at home now so cant check exact values).
After sending this line, when I try to home my Z axis it travels all the way to the top (overtravel) and I have to Power it down.
(Seem to remember that Z was indicated at -220 the whole time)
If i re-Power Everything it works (Not put it in config.g yet) as long as i don't send the M556....
To test i sent the exact same line as in the calibration instructions ("M556 S78 X-0.65 Y0.9 Z0.2") with the exact same result (Z just keep going all the way up when trying to home).
I'm using the latest firmware 0.78a. Can't be a firmware issue right? Think i would have found more ppl with this issue.

Anyone able to give this newbie any pointers?

Somebody else reported the same problem a week or two ago. I don't recall a resolution being posted. However, you could try my firmware fork, which includes a bug fix for axis compensation (although not specifically this bug, which I can't reproduce using my firmware). See [forums.reprap.org] for details.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I had someone else report this bug yesterday, and I think this is specific to Ormerod 2, because the Y axis endstop has changed ends. The triggering of any endstop appears the same to the firmware (in the current version) so if any one of them is triggered, the firmware thinks the current axis it is homing is triggered, so will move the axis away from the endstop, until it is not triggered. When you home Z, and the Y endstop is triggered, it sees this and thinks the Z endstop is triggered, and moves the Z axis away. The Z axis probe point is X60 Y0, so the Y axis is on the Y endstop. This probably just works without orthogonal compensation, but when this is applied, it is probably triggering the Y axis endstop, and so the behaviour of the Z axis.

There are two theoretical workarounds (we're just testing these):
1. Change the z homing point from X60 Y0 to X60 Y2, which will move it away from the endstop. In homez.g, change:

G91
G1 Z5 F200
G90
G1 X60 Y2
G30
G1 Z0 F200

You may need to similarly change the G32 automatic bed compensation points - we're testing this.

2. When homing the Y axis, move it 1 or 2mm away from the endstop, then set that as zero. Change homey.g and homeall.g as follows:

...
G92 Y0
G1 Y3 F200
G1 Y-30 F200 S1
G92 Y0
G1 Y2 F200 ; add this line to move the Y axis 2mm away from the endstop
G92 Y0 ; add this line to set Y  = 0
G91
...

We're testing these solutions, and will update the settings on github with the best solution.

Ian
RepRapPro tech support

Edited 1 time(s). Last edit at 10/16/2014 09:27AM by rhysjones.

If the problem is caused by the wrong endstop being triggered, then it won't occur with my firmware fork, which monitors only the endstop for the axis being homed.

Edited 1 time(s). Last edit at 10/03/2014 06:00PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

It seems to be if you put any figure in for Y, it crashes Z, if it starts with the Y endstop triggered. If you move axis away from the endstop, it works fine. I've passed my findings on to Adrian to work out what the problem is. He said the main firmware branch treats every endstop separately, but clearly something isn't quite working. I can't remember if I tested workaround 1 in my earlier post, but workaround 2 certainly does. I didn't test the dc42 branch, so I don't know if the problem presents in that too.

Ian
RepRapPro tech support

Quote
droftarts
I've passed my findings on to Adrian to work out what the problem is. He said the main firmware branch treats every endstop separately, but clearly something isn't quite working.

It does check the endstops separately, but always checks all of them or none of them. So triggering any one of them will terminate the homing move. The standard RRP homing files follow every X or Y homing move with a G92 command, so they assume the homing mode was terminated by hitting the correct endstop - which is not necessarily the case.

My fork avoids the issue in two ways:

(1) Only the endstops relevant to the homing move being performed are checked.

(2) The homing moves do not have to be followed by G92 commands, except in the special case of the Y axis on an Ormerod 2 (the firmware is compiled assuming a high endstop whereas that machine has a low endstop).

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].