Homing and G92 issue

mwinterm

Hello,

I'm using a DuetWifi to control a CNC router. I'm currently running into an issue with using G92 for homing.
When having a WCS and/or Tool compensation set and homing with G92 the position specified in G92 is including the WCS offset and the tool compensation. Therefore the new zero after homing is off by the WCS-offset and the tool length. This behavior of G92 is in my understanding correct but undesired for homing the axis. Is there a command / method to set the absolute machine coordinates of the axis after hitting the end-stops?

However the current implementation of G92 can lead as well to the following undesirable and potentially dangerous behavior. In the case of my machine the travel in X is 600mm and I want this to correspond to machine coordinates 0-600mm which I do with homing the axis to the end-stop on the left and setting it to 0 with G92 X0. After that I e.g. set a A WCS at X300 by G10 L2 X300. I can now issue G0/G1 commands with X-values between X-300 and X300 (any values outside produce a G0/G1 outside machine limits as expected) . Now I home the X-Axis again with issuing a G92 X0 at the left end-stop leading to the offset as described above. However the real issue now is that when now sending a G0/G1 with X-values greater than 300 I get a G0/G1 outside machine limits even tough I have an additional 300mm on the X-axis. But even worse if I do a G0/G1 to e.g. X-100 I run a collision. I think this behavior is faulty.

Best regards,
Marc

mwinterm

Sorry, first part regarding homing got obsolete. The problem can be solved by setting the ranges accordingly with M208. However general issue regarding G92 is still valid....

dc42

Why are you using G92 in your homing files at all? Normal practice is to adjust the M208 lower or upper limit (depending on where the endstop switch is) to be the required coordinate when the end stop triggers.

mwinterm

@dc42: Yes you are right as I already outlined in my second post. I originally started off RepRap Firmware configurator and it gave me G92 which I stayed with... However now I removed it.
However the G92 behavior is nevertheless faulty as after using it the machine limits are not correct anymore.

dc42

I've just read what the NIST GCode standard says about G92, and it appears to me that G92 is supposed to behave in the same way as G10 L20 - in other words adjust the coordinates of the current coordinate system only (not the machine coordinates) to make the current tool have the specified coordinates. This makes it incompatible with using G92 in homing files.

One possibility would be to implement G92 as per the NIST standard when CNC mode is being used and G53 is not in effect, i.e. adjust the current workplace coordinate offsets and not flag the axis as homed. It would be an error to use G92 when the axes mentioned have not been homed.

When G53 is in effect then G92 would be allowed when the axes are not homed, set the machine coordinates and flag the axis as homed.

Does that sound OK?

mwinterm

Yes, for me G92 should behave exactly like G10 L20 i.e. it should as well handle the machine limits in a correct way. I don't see any reasons to allow G92 before the machine is homed.

My understanding regarding the different coordinate systems for CNC is the following:

Level 1: Machine coordinate systems
Are typically set only once and are rarely changed over the machines lifetime.
Using M208 in the config file makes sense for me here.
Level 2: Working Coordinate Systems (WCS) , G54...G59.3
They are more dynamic and mostly refer to setups that can be individual to a certain job, but can also refer e.g. to a corner of a vise or the center of 3-jaw chuck mounted.... They are typically set by the machine operator prior to running a program and only referred but not modified by the NC-program. (*)
Level 3: G92
The G92 command is typically used to set a WCS from within a program e.g. for machining a number of identically parts in a row (to do so you make a loop in the NC-code and at the end of the loop there is e.g. G92 X-50 for shifting the WCS by 50mm for the next iteration).

That at least is my take on it. Additionally there should be as well a command to cancel G92. Sometimes this is G92.1.

(*) PS: ...in that context for doing CNC with the Duet my biggest two wishes currently would be:

G53...G59.3 should be automatically stored like it is done for the bed-compensation
Same thing for tool-offsets: In the NC world the tools are not so static as in the printing world where you typically define them in the machine configuration. But it is also annoying to re-zero the tools anytime the control is restarted.

dc42

Looks like there is a fundamental difference between G92 on RepRaps and G92 on at least some CNC machines. On RapRaps, a command such as G92 Xnn is used to mean "Treat the X axis as having now been homed, and its current position is nn".

0n10n

DC42, 1) Is there documentation detailing the deviations between the NIST Standard & RepRap? 2) Are there any plans to modify the RepRap deviations so that the NIST Standard is followed rigorously?

Link to NIST Standard for reference; https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=823374