-
@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!
-
I completely agree with all that 90% of users on small CNC's just need a way to set one coordinate system on the corner of there part and "let it eat".
The ability to have preset locations is great bonus for fixtures.
The Duet is truly versatile for sure and getting better each day.
-
Well, well, I haven't been paying attention! CNCjs. I will check it out. Looks quite nice.
-
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).
I'll have the interface update the user coordinates immediately in the next RC.
-
I'll have the interface update the user coordinates immediately in the next RC.
You are a gentleman and a scholar!!
-
I've realised that both PanelDue and DuetWebControl currently display the coordinates in machine space, not in user space. I think they should be displayed in user space instead, or possibly DWC could display both. Those of you who use CNC workspace coordinates, do you agree that the only or primary coordinates should be displayed in user space - in other words, in the coordinate system that is used when interpreting the parameters of G0/G1/G2/G3 commands? This would mean:
- If you send G1 X123 Y321 and this is a valid command that doesn't breach machine limits, at the end of the move the coordinates displayed will be X123 Y321 no matter what coordinate system you are in (until you change to a different one);
- When you use any of G53..G59 to switch to a different coordinate system, the displayed coordinates will change if the new coordinate system has a different origin from the previous one.
M114 returns the coordinates in machine space, followed by "User:" and then the coordinates in user space. I propose to leave this as-is, unless it is definitely going to cause issues for those using Octoprint or similar.
-
The following applications show both:
- https://github.com/Denvi/Candle - top-right area, two columns for each axis
- https://github.com/cncjs/cncjs - top-right area, two columns for each axis
- https://winder.github.io/ugs_website/ - bottom-left area, work with larger digits and machine with smaller ones, underneath
- https://github.com/vlachoudis/bCNC - top-left area, WPos and MPos rows, just under the "Not connected" red label
If both work and machine coordinates are displayed, after issuing G53..G59 M114 should immediately return the new work coordinates. As for how it reports the work coordinates, leave it as it is, especially in order not to break backward compatibility.
If DWC could display both, it would be great, at least when the firmware is set to CNC mode.
-
All GUIs that I've ever seen show the "Work Coordinate System" that is active. Some also show machine coordinates, some show machine as an option or secondary display.
This is true of software, as per the excellent examples given above, and of older controls that had physical panels. Sort of "in between" are some of the very original PC software for CNC, like MACH3, that attempted to look like an old controller. Showed work in a big display, and machine as an option.
Those of you who use CNC workspace coordinates, do you agree that the only or primary coordinates should be displayed in user space - in other words, in the coordinate system that is used when interpreting the parameters of G0/G1/G2/G3 commands?
Yes. Always WCS in the primary display
M114 returns the coordinates in machine space, followed by "User:" and then the coordinates in user space. I propose to leave this as-is, unless it is definitely going to cause issues for those using Octoprint or similar.
Yes, status should always send both. TinyG had (has) options to configure status for either, and it is very challenging to make Chilipeppr work correctly.
-
And a clarification, triggered by one of Dave's notes:
G53 is NOT modal. It applies only to the line on which it appears. It DOES NOT (should not) switch the "work coordinate system" to match machine coordinates. Whatever "prior" WCS was in use stays in force. (First boot ever, that would be G54). This also means it is not useful "by itself" and the response and/or status reports should not change if it is used by itself.
Note that this is in the NIST standard; however, the section on G53 does not say this… A careful read of the modality table will verify that G53 is not modal, by standard.
G54 through G59 are modal, and responses and/or status should change their Workspace coordinate system to match the one just activated.
Given that M114 returns both machine and work coordinates, always, what I'm really saying is that G53 does NOT switch WCS in a modal/sticky fashion, and G54 onward ARE modal/sticky.
