Need help with a G92 Question

[tas99]

I got the basic Mach3 Plasma post in SheetCam working just fine but I'm having trouble with the 'Mach3 THC with scriber' post.

The problem I see is that the G92 function is not working properly. I took the following bit of code from that generated by the post-processor so I could see what was happening. The way I thought it should work is the G92 function in line 110 should happen after the G31 triggers the sensor. The problem is that as I watch the head move down the Z is zeroed before it hits the switch and the resulting Z is not 0 but a value determined by the length of travel after the Z 0s and the sensor is tripped. As a result all the Z move functions after that are incorrect because they assumed the Z was zeroed.

Just for info I posted the entire code below the code I shortened. I used the shortened version to better see what was happening but the problem occurs in the full code as well.

N0010 (Filename: 2 6x6.tap)
N0020 (Post processor: Mach3 THC with scriber.scpost)
N0030 (Date: 01/04/2020)
N0040 G20 (Units: Inches)
N0050 F1
N0060 G53 G90 G40
N0070 (Part: 2 6x6)
N0080 (Operation: No Offset, 0, T1: Jet tool)
N0090 G00 X0.0000 Y0.0000
N0100 G31 Z -100 F19.685
N0110 G92 Z0.0
N0120 M30

Entire code;
N0010 (Filename: 2 6x6.tap)
N0020 (Post processor: Mach3 THC with scriber.scpost)
N0030 (Date: 01/04/2020)
N0040 G20 (Units: Inches)
N0050 F1
N0060 G53 G90 G40
N0070 (Part: 2 6x6)
N0080 (Operation: No Offset, 0, T1: Jet tool)
N0090 G00 X0.0000 Y0.0000
N0100 G31 Z -100 F19.685
N0110 G92 Z0.0
N0120 G00 Z0.2930
N0130 G92 Z0.0
N0140 G00 Z0.1181
N0150 M03
N0160 G04 P0.5
N0170 G01 Z0.0591 F3.937
N0180 Y6.0000 F75.0
N0190 X6.0000
N0200 Y0.0000
N0210 X0.0000
N0220 M05
N0230 G00 Z1.0000
N0240 Y7.2872
N0250 G31 Z -100 F19.685
N0260 G92 Z0.0
N0270 G00 Z0.2930
N0280 G92 Z0.0
N0290 G00 Z0.1181
N0300 M03
N0310 G04 P0.5
N0320 G01 Z0.0591 F3.937
N0330 Y13.2872 F75.0
N0340 X6.0000
N0350 Y7.2872
N0360 X0.0000
N0370 M05
N0380 G00 Z1.0000
N0390 Y0.0000
N0400 M05 M30

[acourtjester]

I have seen this and it seemed to me that you did not zero out the Z DRO before you started the G-code and the -100 is not long enough and the Z stops traveling down before the touch is made. Are you using a Ohmic sensor or a floating head switch, it seems your line 120 the has a large offset (0.293 ) for either. When I used a floating head I had an offset of about 0.028" and Ohmic sensor is like 0.0"

[tas99]

Some additional info;

I tried these two snippets of code. One worked, the other didn't.

This didn't work;
N0010 (Filename: 2 6x6.tap)
N0020 (Post processor: Mach3 THC with scriber.scpost)
N0030 (Date: 01/04/2020)
N0040 G20 (Units: Inches)
N0050 F1
N0060 G53 G90 G40
N0070 (Part: 2 6x6)
N0080 (Operation: No Offset, 0, T1: Jet tool)
N0090 G00 X0.0000 Y0.0000
N0100 G31 Z -100 F19.685
N0110 G92 Z0.0
N0120 M30

This worked;
N0010 (Filename: 2 6x6.tap)
N0020 (Post processor: Mach3 THC with scriber.scpost)
N0030 (Date: 01/04/2020)
N0040 G20 (Units: Inches)
N0050 F1
N0060 G53 G90 G40
N0070 (Part: 2 6x6)
N0080 (Operation: No Offset, 0, T1: Jet tool)
N0090 G00 X0.0000 Y0.0000
N0100 G31 Z -100 F19.685
N0120 G04 P5.0
N0130 G92 Z0.0
N0140 M30

The only difference is the pause I put after the G31 (line 120)

The detector is not a switch, it's an inductive proximity sensor. It seems 100% reliable. It always senses and stops the Z motor and I can see the input recognized on the Mach3 diagnostic screen. I would think if it were noise it would work some of the time and the fact that the one set of code posted above that worked would be subject to the same noise or detector problem. I ran each one 10 time and one worked 100% and the other failed 100%.

I zeroed the Z to the metal surface before starting, no change.

Also, if I step through the program it works fine. That's why I inserted the pause.

[robertspark]

How are you running Mach3

Parallel port?
Motion Controller? (which one?)

if a motion controller, G31 operates outside of Mach3 and resides within the motion controller, hence a pause at the end of the motion is probably a good thing as it will allow the buffer for the motion controller to catch up with Mach3 and it's internal loops as the motion controller needs to hand back control to Mach3 and tell it that the skip signal (probe {G31}) has been triggered / tripped, which will then in turn allow mach3 to zero (via temporary offset G92) the z axis.

Your delay should not need to be very long, but it will probably be related to the motion controller buffer size or mach3's loops (0.1 second should be enough..... but really 0.5 second should not be "that" much of an issue in the whole scheme of things of life....)

[robertspark]

..... the other thing worth considering is the skip signal (probe trigger) its self....

The machine is moving downwards..... it is moving at a specific velocity (F19.685 {bit of an odd number.... but each to their own....})

When the skip (probe input) signal triggers, the machine will not stop instantly.... it will decelerate to a stop...... yes this deceleration distance and time will be very small given the Feedrate for probing should be low (and your axis acceleration / deceleration rate much higher).... but is will be an ever so slight deceleration....

The risk with handover back to mach as soon as the skip signal is triggered is the machine has actually not stopped moving downwards .... and Mach3 has reset the G92.... and moved on....

[tas99]

I'm using a Novusun NVUMv2.1 USB card and 4 DMT542T motor drivers running the latest version of Mac3 and SheetCam to generate the G code.

What I've seen is that the delay has to be long enough for the floating Z to actuate the proximity sensor and from about 1" above the metal anything less than 3 seconds won't work. If the delay times out before the floating Z is activated the next line of code is executed. In this case it's G92 which zeros the Z and when the floating Z is finally actuated the Z value is the distance traveled after the Z was zeroed. Usually about 0.5" if the Z started 1" above the plate.

With the delay operational I've measured the torch height of all the resulting Z movements and they are right on.

The F19.685 was generated by SheetCam and I thought it a bit odd as well. It must be the result of some calculation.

[djreiswig]

19.685 inches is 500 mm

[tas99]

That must be why. The program is written with mm so the conversion must result in that number with no rounding.