-
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.
-
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.
That's interesting, and not what I had expected. Are you saying that once I have selected a WCS, there is no way I can go back to the native machine coordinates, except by setting the offsets of some WCS to all zeros and then switching to that WCS?
Please note, one aspect in which RRF does not follow the NIST standard is how it handles multiple commands on the same line. RRF does this:
- F is not a command, it is a parameter to other commands, in particular the feed rate on G0-G3 commands (for which it is 'sticky').
- T is a command when it is the first non-whitespace character on a line. Otherwise it is a parameter.
- You can have multiple G and M commands on the same line. Each G or M character that is not within double quote characters or in a comment and is either at the start of a line or preceded by white space is the start of a new command. Multiple commands on the same line are executed in left to right order.
-
That's interesting, and not what I had expected. Are you saying that once I have selected a WCS, there is no way I can go back to the native machine coordinates, except by setting the offsets of some WCS to all zeros and then switching to that WCS?
Correct. There is no way to put an NIST standard CNC into "machine coordinates" on a permanent basis. It can only be in G53 "one line at a time". The command:
G53 G0 X…Y...Z...
is valid and would move to those machine coordinates. As a side note, this seems compatible with the general way multi-commands on one line are handled now, with the clarification that G53 must not affect succeeding lines.
And, to be super clear the statement "...once I have selected..." is a non-sequitur. There is always a WCS active. It just so happens that a "freshly deployed" machine will be in G54 and the offsets will be zero, so it will 'appear' as though it is in G53.
This is made clear in the verbiage surrounding Table 4 in the NIST standard. Specifically these subsets:
@NIST:
The modal groups for G codes are:
group 12 = {G54, G55, G56, G57, G58, G59, G59.1, G59.2, G59.3} coordinate system selection
In addition to the above modal groups, there is a group for non-modal G codes:
group 0 = {G4, G10, G28, G30, G53, G92, G92.1, G92.2, G92.3}Two explicit things here:
First, the table itself shows G53 to be non-modal, Group 0.
Second, it shows all of G54-G59.3 to be in the same group, and makes the following statement about all groups, just after the table (underline mine):
@NIST:
For several modal groups, when a machining center is ready to accept commands, one member of
the group must be in effect. There are default settings for these modal groups. When the
machining center is turned on or otherwise re-initialized, the default values are automatically in
effect.That statement confirms my statement "A freshly deployed machine is actually in G54 with no offsets". Also, see next post (this one is getting too long).
-
Directly from the standard, underlines and bolding mine:
3.2.2 Coordinate Systems
In the RS274/NGC language view, a machining center has an absolute coordinate system and nine program coordinate systems.…snip...
You can select one of the nine systems by using G54, G55, G56, G57, G58, G59, G59.1, G59.2, or G59.3 (see Section 3.5.13). It is not possible to select the absolute coordinate system directly.
…snip...
You can make straight moves in the absolute machine coordinate system by using G53 with either G0 or G1. See Section 3.5.12.
…snip....
-
Thanks. I can easily change the firmware to make the G54 WCS the default. Making G53 non-modal is a lot harder and will probably have to wait until the 1.22 release though.
-
That's great!
If a given piece Gcode is somehow dependent on G53 not being modal, a quick insert of G54 (or whatever) after the G53 G0 X… line would be a very easy bypass.
-
Please try firmware 1.21RC5. I believe that workspace coordinates are working correctly in it (including G53 being non-model), with the caveat that this command:
G53 G1 Xnn Ynn …
will work correctly; whereas this:
G1 G53 Xnn Ynn
will not.
-
Please try firmware 1.21RC5. I believe that workspace coordinates are working correctly in it (including G53 being non-model), with the caveat that this command:
G53 G1 Xnn Ynn …
will work correctly; whereas this:
G1 G53 Xnn Ynn
will not.
I will give it a try later today.
Interesting case you have with "G53 G1 coords" vs. "G1 G53 coords". I can sort of see the technical parsing assumptions behind both being valid… at the same time, I've never seen a CAM generated line, or a human generated line of the "G1 G53 ..." variety. Personally, I'd be OK with not covering that case.
-
Hmmmm…. The following would also be valid:
[[language]] G54 G1 Xnnn Ynnn ;Moves to currently active G54 Work Coordinates G53 Xnnn Ynnn ;Moves to machine coordinates Xnnn Ynnn ;Moves to currently active G54 Work Coordinates. G55 Xnnn Ynnn ;Moves to currently active G55 Work Coordinates.And so forth. G1 stays active until another Group1 command is executed.
And, I HAVE seen CAM generated code that looks something like that. Therefore, I take back what I said… eventually, the modalities would need to be correct.
-
New thread that re-summarizes a ton of things about CNC coordinates here:
