More or revamped coordinate systems? about grbl HOT 9 CLOSED

Would you be implementing a single work coordinate system (G54) or more than one (G55 - G59.3)? It seems like a single G54 is a good idea. Can we simply map G92 as an alternate G54 or are there differences in behaviors?

-- (later edit) I just reviewed NIST RS274/NGC v3, sections 3.2.2, 3.5.5, 3.5.13 and 3.5.18. There's more to it.
G54 is for selecting the active coordinate system, G10 is for applying offsets to the active coordinate system for zeroing & other needs, and G92 and G92.3 are for applying (temporary) offsets to the coordinate systems. The offset can be canceled using a G92.1 or G92.3

So the questions I have are (1) is this the way it's actually expected by the world of Gcode generators - which may or may not operate according to NIST, and (2) how much of this do you think it makes sense to implement?

When I looked at this a while ago I sidestepped the coordinate systems and simply used G92 as a simple way to zero w/o managing all this. At least that's what TinyG does, I can't speak for the implementation in grbl. If you want to keep separate machine and work coordinate systems this simplification seems to break down.

from grbl.

I had argued for keeping the things the way they currently are with Mike, mainly for staying with simplicity. He was pretty unrelenting about this and I've come to agreement with him. Implementing G54 (and possibly more work coordinate systems) is the way to go, in keeping to standards and being able to have users understand other CNC systems easily.

Recently I had added a way to retain machine position upon reset. When I did, I had inadvertently added all of the functions that I need to manage coordinate systems. In general, all you have to do is retain the coordinate offsets for each work coordinate system and apply them to the g-code parser and planner when there is a change. In fact, there isn't much that I need to do to get it to work. (I think). All that is required is some memory allocation for storing these: 3 doubles/int32 per coordinate system. So, it would be easy to add as many as we want. Does it make sense to add just G54 at this point, or more? I'm thinking adding one is fine and writing a commented procedure in the code if users want to add more.

One more note on this. G10 is a g-code way of setting the G54+ work offsets in program memory, but this isn't the only way to do it on traditional CNC machines. Most all of them have specific physical buttons to do this at the machine, so it's not necessary for grbl to support G10, if we supply another way to set them through the '$' interface.

As for G92, I agree that this can be the simplest way to handle work coordinate systems, if we don't have the others. G92 does add some complications, since it functions a bit weird. I think we decided to keep G92 and added G54+ work coordinate systems, G92.1+ commands would need to be added as well. I'm thinking that we should drop G92, but is there anyone that wants grbl to keep this?

from grbl.

Sonny: Sounds like a reasonable analysis.

I implemented a similar method where values are passed through a translation layer on their way into and out of the gcode interpreter. All coordinate operations are performed in internal canonical form, which is in machine coordinates in mm. Adding work offsets to this adaptor layer is relatively straightforward. (I've seen some Gcode implementations that do not work this way and if you change coordinate systems they go crazy).

I would argue for only one coordinate system, the G54, at least for now. Let's find out if there is a need for more before adding more.

For G10, regardless of whether or not you can set offsets using $ commands I'd like to be able to do this using G10s. NIST specifies a bunch of parameters in the 5200 series that select coordinate systems and specify offsets (ref: 3.2.1, table 2). While we don't need to replicate the number system, that is (in effect) what we are doing by storing these values.

It sounds like its not necessary to have a G92 if you have a G54 and a G10, but I don't think I know the uses cases well enough to offer an informed opinion. Is this part of how people would like to perform a homing / zeroing operation? Doesn't sound like it, but I could be wrong. Are there use cases for G92 for hand-coded subroutines, like replicating patterns? Do we care about hand-coded Gcode? I think we need a bit more exploration here. M. Mike seems to indicate that it's not used because it's not standard, and that might be the ultimate answer.

from grbl.

There doesn't seem to be that great of a use for G92, if you have the standard work coordinates. You should be able to do exactly the same thing, but the input would be machine coordinates indicating work zero versus what you want. A little different, but the same, especially since grbl now reports machine coordinates. If G92 is removed, I think it would be good to install maybe 2 or 3 work coordinate systems to compensate for the loss of it. M. Mike states that 6 work coordinate systems are standard across all machines, and anything greater are usually add-on packages.

As for hand-coding, I see this very frequently done in practice at the machine shop in my lab. Mainly for replicating patterns, as you say. It can be much faster to do this directly in g-code than creating multiple operations in a CAM program. Again though, since G54+ can do the same thing, the death knell for G92 is sounding.

Good idea on the translation layer. I will try to integrate something similar. It may have to reside in the g-code.c source so it can easily translate G53 non-modal absolute calls.

from grbl.

I don't think there's a sentimental attachment to G92, but I think a number of people have used it in their console programs to zero the machine. So those consoles would break with the new version. I'm not saying things should or should not be backwards compatible, - it's just an observation. I think the question of backwards compatibility should be raised.

6 work coordinate systems. Hmmm. That's a lot of flexibility. What do we know about whether the common Gcode generators grbl users are using support this - Pycam, CamBam, ReplicatorG, etc., as well as hand-coded Gcode? I'm tempted to rough in 6 but start with 1.

Part of Simen's early "mission statement" was to support common machine generated outputs - which is why things like tool length offset and cutter radius compensation are not in there - as they are generally dealt with in the Gcode generator and not the Gcode itself. It would be good to discuss the direction on hand-coded Gcode. Increasing support for hand-generated Gcode ultimately takes you down the path the above, and possibly subroutines (O codes), expression evaluation and a bunch of other stuff.

from grbl.

You're right about being backwards compatible with G92. I've been mainly trying to avoid having to support the rest of G92, which are the .1, .2, and .3 commands. Without them, G92 can be unmanageable with the standard work coordinate systems.

Agreed that six work coordinate systems are a lot, but this is what is standard on production machines. Grbl does not have to follow this framework, but it definitely needs to have a minimum of one work coordinate.

As for hand-coding, I don't think that grbl will ever support macros or functions, but you can still do a lot with the standard gcodes that it already has. I think the only thing missing is the work coordinates, which are supported by all CAM systems, as G54 is always the default.

Either way, I'm begrudgingly going to try to see what it will take to install the rest of the G92.X commands, along with two work coordinate systems. I'll likely only enable one and comment out the other for user reference.

from grbl.

This all makes sense. Let me know how the exploration goes. I'll be doing similar work. I do think G10 is important and am working through a way to support both G10 and $ operations for setting offsets.

from grbl.

Sounds good. I'll install G10 as well.

Also after looking into the G92.x commands, I think I'll not include G92.2 and G92.3. These require the offsets to be kept in memory and when re-enabled between programs, these offsets can cause some issues. (Smithy) I think it would be best to always zero out these offsets both upon reset and disabling it.

from grbl.

Good news! Got everything working this evening and it actually simplified the coordinate management by only allowing the planner to see the machine coordinate system and having the g-code parser handle all of the translations. I've wrote it so that grbl can support up to 6 work coordinate systems via a compile-time config option. It will default to one. The work coordinate systems will be retained upon a soft reset, but not a power cycle. (could be something that eeprom could do, if needed.)

Also, I rewrote portions of the parser to do error checking like modal groups and missing parameters. It didn't blow things up very much. Only 1.5kbyte bigger flash.

I've got to test everything thouroughly to make sure nothing inadvertently broke elsewhere and clean and optimize the code a bit. Should be posted later this week.

from grbl.