CNC workplace coordinates
-
Can you point me to a specification of G10 L20? For CNC support I try to follow the NIST GCode Standard version 3, but it doesn't mention G10 L20, just G10 L2.
-
First of all on the G10 L1… It is completely identical to the current G10 implementation of the Duet firmware if you disregard the extruder specific parameters (the Rnnn and Snnn parameters). So if the firmware would optionally accept L1 (that is, if no L parameter is given, consider it to be L1), it might be better for compatibility with other control applications.
Now for the step by step for G10 L20 use, it depends on various factors. Generally speaking, it is exactly as you say. When generating the GCode with a CAM application, usually you position the workpiece relative to the origin of the axis in the CAM application. It might be the corner of the raw material, but not mandatory. One must also consider material clamping devices and insure that the tool doesn't hit them somehow. Most of the time the origin is decided by jogging to the desired location, visually checking for potential obstacles and completely ignoring the machine coordinates.
Scripts that use touch probes (or alternative solutions) to determine precisely the edges will also end with a G10 L20 for each determined edge, just that the position for the measured axis will not be 0, but half the width of the edge probe tip, either positive or negative, depending on the searched edge.
Other alignment solutions rely on USB microscopes installed at precise offsets from the spindle axis. Then the G10 L20 will set the coordinates using the fixed offsets on X and Y between the microscope and the spindle axis while Z will have to be zeroed using other methods.
But in all cases we are discussing of constants that can be implemented through easily accessible one-line macros in DWC. And everything gets down to the same G10 L20! Thus I bet this extra would make really happy a lot of CNC users.
-
GRBL, TinyG (0.97-Edge) and G2 core implement G10 L20 exactly as LinuxCNC does, computing the offsets for the G53-G59.x workspaces based on current machine coordinates and the desired work coordinates (http://linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G10-L20). Other controllers may use other conventions, but considering the already existing firmware code and that most CNC specialized G-Code senders that might get Marlin reporting compatibility support this version of G10 L20, I wouldn't consider anything else for the time being.
As for the NIST GCode Standard version 3, it doesn't mention anything else but G10 L2 and if you look at other controller manufacturers that detail the supported G-Codes, there are quite a few G10 L- possibilities!
-
I have attempted to implement G10 L2 and G10 L20 in firmware 1.21RC4. See the thread about that release for where to get it. Please test this with care, because I may have got it wrong.
-
Going to reconnect Duet3D to the machine and give it a test. I might move the home/limit switches away from the physical limits and leave the screws relatively loose so they are pushed away until I reach the stop button. I might also have a look over the code, as extra safety!
-
I have finally had some spare time to do the test and look though the code. Briefly put, I have just homed the machine and manually jogged all coordinates (X, Y and Z) to 10.0. After the jog I used the G-Code console to send M114 followed by G10 L20 P0 X0 and another M114. The following is copy&pasted from the DWC G-Code console, so the sequence must be read in reverse (first line is the last command):
9:45:29 PM
M114
X:10.000 Y:10.000 Z:10.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 E7:0.0 Count 4000 4000 4000 User 20.0 10.0 10.0
9:45:25 PM
G10 L20 P0 X0
9:45:10 PM
M114
X:10.000 Y:10.000 Z:10.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 E7:0.0 Count 4000 4000 4000 User 10.0 10.0 10.0
User coordinates should have been (0, 10, 10) instead of (20, 10, 10). In GCodes3.cpp I see the following line:
[[language]] workplaceCoordinates[cs][axis] = (compute) ? coord - currentUserPosition[axis] + workplaceCoordinates[currentCoordinateSystem][axis] : coord;The sign of the offset seems to be wrong.
I also presume that```
[[language]]
currentUserPosition[axis]-workplaceCoordinates[currentCoordinateSystem][axis] -
More to this, when switching between the workplaces with G53..G59.3 commands I don't see the workplace coordinate changing until I do some jogging. For all the tests I have used G-Code console, including the M114 commands, not to depends on possibly not updated DWC status.
As a side note, I have not seen detailed description of M114 in the wiki, but I presume that "User" section is for the absolute coordinates and all other are workplace.
10:18:40 PM
M114
X:0.000 Y:0.000 Z:0.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 E7:0.0 Count 0 0 0 User 0.0 0.0 0.0
10:18:37 PM
G54
10:18:26 PM
G10 L20 P1
Coordinates of workplace 1: X100.00 Y200.00 Z300.00
10:18:17 PM
G10 L20 P1 X100 Y200 Z300
10:17:52 PM
G10 L20 P2
Coordinates of workplace 2: X0.00 Y0.00 Z0.00
10:17:49 PM
G10 L20 P1
Coordinates of workplace 1: X0.00 Y0.00 Z0.00
10:17:45 PM
G10 L20 P0
Coordinates of workplace 0: X0.00 Y0.00 Z0.00
10:17:39 PM
M114
X:0.000 Y:0.000 Z:0.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 E7:0.0 Count 0 0 0 User 0.0 0.0 0.0
-
It's the other way round. The user coordinates correspond to the values sent in G1 commands. So if you send G1 X12 Y34 then at the end of the move the user coordinates will read X=12 Y=23.
If you use G10 to change the origin of a workspace, and you currently have that workspace selected, the user coordinates should change immediately to match the current tool position.
-
I have just done a new clean session. As you can see, the G53..G59.3 codes do not update the reported status until a movement command is issued. But G10 for the current workspace is indeed updating the reported coordinates as it should.
12:28:04 AM
M114
X:5.000 Y:10.000 Z:15.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 E7:0.0 Count 2000 4000 6000 User 5.0 10.0 15.0
12:28:01 AM
G0 X5 Y10 Z 15
12:27:48 AM
M114
X:10.000 Y:20.000 Z:30.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 E7:0.0 Count 4000 8000 12000 User 20.0 40.0 60.0
12:27:45 AM
G54
12:27:40 AM
M114
X:10.000 Y:20.000 Z:30.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 E7:0.0 Count 4000 8000 12000 User 20.0 40.0 60.0
12:27:37 AM
G10 L20 P0 X0 Y0 Z0
12:27:23 AM
M114
X:10.000 Y:20.000 Z:30.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 E7:0.0 Count 4000 8000 12000 User 10.0 20.0 30.0
12:27:20 AM
G0 X10 Y20 Z30
12:27:02 AM
M114
X:0.000 Y:0.000 Z:0.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 E7:0.0 Count 0 0 0 User 0.0 0.0 0.0
-
Another problem that I have just spotted - The offsets accumulate with multiple G10 L20 commands. The offsets should always be computed based on the actual machine coordinates and not on the currently displayed workplace coordinates. Unless it is a side effect of the wrong offset sign (if the firmware stores only workplace relative coordinates and relies on current offsets to determine the actual machine coordinates! - I must admit I have not looked that far into the firmware source files).
12:34:15 AM
M114
X:10.000 Y:20.000 Z:30.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 E7:0.0 Count 4000 8000 12000 User 40.0 80.0 120.0
12:34:12 AM
G10 L20 P0 X0 Y0 Z0
12:33:47 AM
M114
X:10.000 Y:20.000 Z:30.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 E7:0.0 Count 4000 8000 12000 User 20.0 40.0 60.0
12:33:44 AM
G10 L20 P0 X0 Y0 Z0
12:33:35 AM
M114
X:10.000 Y:20.000 Z:30.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 E7:0.0 Count 4000 8000 12000 User 10.0 20.0 30.0
12:33:33 AM
G0 X10 Y20 Z30
12:33:01 AM
M114
X:0.000 Y:0.000 Z:0.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 E7:0.0 Count 0 0 0 User 0.0 0.0 0.0
-
This thread is very interesting, thank you for having it in the forum where others can follow!
I recently got a shapeoko and would love to put a Duet into it at some point down the road. I'm just barely tapping into workplace coordinates so far, so being able to see this discussion is very helpful!
-
Another problem that I have just spotted - The offsets accumulate with multiple G10 L20 commands. The offsets should always be computed based on the actual machine coordinates and not on the currently displayed workplace coordinates. Unless it is a side effect of the wrong offset sign (if the firmware stores only workplace relative coordinates and relies on current offsets to determine the actual machine coordinates! - I must admit I have not looked that far into the firmware source files).
12:34:15 AM
M114
X:10.000 Y:20.000 Z:30.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 E7:0.0 Count 4000 8000 12000 User 40.0 80.0 120.0
12:34:12 AM
G10 L20 P0 X0 Y0 Z0
12:33:47 AM
M114
X:10.000 Y:20.000 Z:30.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 E7:0.0 Count 4000 8000 12000 User 20.0 40.0 60.0
12:33:44 AM
G10 L20 P0 X0 Y0 Z0
12:33:35 AM
M114
X:10.000 Y:20.000 Z:30.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 E7:0.0 Count 4000 8000 12000 User 10.0 20.0 30.0
12:33:33 AM
G0 X10 Y20 Z30
12:33:01 AM
M114
X:0.000 Y:0.000 Z:0.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 E7:0.0 Count 0 0 0 User 0.0 0.0 0.0
Please can you provide me with a sequence of operations to test G10 L20 along with expected outcomes.
As I understand it, if I send G10 Pnn L20 X123 then the firmware should adjust the origin of the workspace coordinate system nn so that when I am using that system, the current user X position becomes X=123. It follows that if I am already using that coordinate system or I switch to it using an appropriate G command, if I then send G1 X123 the tool will not move. Is that correct?
-
Does the Duet firmware always maintain the machine cords in the background or does it just have one set that get altered through G92's or G10's? I think that is where the differences may lie here.
On CNC machines the G53 coordinates are set based on the home switches. then any types of offsets are based from the G53. The G53 coordinates are always maintained and can never be changed through M or G codes. Only the other offsets can be changed as needed to set zeros, tool height, ect.
So if I set my G54 X offset to 105mm and then move to "G54 G1 X0.0" the machine will move to that position. If I check my G53 cord then X will read "105.0" In my opinion this is important because you can never over travel an axis in any direction with this type of setup. The travels in each direction are all based on G53 (machine coordinate) not any other coordinate. Right now on my printer I can home my axis, move to XYZ 0 (center of the bed). Now if I move X over 50 mm positive and run a G92 X0. my X is now moved over 50 mm. But so are all my axis end limits. So if I move in the positive direction another 200 mm I will over travel because my X can really only move 225mm from true center. But Duet doesn't realize this and stop before the crash. If the firmware were to manage the G53 machine coordinate and monitor the end limits based on that coordinate system then it would still stop at my true end limit no matter where I set my zero.
This is why the offsets currently accumulate with multiple G10 L20 commands….
I'm not sure if the Duet firmware can support multiple coordinates at the same time but it would really help the CNC mill guys.
Just my 2 cents.
I think the Duetwifi is by far the best printer board and firmware on the market. I have tried most of them.
-
@timcurtis67
The Duet firmware has almost completely functional support for G53 to G59.3 coordinates systems. All of them can be changed through G10 Lnn Pnn commands, with P0 corresponding to G53. At least that is what I understood from briefly looking through the code.And I totally agree that the Duet is among the best solutions for 3D printing, with equivalent ones being many times more expensive, especially considering the quite advanced TMC2660 drivers (similarly specced Leadshine drivers are about 40-50EUR/piece and you have 5 of them on the Duet!). But I would really love to permanently use it on my WorkBee with 3A steppers. But enough smalltalk, back to the issue…
@dc42
For CNC the status report should have both machine and work coordinates. For simplicity I will discuss, as you did, just axis X. Also, MachineX=WorkX+Offset is considered.- immediately after reset and homing, MachineX=0, WorkX=0 and G53 is presumed
- G10 L20 P1 X-100 should set X offset for G54 to 100.
- G10 L20 P2 X-130 should set X offset for G55 to 130.
- G10 L20 P3 X20 should set X offset for G56 to -20.
- Send G54, the status should be MachineX=0, WorkX=100
- Send G55, the status should be MachineX=0, WorkX=130
- Send G56, the status should be MachineX=0, WorkX=-20
- Send G0 X0, the status should be MachineX=20, WorkX=0
- Send G54, the status should be MachineX=20, WorkX=120
- Send G0 X0, the command should be rejected because of software limits! (MachineX would go below 0) or just prevent sending stepper pulses while MachineX is below 0 (I think this is already done, based on quite recent discussion!).
If G10 Lnn P0 commands should be accepted or not is another discussion. In the end, some things can be left for "upper level decisions" (read it "let the user break things if he really wants to!").
Oops! "G10 L20 P2 X-130"
-
Thanks. In line:
- G10 L20 P2 X-120 should set X offset for G55 to 130.
I presume you meant:
- G10 L20 P2 X-130 should set X offset for G55 to 130.
-
I'm a CNC guy as well, and a user of both Mach3 and Chilipeppr/TinyG. I wrote / re-wrote most of the Chilipeppr GUI support for coordinate systems.
What Catalin_Ro said above is absolutely correct, and I believe that Dave correctly caught a 120/130 typo. However, I'm chiming because as a "user story", the examples given are untypical. Therefore, I want to make two comments:
- It is much more common to have positive offsets from Machine zero to a user workspace coordinate system.
-
- Many/most small CNC machines do not have home switches. Users of these machines almost always use a workflow wherein they CAD/CAM all toolpaths to originate in either the "lower left" or the "center" of the workpiece (stock). Later, at the machine, they position the bit at the lower left or center, and zero the machine, then cut. They never use "work" coordinate systems. They just zero the machine (G53). This works for small machines, and is extremely simple for the person who is the CAM and the Operator both.
It does have the down sides of making it difficult to use "right up to the edge" of the cut area, difficult to produce a multi-cut part, impossible for the machine to have software limits, and more. Most small CNC users don't care about any of these things.
I say all of this because there will be people reading this thread (and possible commenting) that don't (can't) see what the heck we are all on about… because they don't have home switches.
Now, back to work coordinate systems...!
-
So, an example from my shop literally yesterday, as I was surfacing a new spoilboard, on a CNC Router with XYZ of
60 in (~1500mm), 24 in (~600mm), 6 in. (~150mm)-
Attached the stock, the new 24x48 inch spoilboard, at about X+two or three inches, doesn't matter exactly where, centered in Y.
-
Homed the machine. At this moment XY=0, Z also is zero, but on a CNC this is at the top of travel, about 6 in above the surface. At this moment, G53 (machine) coordinate systems would be active, and G54 through 59 would be unknown (really whatever prior operator (me) set into the machine last time).
-
Jogged the spindle to the corner of the stock. Machine G53 X=2 inches (let's just say for ease of description) Y=0, Z=-5.25.
I "eyeballed" this, because I was using a large surfacing bit. In many case, people use an"edge finder" that can put the bit over the corner of the stock to within a few .0001 in, and then probe Z electronically, again achieving repeatability in the few ten thousandth range. That really drives home why coordinate systems are important.
-
Used the Chilipeppr GUI to "Set G54 Zero". Internally, this issues G10 L2 P1 X-2.5 Y0 Z5.25.
-
Used the Chilipeppr GUI to switch to G54 coordinates. This sends G54.
At this moment, machine coordinates are X2.5 Y0 Z-5.25. G54 coordinates (as shown in the DRO on Chilipeppr) are X0Y0Z0
- Started the Cut.
This is a VERY typical use case. Also, a lot of people use G54 as a "change it for each piece you cut" and G55, 56, etc as a "this is a semi-permanent fixture" mounted on my machine somewhere. For example, I CNC plastic cases for a product I make, The fixture that holds a case for cutting is in my machine "at" G55 X0Y0Z0.
-
-
This is what the display on Chilipeppr/Tinyg looks like. Top XYZ are work coordinates. Bottom (with 'm X' etc) are machine coordinates (machine coord display is normally turned off).
Were G54 (etc) set, the coordinates would be different between the two displays. . (I can't show that without an actual machine hooked up, and i'm not in the shop).
Also notice the graphic to the left, that shows how G53, 54, etc and G92, relate.
And, last, think carefully about the buttons, noting that "Go To Gxx Zero" changes itself to G54 (or whatever) when you select an alternate coordinate system. As an example, think about the sequence: "Home Machine"…. "Jog"... "G54"... "Set G54 zero". Then think about what "Go To Mch Zero" will do vs "Go To G54 zero".
-
And, just for completeness, this is what the dropdowns on the individual axis show. Essentially, they let you do the same as the main buttons, just on one axis.
