G53 command
-
@mwinterm Hmmm... I very strongly agree that G53 arguments are "machine coordinates", with absolutely no offsets of any kind. Nothing else makes sense to the operations that occur on real machines, as you've pointed out.
I also agree this is shown in the HAAS vid, right around 1:28.
The "Hmmm...." is because of the odd phrasing in the NIST standard. Let me poke around a bit more.
-
Well, I can't find anything in the standard. However, the standard is an attempt to describe the interpreter itself, and the interpreter is still available. Old, and in a very old "coding style"... but still out there.
Reading the old RS274NGC source, tool offsets are not applied when G53 is (non-modally) active.
As we all said...
-
@dc42: This post kind of also relates to the G0/G1 discussion I raised in another post (https://forum.duet3d.com/topic/7728/g0-vs-g1-movement). For the G53 to really function correctly for tool-changes etc. bed compensation also needs to be disabled for G53 G0... . I'm not aware if the standards say anything regarding G53 G1... but having G53 G0 ignoring all compensations (WCS, Tool & Bed) and having G53 G1 ignoring only WCS and Tool but keeping bed compensation in could give all the options.
-
Thanks to all of you for the references. I made a change ni 2.02RC5 so that tool offsets are not applied when G53 is active.
-
@dc42 Thanks a lot. Already built and tested it (even though not yet extensively) but everything seems to work fine
-
@dc42 : ...just noticed that there is already a built RC5 available... However I saw that in the release notes you refer to a modification of G54 instead of G53.... small typo but could be confusing as G54 (i.e. WCS) should for sure take tool offsets into account....
-
@mwinterm said in G53 command:
@dc42 : ...just noticed that there is already a built RC5 available... However I saw that in the release notes you refer to a modification of G54 instead of G53.... small typo but could be confusing as G54 (i.e. WCS) should for sure take tool offsets into account....
It should have read G53. I have corrected it.
-
@dc42 I detected another behavior of G53 which I believe is not correct. If G91 is selected G53 also makes relative moves which I believe is not correct. As outlined in earlier posts G53 is typically used to move to fixed machine position e.g. for tool change... This should happen independently of if G90 or G91 is selected.
-
@mwinterm I don't see why G53 should not allow G91! Currently used coordinate system and relative vs. absolute moves are two completely different things. I can imagine quite a few scenarios where relative moves are needed even with G53.
-
The NIST standard appears to be silent on whether moves are always absolute when G53 is used, or are affected by G91. Does anyone know what Fanuc, grbl or Smoothieware do?
-
On my Fanuc machine (16i control) when I try a incremental (G91) move in G53 machine cord. the control doesn't move. It just ignores the command. No error, it just doesn't move. Where an absolute (G90) command moves as it should.
I can't speak for all machine controls but for a majority of them (all of the ones I have run) the G53 work cord is not modal. Meaning if you need a move that needs to be carried out under the G53 machine cord, the G53 must be in the same line with the move. When the next move is executed the work cord resorts back to what ever work cord you are using.
Example If I am running a program under a G55 work cord, And I want to go to a fixture reference point with G53 here would be my command - G0G90G53 X4.1 Y16.114.
If the next line of my program is G0 X1.0 Y0.0 the machine will move to X1.0 Y0.0 position of G55 not G53. I would have to include the G53 in line same command to go to the machine cord X1.0 Y0.0.
You can't really put the machine work cord in G53 and have it remain active until you call up a different work cord like G54 or G55. You can reference the G53 at anytime during your program operation by specifically calling it out in the line during the command.
I can't say what smoothieboard or grbl does.
Why would you need a G91 incremental move when referencing the machine work cord? Just curious?
-
Thanks, Tim. G53 isn't modal in RRF either, so if only affects the remaining commands on the current line. However, RRF treats multiple G or M codes in a line as separate commands and executes them sequentially. So for RRF your example would have to be rewritten as either "G90 G53 G0 X4.1 Y16.114" or "G53 G90 G0 X4.1 Y16.114", or just "G53 G0 X4.1 Y16.114" if the movement mode is already absolute.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 said in G53 command:
Thanks, Tim. G53 isn't modal in RRF either, so if only affects the remaining commands on the current line. However, RRF treats multiple G or M codes in a line as separate commands and executes them sequentially. So for RRF your example would have to be rewritten as either "G90 G53 G0 X4.1 Y16.114" or "G53 G90 G0 X4.1 Y16.114", or just "G53 G0 X4.1 Y16.114" if the movement mode is already absolute.
Thanks for the info David.
My next project is going to either be a cnc mill or cnc plazma cutter. I am in need of both
Of course I will be using a DuetWifi to control it.
-
The standard is silent; pragmatic real world use speaks volumes.
Consider trying to probe* for the corner of a fixture. Operator puts the probe "near" but "off of" the corner of the Xmin Ymin edge of the fixture. Probe now needs to repeatedly move Y+ (stop if probe contacts) and Y-, then slightly X+, then repeat. A linear rectangular grid search for the corner. This can only realistically be programmed (as a reusable script) with relative moves, and the human operator MUST have the results in G53 coordinate system to "know" where that fixture is for future use.
Repeat for X.
.
* Non-CNC folk may only be familiar with Z probes. CNC machines often probe "sideways" with the bit itself as the probe. Metal to Metal contact, no switches or inductors or whatever. Just the bit, and the fixture or metal workpiece/stock about to be cut.
-
@mwinterm said in G53 command:
In Wikipedia it states:
G53 Machine coordinate system : Takes absolute coordinates (X,Y,Z,A,B,C) with reference to machine zero rather than program zero. Can be helpful for tool changes. Nonmodal and absolute only. Subsequent blocks are interpreted as "back to G54" even if it is not explicitly programmed.
If tool length compensation would be considered this would not work for tool change (which is my problem).
https://smithy.com/cnc-reference-info/coordinate-system/machine-position-commands/page/0 also states: Regardless of any offsets that may be in effect, putting a G53 in a block of code tells the interpreter to go to the real or absolute axis positions commanded in the block.
Another reference on Youtube.
I think it is very clear that G53 is referring to absolute machine coordinates.
The current behavior of G91 in combination with G53 means G53 is effectively ignored. I also can not imagine how a relative move in machine coordinates should look like. Ignoreing G53 would mean a modal command precedes a specific command like G53 which is also wrong in my understanding.
@Catalin_RO I can not follow your example as a combination of G91 and G53 means thatG53 is ignored, so no need for using it...
On the other hand the current situation can be very dangerous. If someone happens to work with G91 and then issues a command like Tool probing, tool change, lubrication routines.... they will not work correctly and can lead to potential crashes.
The Fanuc behavior described by @timcurtis67 is save but still I believe G53 should temporarily override G91. When working in G91 and I e.g. want to remeasure my tool I would first have to issue a G90 (not a big problem) but after the tool probing I have to remember if I was in G91 and if so re-issue the G91 (very impractical).
I can check next week how Heidenheim and maybe as well Siemens is behaving. -
While I said earlier that the NIST standard is not clear... I really was being lazy and did not want to explain. It is VERY clear, when you combine the pieces.
First, keep in mind that the machine is ALWAYS in a coordinate system. It is in G54 if no prior G54/5/... has been issued. It is in G53 ONLY on a line that contains G53 (i.e. G53 is non-modal).
That bears repeating: Whichever is active at that moment, there is ALWAYS an active coordinate system. With that in mind, G90/91 become quite transparent.
G90 and 91 work in ANY coordinate system, G54, G53, G54 whichever is active.
And... just to address the comment "can not imagine how a relative move in machine coordinates should look like", it looks like this: The machine has a position in G53 coordinate space prior to the move. (In fact, the NIST standard specifies which "parameter number" (think of it like a register or a variable) holds these position numbers for X/Y/Z/A/B/C)
If G91 is active, the numerals specified on each axis in the G0 or G1 are added to the current G53 coordinate, and the machine is then moved (via coordinated linear motion) to that G53/absolute position. Exactly the same as if G54 and G91 were active, etc.
Again, G53 relative moves are VERY common in the actual world of CNC operation.
-
To summarize:
G53 is "absolute machine". G53 is non-modal. G53 is therefore only 'active' on the line where it appears.
G54/5/... can be offset from absolute machine. They are modal. They stay active for all following lines until changed.
When G90 is active, G0 or G1 move axis numbers specify a position in that active coordinate system, including G53, G54, G55...
When G91 is active, G0 or G1 move axis numbers specify a position relative to the current position in that active coordinate system, including G53, G54, G55...
-
@Danal sorry for being ignorant, but I don’t get it: A machine can only have one physical position. Assuming that we don’t deal with rotated coordinate systems which coordinate system you are in is only relevant for G90. In G91 mode coordinate systems are completely irrelevant as the move is just added to the current physical position independent of in which coordinate system they are represented i.e. the selected coordinate system only affects the numbers displayed but not the real position.
Please help me if I miss something here.... -
Sorry, I correct my statement. If dealing with non-Cartesian systems like in hang printers or 4- and 5-axis systems relative G53 moves could make sense.
However still wondering how Haidenhein an Siemens deal with the problem...PS: is a G90 or G91 called from within a macro still active after the macro is finished? If so is there a way how the G90/91 mode active before the start of a macro could be re-established after the macro... this would be another way to deal with the issue....
-
@mwinterm said in G53 command:
PS: is a G90 or G91 called from within a macro still active after the macro is finished? If so is there a way how the G90/91 mode active before the start of a macro could be re-established after the macro... this would be another way to deal with the issue....
The G90/G91 state just prior to the macro being executed is restored when it ends. So you can safely use G90 and G91 within macros.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com
