G53 command

mwinterm

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....

dc42

@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.

Danal

@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.

Danal

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.

mwinterm

@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?

dc42

@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.

mwinterm

@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?

dc42

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.

mwinterm

@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?

dc42

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.

mwinterm

@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.