Probe function only 1/2 working.

[infernozx]

Problem description

Probe function works when inputted into the input line at the bottom of the program, fails to function when placed in the g-code .tap file, and then loaded via the program.

Expected Behavior

I'm using a G38.2 Z-10 command, in order to find the top of the plate, before pulling off using a G38.4 Z20 command, this should stop the torch just as it's lifting from the plate. Then I run a G92 Z0 command, to set that as Z0, and then I move the torch to cut height, before running the remainder of the program.

I have written this directly into the g-code file. The program should be running this sequence before each and every M03 torch light. This is to compensate for warping between cuts.

Actual Behavior

The above all works if you input it into the input bar at the bottom of the program. Something like: F600 G38.2 Z-10 (Machine moves down, contacts the plate and then stops. F600 G38.4 Z20 (Machine moves up, until contact is lost, and then stops. G92 Z0 (DRO window on machine sets Z to 0.00) Z3.6 (Machine moves to cut height) M03 (Torch lights.)

When the following is put into a file, and loaded as a program:

F600 G38.2 Z-10 F600 G38.4 Z20 G92 Z0 Z3.6 M03

The Z axis moves downward, and then hits the plate, triggering the probe switch, but continues pushing a moment before displaying the message "ALARM: Probe Fail"

Steps to Reproduce the Problem

Input the above code in the two different methods, unsure if this could be experimented with in the X and Y axis, as I only have the probe setup for the Z.

Specifications

Version

UGS Platform 2.0

Operating system

Lubuntu

Platform

GRBL 1.1 (I think)

Other

[AbySet]

"but continues pushing a moment before displaying the message "ALARM: Probe Fail"

Seems like there is a missing electric contact on prob hardware, check it with multimeter from probing tool to the controler. You could also use probing plugin included in ugsplatform.

[infernozx]

I rebuilt the probe, and the wiring to eliminate loose connections.

Its 100% consistent. Fails with program entry via loading a file. Works with entry via the command input line.

I can check for voltage while it's running the two cycles. I'll report back.

[infernozx]

Update:

I'm still fighting this problem.

I re-aligned the probe switch so it would better engage, I thought maybe it was JUST triggering, and then causing problems on the rebound.

Then I got frustrated with the switch, and eliminated it. I became the switch as I manually stuck the wires together to trigger the probe circuit.

When at idle, the circuit reads 5v. (4.98) When I put the two wires together, obviously it reads 0v.

I also slowed down the feed, in order to ensure it wasn't just moving too fast to get a good reading.

I manually typed in the following lines:

F200 G38.2 Z-10 It probed down correctly. Then I ran: F200 G38.4 Z60 It probed up correctly.

So then I loaded a program that had

F200 G38.2 Z-10 F200 G38.4 Z60

in the middle of it, it completed the first line, and on retracting the probe from the work, it triggered an:

ALARM: Probe Fail

So I took the code that was in front of the F200 G38.2 Z-10 out of the program.

I ran it, and it again Probe Failed.

So I took the code from behind the F200 G38.4 Z60 out, intending to literally just run a text file containing:

F200 G38.2 Z-10 F200 G38.4 Z60

But then UGS repeatdly crashed and wouldn't let me load the file. It lets me start, it connects to the GRBL, it will run the home function $H, and as soon as I Browse, choose my file tester.tap, it crashes.

[AbySet]

So it's working on command line but not from a file, that mean only one think: Probing can not handle many commands at the time, it needs some delay before doing the next command, if so, you can try to put a delay between the commands in the file, the syntax for that is: G04 P0.5 (for 0.5 second), try to figure out how much delay each move need and put it after that move command in file. Try that and let me now.

[infernozx]

I'm not sure if this thread is appropriate, but I managed to find out what was crashing my UGCS.

If you load a file, that doesn't have a movement, then the program crashes.

So a text file containing:

F200 G38.2 Z-10 F200 G38.4 Z50

Will not load, and UGS will crash.

I added:

G00 Z40 to the end of the above program, and it loads in UGS fine. I feel like while it's unlikely that people will be loading blank, or erroneous files, it wouldn't be hard to have it quickly check the file for a valid piece of motion, and then throw a warning if it doesn't.

Now onto my original issue:

I loaded the following:

F200 G38.2 Z-10 G04 P0.5 F200 G38.4 Z60 G00 Z40

It loaded, and ran without any probe problems. so I went back and added the G04 P0.5 into the original file, and ran it. It failed. The only difference between the two now, was the feed rate. (Feeding 60mm at F200 is noisy and painful, so I was feeding at 600.

For whatever reason, I think it's a debounce issue, (I have debounce on my GRBL setting for the homing because i found it was required.) It would be nice if we could get a probe debounce, or perhaps that causes other issues with how other people use probing?

I'm not sure if it was the feed-rate, or if it was the pause that was causing the problem originally, I'll go back and remove each one in turn to see how it plays out. I'll try to remember to come back and update.

I'll also leave this open for now, I'm not sure if we want to open a new issue with the crashing because of the file load, (with a more appropriate title) or if we want to keep this to have a background behind the issue.

[infernozx]

More info:

I removed the pause, and it kept working. I then added a feedrate of 600, and it kept working. I'm at a bit of a loss. I think I might have had a compound problem. To start a loose connection, and then once that was fixed a feed rate that was just a little too high.

It seems to be working fairly flawlessly now.

[AbySet]

Nice finaly, so we can assume this issue resolved from compound problem. Hapy for you.

[bduplan]

I just experienced the same exact problem and wanted to post my solution for any future searchers. My problem was not the probe itself. In UGS, the command table showed the G38.2 successful, the G92 successful, and then the following command failed. It did say Probe Alarm, which is what lead me here. It turned out my next move didn't have a G00 before the Z move, and it was still in G38.2 mode (hence the Probe Alarm). The problem was in my post processor. I had post.ModalText for everything except that one G92, which was just post.Text, so I guess that left the mode in G38.2 probe, which it couldn't do because the switch was open (I have a floating head).