Openbuilds XYZ Probe Plus, G38.2 X moves in wrong direction
-
@dc42 After multiple erase and flash attempts with various methods in powering the SBC and main board with several different cables, I finally got it to flash. I do not know what the issue was, but I don't think I want to do that again.
I am going to reconnect everything and run the update to get it running on RC2.
-
@markz Thanks for the reply. After the update to RC2 we shall see if the G38.2 is going to behave. If not I'll give your solution a try.
-
@markz I've just been playing with G38.2 myself on my Workbee and realised that it behaves quite differently in relative and absolute positioning modes.
Under relative positioning X and Y both move towards zero regardless of the sign of the relative movement you enter (which I think is probably a bug).
Under absolute positioning X & Y move towards the position you enter (correct behaviour according to the NIST spec).
I've just got to get my head round the coordinate systems now!! -
@crossbow Huh, I didn't realize that about the relative. Thanks also for improving my comment. I use X and Y with no coords (a value of 0) since it's in a macro that's simplest and forget that's not the full use.
Mark
-
@chrishamm The problem with G38.2 persists with the update RC2 from the link you posted for the main board and the unstable update for the SBC. I will try to use the M675 command in a macro to probe the cavity in the probe plate. I think the RC2 solved a problem for user Yveske - https://forum.duet3d.com/topic/21025/duet-3-6hc-with-openbuilds-xyz-probe
-
@crossbow Since I have updated to RC2, I can get G38.2 to move in a negative and positive direction on Y and Z, but X still ignores the parameter and moves to zero under the G91 relative positioning. I was able to do this with Y and Z under the stable release as well.
-
@max3d I am still using 3.2.2. What I did was to use absolute positioning using machine coordinates (so I didn't exceed machine limits in the reference) with commands like this which worked for me:
G90
G53 G38.2 X550 F100 ;probe to some distant X to make move in forward direction using machine coordinates
G10 P1 L20 X-11.5 ;set X offset in WCS 1 to thickness of probe plate edge + 1/2 bit diameter -
@max3d check out https://forum.duet3d.com/topic/21025/duet-3-6hc-with-openbuilds-xyz-probe/48
Apparently G38.2 uses absolute coordinates. That is why you cannot get X to move in the direction you want. @dc42 suggested this instead:
G38.2 Z{move.axes[0].userPosition-25} -
@cthulhulabs Sorry for the late reply, went on Holiday... The command did not work in absolute or relative positioning. But, what did work were the commands that "crossbow" posted above. Thank you for your reply.
-
@crossbow Sorry for the late reply, went on Holiday...
And the winner is?
I ran the same code you suggested in 3.2.2 and it did not work. When I am testing I leave the code changes in the macro and just comment them out so I can keep track of what I tried. The difference was that I stayed with "G53 G38.2 X50 F100" and your code increased the X value by 500 and that made all of the difference. I can now zero the workpiece on the X axis with G38.2.
Just for kicks, I lowered the X value to 100 and it works the same as the 550 value. I lowered the value to 90 and the tool moves in the wrong direction (under 90mm, about 20mm) this time and then the pinky-orange dialogue box appears with the following message: "Error: Probe was not triggered during probing move". Testing method: I do not reset the board each time, but I "HOME ALL" after each test jog to position and run macro.
I do not know if this is just a bug for X, because I can control the direction of Y and Z without any problems in relative coords. For X the parameter value for X needs to be 100 or above ie. "G53 G38.2 X100 F100" in absolute coordinates (G90).
Many thanks to you, and everyone, for the help.
-
I'm necroing this because while it's an edge case it's still a problem.
There's a bug report on git hub that was closed because no one replied in time and it says to open an issue in the forum if it's still a problem, but I'd rather keep a discussion going rather than clutter things with new issues on the same topic. Needless to say generally having a move command not respect what type of move you're commanding and moving unexpectedly is a problem, moreso in the CNC world than the printer one, and my post on the bug details exactly how this has impacted me (my own experience is quite similar to @Max3D 's but I was lucky enough to notice why sooner). I would request that we get some attention to this soonish.
