-
[h]Background[/h]
CNC machines have multiple sets of coordinates*. The G53 coordinate system is "Machine Absolute". G54, G55… G59.4 are "Work" coordinate systems. There are several ways to 'offset' a given Work coordinate system from absolute machine.
Many hobbyist CNC operators don't know and/or don't care about G53, G54, etc. They either don't have home switches at all, in which case they "zero the machine" to the edge/corner of the piece to be machined, or they do have home switches and the effectively override them, also by zeroing the machine coordinate space.
At the same time, extensive use of these coordinate systems is very common on larger CNC machines, and/or production CNC shops. There are many use cases, far beyond a 'background' summary… suffice it to say that proper Work/Machine coordinates are extremely important to a lot of CNC people, including a lot of hobbyists.
Work coordinate systems are also crucial for "probing" to set Z-Height… which is essential to precision machining. I don't mean "piece of paper" z-height precision, I mean .0001" repeatability. And so on and so forth.
- Per the NIST standard for G-Code.
[h]Current State of RepRapFirmware for Duet[/h]
DC42 is very interested in following the NIST standard, and has been very responsive to requests to make RepRap on Duet highly aligned with the behaviors described in that standard. It has always been close, and as of 1.21 RC5, it appears to correctly process G53, G54 through G59, and G10 L2 or G10 L20 requests. In short "everything works" to standard (with one known edge case about G53 on one vs. multiple lines).
[h]HMI (GUI consoles) for CNC machines[/h]
In addition to the actual machine motion controller, almost all CNC machines have a "Human Machine Interface". This may be a piece of hardware, or it may be a screen/keyboard/mouse based console. Two of the most popular screen based HMIs to use with 'Full-G-Code' imbedded controllers are "Chilipeppr" and "CNCjs".
Chilipeppr is a web-based, runs entirely in browser (other than one small background task that talks to the USB serial port). It does not, at this time, have direct support for Duet/RepRap based CNC machines. It DOES correctly support "Machine" vs. "Work" displays (often called "DRO" or "Digital Read Out" in the CNC world) when used with a TinyG controller. Disclaimer: I wrote most of the "Axis Widget" that provides these dual DROs for TinyG, and I believe most of that work has been (correctly) copied to the Grbl workspace in Chilipeppr.
CNCjs can run in browser, or run as a Windows/Linux/Desktop app (which is really the browser version encapsulated in Node.JS and Electron). It also does not have direct support for Duet/RepRap… however, it does support Marlin in CNC mode, and if Duet/RepRap is correctly set for Marlin feedback, CNCjs 'mostly works'.
CNCjs does have dual DROs for "Work" and "Machine". It correctly displays these when connected to a TinyG (and possible some others, like smoothieware). However, it does NOT properly display "Work" and "Machine" when told to connect to a Marlin machine that is really a Duet/RepRap machine in Marlin feedback mode. This is, at least in part, because Marlin has absolutely no support for G53, G54, G10 L2, G10 L20, etc, etc. and therefore has nothing in the Marlin status report (M114) to show machine vs. work coordinates. Therefore, there is no "pattern to follow" that Duet/RepRap can use.
There may be other HMIs (Consoles) for embedded G-Code controllers out there... please post any that I've missed in this thread.
[h]Summary Status[/h]
Duet/RepRap appears to correctly support "Machine v Work" coordinate systems per NIST G-Code standards.
There is not an HMI (console) that correctly displays "Machine and/or Work" coordinate systems when connected to Duet/RepRap.
.
.
[h]Threads that started the discussion[/h]Additional information here, a thread asking some questions about CNC coordinates: https://www.duet3d.com/forum/thread.php?id=4642&p=1
And a little bit about most recent changes to make CNC coordinates work better, in RC5, here: https://www.duet3d.com/forum/thread.php?id=4642&p=1 -
Thanks for the summary. The M408 S0 and M408 S2 responses from RepRapFirmware include both user and machine coordinates. So does the HTTP rr_status response. So the information is there if a user interface wants to display it.
-
Why that long post? Because DC42 needs to decide what a status report for M114 looks like, to improve the future compatibility of HMI… without breaking current compatibility.
At this moment, Duet/RepRap M114 response looks something like:
[c]X:123 Y:456 Z:789 E0:123456 (maybe repeat for more extruders) Count 932854 3459 2345 983456 User 15.55 789.45 13.78 (maybe more numbers for more extruders). [/c]
The first two sets of numbers are designed to be compatible with Marlin. Specifically:
The first X:nnn are "machine" coordinates. G53.
The "Count" are Extruder steps and are used for debugging only.
The "User" numbers are the position in the currently active Work Coordinate system (G54, etc).
-
I'm going to argue that the first set of numbers, the X:nnn Y:nnn, should be WORK coordinates. This may seem like it is not fully "backward compatible".
I would offer that the backward compatibility is actually:
-
Perfect for those who do not actually use G54 and so forth. They'll never know anything changed, because G53 and G54 are always equal for them.
-
Also correct for HMI/Console. Right now, these consoles all parse and pick up the "Marlin looking" codes, the regular expression being something like: c[/c]
At this moment, they (all that I'm aware of, anyway) are INCORRECTLY parsing out the first occurrences of X: and displaying MACHINE coordinates in their WORK DROs.
Changing the X: to be "Active Work Coordinate" will both fit the existing parser RE, and will cause the HMI/Console to display work coordinates in the work DRO.
It may take a future parser change to the HMI/Console to get the machine DRO to be correct… meanwhile, having only "work" be correct is much more useful than have only machine coordinates displayed. In fact, an operator who does use offsets literally can't operate with machine only coordinates (and as mentioned in (1) above, an operator who does not use offsets will never know anything changed).
In other words, making this "change" to have the first set of X: Y: be WORK is actually MORE compatible than the current behavior of returning machine coordinates in these positions.
-
-
That leaves the extended codes at the very end of the string that are the actual machine position (G53). There is no "marlin compatible" answer here, because Marlin has no concept of multiple coordinate systems (does not support G54 and friends). This is new ground for Duet/RepRap, recently added to the M114 response.
In order to make it more parseable, I'd like to offer that it should be:
[c]X:123 Y:456 Z:789 E0:123456 Count 932854 3459 2345 983456 MX:15.55 MY:789.45 MZ:13.78 ME0:753.15 [/c]
Or similar.
That would make it MUCH easier for Chilippepr, CNCjs, etc. to add proper support for parsing this output.
.
.
And, is there a JSON equivalent to the M114 text output? If so, of course, it should be 'similar'. -
dc42, I know you've been busy pushing a release… now that is been a day or two, any further thoughts on:
X:123 Y:456 Z:789 E0:123456 Count 932854 3459 2345 983456 MX:15.55 MY:789.45 MZ:13.78 ME0:753.15
-
My suggestion is to use M408 instead of M114. It provides both machine and work coordinates, and a lot of other data that may be useful in the HMI.
Or why not modify Duet Web Control to be more CNC-friendly? It displays user coordinates, but it also has access to machine coordinates.
-
I agree that M408 would be better for HMI/Console than M114. I will investigate changing CNCjs to have a "Duet/RepRap" tab in addition to its existing tabs. However, I don't know how active they are, and/or how receptive to pull requests.
DWC being CNC friendly is interesting. I'll think about that seriously.
At the same time, M408 is further evidence that M114 is not correctly aligned with the actual philosophy of NIST standard model of coordinate systems. Further, M114 and M408 are in conflict with each other:
M408 returns work coordinates in the "pos:" block, which is equivalent to M114 "X:". M114 does the opposite.
M408 returns machine coordinates in the "machine:" block, and this is equivalent to M114… well, nothing by de-facto standard... it would be most aligned with M114 returning "mx:" or similar.
Thanks for your consideration.
-
Busy days for me, so I will be brief. The CNCjs guy is pretty friendly as we already did some debug in order to see why the GUI was not sending commands to Duet unless I manually issued M114 commands through a menu in it. So there might be an improvement on this matter in the version anyway.
-
My take is that as NIST doesn't define M114, and Marlin doesn't support workspace coordinates, what M114 is supposed to return on a CNC system is not defined.
Does anyone know what Smoothieware returns in response to M114 when workplace coordinate offsets are in use? Does LinuxCNC support M114?
-
I understand your perspective that NIST doesn't define responses, not M114 nor anything else.
What it does define is that a CNC machine is always in one of the work coordinate systems. It is literally not possible for a controller to be "in" the machine coordinate system; in particular, G53 overrides only the line on which it occurs. Therefore, a controller should never return anything but the work coordinate that represents its current position (unless explicitly marked as machine in a separate field).
And, I'd also note that M114 and M408 are in conflict with each other.
Dave, it is certainly possible for an HMI/Console to parse any response, in any pre-agreed fashion. Formally, any "Interface Contract" will work as long as it is stable. However, that does not make the response correct. M114, as seen by a human at a serial terminal, is wrong as it stands.
-
Catalin, good to hear about CNCjs. I'll look at doing a fork and a Duet/RepRap tab. As Dave pointed out, that will most likely use the M408 JSON response. (If I do it, it certainly will).
Dave: Would you have a preference regarding the "short name" of the tab in the CNCjs GUI? "Duet", "Duet3D", "RepRap", or something else?
-
M114 and M408 are not in conflict, because they don't use the same labels.
I don't plan to change how M114 behaves until I know how other CNC firmwares that support M114 behave.
-
Dave, you asked about LinuxCNC and M114 M408. It does not support any G or M command that returns a response, primarily because the displays are all "built in". The displays can be "skinned" to user preference… and almost all of those skins have the current work coordinate displayed quite large, and the machine displayed small or not at all. Example (white numbers are labeled "Current Position", aqua blue numbers "Machine Coords"):
My interpretation of this is "neutral", because the motion controller and the display are not separate, there is no "message format" to follow.
-
M114 responses, Work or Machine, by firmware:
NIST - Does not specify M114 (or any other way to solicit a coordinate position response).
NIST does document "Parameters" to read the state of the controller. NIST further documents which "Parameter" sets contain work coordinates for the various G54 and onward states (5221 onward). NIST also documents a separate parameter that selects which set is active (5220). NIST further states: It is an error for the value of parameter 5220 to be anything but a whole number between one and nine. (corresponding to G54 through G59.1).
Any hypothetical DRO/HMI/Console interfaces to the NIST controller would need to read the parameters, and it should be noted there are not parameters (documented) for absolute machine coordinates. So any hypothetical "Tell me your position" response would have to read 5220 and use it to decide with group of 5221 onward to display… put simply, it could only respond with "Work". Per NIST documentation, it is not possible to respond with anything else. Machine coordinates can only be "back calculated" from the currently active offset.
My interpretation of this is "Work" should be displayed, because it is the only thing that NIST 'externalizes'.
-
M114 responses, Work or Machine, by firmware (continued):
Marlin - N/A, does not have the concept of Work vs. Machine.
Smoothieware - M114 shows Work. M114.2 shows Machine.
Repetier - N/A does not have concept of Work vs. Machine.
GRBL - Does not support M114. ? can be set to return one of W or M. ?? returns both, and a matrix of all offsets.
TinyG - Does not support M114. JSON and/or Text responses can be configured to return Work, Machine, or both. When configured to return Work and/or Machine JSON uses POSX: and MPOX:, respectively. Text responses return a large block of text, with "X Position: nnn.nnn" on a line by itself, etc. These are work positions. A different line has the currently active coordinate systems (G54, etc).
Summary (skipping the N/A):
Smoothie: G54 Yes. M114 Yes. M114 returns work. (M114.2 returns machine).
TinyG: G54 Yes. M114 No. TinyG does have its own status and/or response formats, both text and JSON. They all return Work in the "POSX" or "X: Position" fields. They all can be configured to return machine, in fields such as MPOX:.
Even more summarized: All firmwares that do respond, always return work in the "normally named" fields, and only return machine in subset commands or fields who's names start with "M".
-
Thanks. I'll probably follow the Smoothieware format in a future firmware release.
-
Dave,
I've checked G10 L2 and L20, using M408 S1 for response, on Release 1.21 (final), combined with various G1 and G0 moves. Everything appears to behave correctly in every scenario I could think of to test (I did not do a rigorous analysis of test cases).
-
However…
Per NIST standard documentation, work offsets are supposed to be persistent, including across reboots and power cycles. In the case of Duet3D/RepRap, they are not.
In case you are wondering, persistence is an important feature for CNC machinists, because the various G55, G56, etc. are quite often used for "Fixtures" that are mounted to the CNC bed for extended periods of time (weeks or months). Having to "re-find" or "re-touch" fixtures every time the machine is reset would be quite contrary to the way people are accustomed to operating.
-
I've added this to the list of thing to look into for the next firmware version.
