G53 command
-
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 -
@mwinterm said in G53 command:
@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....The results of what you are saying are identical to the results of what I'm saying.
- The way the NIST standard phrases it:
The machine is in a coordinate system, such as G54. A G1 move is executed. The numbers in the axis words of G1 are "applied" (either directly for G90 or via math for G91) to the starting position to derive an ending position in the active coordinate system. This position in the active coordinate system is then offset (more math) to the absolute (aka G53) physical position desired, and the machine is moved there.
Your phrasing:
The machine starts at an absolute machine position. A G1 is executed. The numbers in the axis words of that G1 are "applied" (directly for G90, with math for G91) to the machine starting position to derive a machine ending position. The machine moves there.
Same thing... same results... except the first phrasing is actually how the NIST interpreter works (the source code for the interpreter is available).
The one place where these are different is the reason they do the more elaborate sequence. It is perfectly legal in G-Code to change the offset of the currently active coordinate system, WITHOUT physically moving the machine. This really only affects the next move when G90 is active... Nonetheless, writing the code to ALWAYS do the same calculations (after the G90/G91 step of the calculations) is simply more "internally consistent" in the code itself, thus potentially avoiding obscure bugs.
-
For G91, the way we are both describing it is "start, math with G1 numbers, move".
You are assuming it all starts with the G53 absolute, and the code is actually written to start with "currently active" coordinate system numbers, for internal consistency reasons with the way that G90 must work.
-
@dc42 Thanks for the hint. That helps...
PS: ...is my assumption right that the behavior is the same for *.g files in the system directory?
-
@mwinterm said in G53 command:
@dc42 Thanks for the hint. That helps...
PS: ...is my assumption right that the behavior is the same for *.g files in the system directory?
No. So if you print a file that doesn't have M82 or M83 near the start, then the result could depend on whether the previous file you printed contained M82 or M83. The initial M82/M83 state will be the same as at the end of config.g.
-
@dc42 : Starting a new program is typically no problem as CNC program always explicitly contain G90 or G91 already at the beginning.
My specific problem at hand if I have a stall detected I want to re-home during a program. So I have in rehome.g
M24
G28
M25
where G28 again calls homeall.g which contains a G91 at the beginning and a G90 at the end. Assuming the program was running in G91 before the stall this would generate a problem...PS: Could the problem be hacked around by call a Macro from the homeall.g?
-
You shouldn't need the M24 and M25 commands and I suspect they won't work anyway, but you might want to lift Z a little at the start and lower it at the end of rehome.g. The G90/91 and M82/83 status and feed rate will be preserved automatically.
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: Normally M25 calls the pause.g and M24 resume.g if present. In there is my spindle stop / retract and my spindle start / re-approach code. However the pause command called by M915 seems not to execute those procedures (that is why I called them explicitly which as you predicted didn't work either). Is there a reason for this?
-
On a 3D printer it isn't necessarily appropriate to run the full pause/resume routine. If you want to run the full routine on your CNC then you could put M98 Ppause.g at the start of your rehome.g file, and M98 Presume.g at the end.
-
@dc42: ok, thank you!
PS: ...regarding G53 I checked Heidenhain and Sinumerik.
- Heidenhain uses G53 in a different context (selecting a WCS from a table of WCS). However the equivalent to our G53 are M91/M92. The allow for relative positioning. Tool length and other compensations are not respected. They are used for positioning the machine on specific positions on their axis as for tool change, etc.
Sinumerik: Seems to use G53 just a another predefined coordinate system from the machine even including tool compensation. By adding D0 tool compensation can be deactivated tough. However for the purpose of tool change Sinumerik provides the G74/G75 commands. But they are used a bit differently as you can predefine machine specific points than then are selected with these commands.
