How to set up alternative coordinate system
-
You do not necessarily need the endstop at the other end. You can have it at one end and then change the homing direction etc.
-
"Work Coordinate" systems, by NIST G-Code standard, offset the "control point" from "machine" coordinates. They do not (can not) mirror, or reverse, an axis. If you have other uses for these offsets, they've been partially in Duet3D/RepRap for some time, and are fully implemented to NIST standard in R1.21 (just released a few days ago).
As mentioned by someone else above, the same M codes that are used to originally configure the machine can easily reverse an axis. Depending on a bunch of things, you may need limit switches physically at each end of the axis. If you have "normally closed" limits, wire them in series. If you have "normally open" wire them in parallel.
Wow. Really? So they eliminated G51 but did not provide an alternative method to scale axes? My 20 year old machine can scale, rotate, translate with two modal commands at the top of the gcode. Very handy for fixturing (and mirroring). Well.. I guess thank goodness for open source. Just means this is going to take more effort than I thought.
-
You can scale and mirror each axis using the M579 command. A negative scale factor mirrors the axis. It's easiest if you define X0 Y0 as the centre of the bed if you are going to do this.
-
You can scale and mirror each axis using the M579 command. A negative scale factor mirrors the axis. It's easiest if you define X0 Y0 as the centre of the bed if you are going to do this.
Nice! I think I can work with this. Too bad it doesn't include the I,J,&K options like G51 (which you use to set the center of rotation/scale) but between this and G92 or perhaps M206 I should be able to make it work. Thanks!
-
Hmm. Cannot seem to make it work with G92, M206, or M10. The M579 works great but I cannot get it to accept the offset to bring positive coordinates back onto the bed. I guess I'll reconfigure the machine like you suggested making X0 Y0 in the center.
-
It should be possible to use G10 P1 L2 to set X and Y offsets to move the origin as necessary, but it takes some thinking to get the offsets right.
-
I tried the G10 (not M10 - typo in my prior post) but didn't have the L2 parameter. What does that do? (not in the duet gcode documentation)
-
OK. I see the G53-59 are only supported in 1.21 and later so it looks like I need to update my firmware before proceeding (my duet is still running 1.20).
-
G10 L2 P1 Xn sets G54 offset. P1=G54, P2=G55, etc all the way through P9 = G59.3. The X (or any other axis) offset is considered to be relative to machine zero. L2 is NIST standard G-Code.
L20 is a "De-Facto" extension implemented by almost all controllers; it is not in the NIST documentation.
L20 is just like L2, except the arguments specified for X etc are relative to the current position, instead of machine zero. This makes it MUCH easier for a Human, or a "stateless" console GUI to set a work offset to the current position. Anything that L2 can do, L20 can do, and vice versa. The difference is what the issuer of the command needs to "know" to calculate the XYZ arguments.
Consider an operator who powers up a CNC machine, homes it (thus establishing machine zero via the endstop switches), and then uses manual jog controls to move the tip of the bit to a piece of stock. It should be noted that these moves frequently use a touch probe that is the bit itself, and/or a "corner finder" or "edge finder", and all of these can set things to .0001" or .001mm. He wants work to be RIGHT THERE, because the CAD/CAM/G-Code file was offset to the corner of the stock when it was generated.
Once that's done, the operator wants to "Zero" work coordinates G55 to match the G-Code file's "expectation". If the underlying command were L2, the coordinates of that stock edge, etc. must be "back calculated" into the command. If we are writing a GUI, it would be nice to have a button labeled "Zero work Gxx"… and that becomes challenging if the GUI doesn't actually know where the machine is at that instant (It is quite common for GUIs to be "one update behind").
The L20 allows the human or GUI to simply issue:
G10 L20 P2 X0Y0Z0
(P2 assuming we are setting G55) and it "just works" with "hard coded" zeros.
That's why many/most controllers also have L20, even thought it does not appear in the standard. Particularly controllers like the Duet (or Grbl or TinyG) which are designed to have a "separate console" from the controller itself.
-
And, Dave can answer more accurately regarding releases… to my best knowledge, G54, etc, have been in Duet for quite some time.
However, there are some nuances about the "modality" (Stickiness across lines) and the exact relationships between G10 L2 and G10 L20 that were fine tuned in 1.21.
Therefore, YES, absolutely run 1.21 if you intend to use work offsets to any great extent; I mention the history to avoid frustration of things that "almost work" in prior releases. They were very close, and most "use cases" would probably be OK... still, 1.21 is best.
-
OK. Going to 1.21 solved my problems. The G10 command worked fine once I updated (same commands would not work on 1.20). For my machine with a 200x200mm bed the following now work to mirror:
M579 X-1
G10 L2 P1 X200Undo with:
M579 X1
G10 L2 P1 X0
