-
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.
-
@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.I just want to make sure I'm following what you are saying.
If I setup my Duet with a G54 location and a G55 location I can then have a moves like this?
"G54 G1 X20.0"
"G55 G1 X4.0"And the machine will go to each location in sequence? It will monitor all set locations at the same time? That would be great. I'm going to try it tonight with my printer just to see if I can get it to work.
-
"G54 G1 X20.0"
"G55 G1 X4.0"And the machine will go to each location in sequence? It will monitor all set locations at the same time? That would be great. I'm going to try it tonight with my printer just to see if I can get it to work.
That's what should happen. I haven't verified it on Duet/RepRapFirmware.
And… just to note... G54 et al. are "sticky". So this is legitimate as well:
G54
G1 X...Y...
G1 X...Y...
G55
G1 X...Y...and so on. This all assumes you've set SOMETHING in G10 L2 P1 X...Y...Z... (P1 for G54, P2 for G55, etc.)
-
I just did a very quick check on a Duet with nothing physically attached to it.
It does appear that G10 L2 Pn X…Y...Z... followed by a G54 command indeed changes the reported coordinates, and does so "properly". I would note that the GUI does NOT update when the G54 is sent, but does update at the next move (G1).
-
Oh, and too Catlian's very original comment, G10 L2 vs. G10 L20:
TinyG also does not have G10 L20 (that works properly). Therefore, the Chilipeppr GUI "back calculates" the correct G10 L2 settings when a user hits the "Set Gxx Zero" button.
I mention this because it would be fairly straightforward to 'clone' the TinyG workspace in Chilipeppr and have a "Duet3D CNC" workspace in Chilipeppr. It is designed to make cloning easy (VERY easy), and the changes would be minimal.
-
I kind of agree with what Danal says. Most small CNC mills/routers do not have home/limit switches. And many users don't care about work coordinates. But let's think of the machines with master/slave axis arrangement. Squaring them is close to impossible when using steppers because it is a 50-50% bet on the position that the steppers will get to when first energized.
I had an eShapeoko. Like with all belt driven dual axis machines, with GRBL I used to pull the X axis toward Y home before turning on the 24V power supply, just to insure as much as possible the gantry alignment. The WorkBee is screw driven and the homing switch is not even at the end of the travel (I would have to install a hard stop for that). A good controller knows how to align such machines. So far, this is the rather short list of "good" controllers:
- Duet3D - can be done with clever macros, I will start a WorkBee specific thread on this matter quite soon, but most things would be true for any CNC mill/router with dual Y axis;
- EdingCNC CPU* series;
- LinuxCNC based solutions;
- Mach* based solutions;
- if I properly recall the UC* series.
I don't count here the machine specific controllers as those are not available as separate products.
The list of "bad" controllers includes:
- GRBL - mainly because it can't control the Y axis steppers independently due to limited I/O pins;
- TinyG/G2 core - I don't know the reason, but the firmware seems to not be able to home more than one axis at a time, and checking just one switch;
- PlanetCNC - the developer strongly refuses the idea as mentioned on several forums.
As a whole package, Duet is the best positioned for small and medium machines (steppers up to 3A) because of the included advanced stepper drivers and the available CPU processing capabilities - hardware wise you can't get more for the money. And when you get into the >2000EUR price range, home and limit switches are usually available by default.
As for the CNC specific GUI to be used with Duet3D, I have raised a CNCjs ticket as it seems to be the only one with Marlin support. When milling I really like to see the 3D preview!
