G38.2 randomly stops

Hello all,

I need some help. I am working on a series of tutorials on making a touch off plate and configuring it under LinuxCNC. I am running AXIS GUI and v2.6.7 of LinuxCNC.

I am using parallel port pin 15 for the input pin, it is pulled low normally. My other wire is 5V.

The pin is netted to probe-in. When watching the pin with Hal Meter, it is false when not making contact, and true when it does make contact. This seems to be all working fine.

When I go to MDI and issue the command

G38.2 Z-5.5 F2.5

The command starts to run then will stop before making contact. I am getting no errors. When I rerun the command it will continue. The length that it runs seems to be random. Sometimes it stops as nearly as soon as I press the button. Other times it will run longer. Once in a while it will run to completion.

I have made a video demonstrating what I am talking about. Does anyone have any suggestions? I will try to link the file but I am not sure how. The youtube video is located here:



Joe

I would use halscope to see if there are false triggers on the pin. halmeter won't always show fast triggers.

Ultimately what I would be checking for is induced noise in the probe wires.

Chris M

I done this before I read your post Chris, but I made some changes.\

I changed the input pin on the BOB from being pulled LOW to pulling it HIGH.

Changed the PIN in the hal file to parport.0.pin-15-in-not, and brought out a ground wire from the 5V power supply. Tested it with Hal Meter to make sure it was detecting it. The started running the command again.

This time, I could probe from any location on the Z-Axis ant several different feed rates, so maybe running it the other way was the issue, but either way it should work shouldn't it?

I will say this, when probing at slow speeds, it would stop and Hal Meter would read false, but running the command again only moved it one step. So I guess it is catching some bounce. I guess HAL Scope would confirm this? Also, sometimes when it is true and I go to retract, I get an error that says "Probe tripped during non probe MDI command. Again I suspect this is from bounce.

I think using hal scope may be the solution here (but I need to learn how to use it), The BOB I have will pull the input pins either high or low by moving a jumper. They are pulled with a 4.7K resistor either up or down.

For what it is worth, the BOB I have is the CNC4PC C10, you can find the manual here: cnc4pc.com/Tech_Docs/C10R10_USER_MANUAL.pdf

And the manual shows a touch off plate with the input pulled high and a ground wire.

Anyway, suggestions are welcome.

Joe

Probes are notorious for interference based false readings.

If you are probing slowly you have quite a bit of scope for using a higher debounce value if necessary and not traveling any appreciable distance extra in the ms that might take.

Another options is screening and grounding one end of the lead.

My favorite, use a 12v plus low wattage plugin PSU to power the probe line and have this activate a SSR which switches a 5v / 3.3v feed to the BOB.

I have used this a few times, especially with limits, the switches are completely noise immune and the SSRs make and break so rapidly there is no lag.

regards

ArcEye wrote:

Probes are notorious for interference based false readings.

If you are probing slowly you have quite a bit of scope for using a higher debounce value if necessary and not traveling any appreciable distance extra in the ms that might take.

I will take a look at the HAL debounce.

ArcEye wrote:

Another options is screening and grounding one end of the lead.

That would explain why it worked so much better when I changed the input to a high and brought a ground wire from the PSU. Although, I am not sure what you mean by screening.

ArcEye wrote:

My favorite, use a 12v plus low wattage plugin PSU to power the probe line and have this activate a SSR which switches a 5v / 3.3v feed to the BOB.

I have used this a few times, especially with limits, the switches are completely noise immune and the SSRs make and break so rapidly there is no lag.

regards

Is this to keep your signal wires as short as possible? Is there a supplier of specific brand or type SSR that you recommend?

Thanks again,

Joe

andypugh wrote:

A standard touch-probe is short-circuit when not tripped, and tends to be fairly noise-immune because of that.

So maybe I should but a touch probe. I will have to do some research and see what is available for me. I am using a Hitachi router and have both 1/4" and 1/2 collets for it. But it seems to me, that going with a regular probe, I would have to use tool length offsets and figure a way to get the tools in the router at the same depth. I think, at least on the surface, that I need to use the tool as the switch.

andypugh wrote:

There is a software debounce component that can help in your situation. I think that probe inputs are monitored in the servo-thread so a software debounce running in the base thread won't introduce a delay.
www.linuxcnc.org/docs/html/man/man9/debounce.9.html

ArcEye mentioned the debounce too. I will certainly look into it.

I am trying to develop the tutorial so that someone new to the CNC hobby can get an idea on how the stuff is added and configured in the environment. I thought, erroneously, that I could show them how to identify an input pin, detect it's level, and bring either a 5V or 0V line out to make the switch. Attach these lines to a clip (for the tool) and a plate.

I didn't take into any account for noise, and you never know how people will wire stuff. So I need a way to help bulletproof it.

Then in MDI, demonstrate the touchoff process for the G-Code before moving on to PyVCP and Classic Ladder. I see that I need to rethink my hardware tutorial portion.

Thanks for the help Andy, and to you ArcEye.

Although, I am not sure what you mean by screening.

A wire which passes inside an outer screen which can be grounded. One end only (control box end usually as that will have a grounded back plane) or you can set up a loop worse than the original problem.

ArcEye wrote:
My favorite, use a 12v plus low wattage plugin PSU to power the probe line and have this activate a SSR which switches a 5v / 3.3v feed to the BOB.
I have used this a few times, especially with limits, the switches are completely noise immune and the SSRs make and break so rapidly there is no lag.

regards

Is this to keep your signal wires as short as possible?

Obliquely yes, it is to do with TTL logic mostly.

A 3.3v signal, which is what most parports are now, only has to drop to 2v or rise from 0v to 0.8v and it is in a nebulous range which could be HIGH or LOW.
It does not take much in the way of induced voltages to throw false signals especially in long cable runs.

Having a 24v signal and converting to TTL would bring up the levels to 11v and 4v respectively, which is pretty noise immune

An alternative to save the 24v>TTL conversion, is having the 12 - 24v signal actuate a relay and the 3.3v signal is passed through the contacts only when they are closed and triggers the actual signal (inverted if needs be)
Because this takes place inside the control cabinet typically, the short run need to bring in the signal to the BOB is pretty well shielded

Is there a supplier of specific brand or type SSR that you recommend?

The ones I used were Omron, but only because I had them in my bits box of stuff stripped from other machines.

regards

andypugh wrote:

What pull-up resistor did you use? You might want to use a surprisingly small one. 50 ohms is still only 100mA from the 5V PSU. The more current needed the lower the chance of false tripping.

The breakout board has 4.7K pull up resistors on it. Would it be safe to run an external pull up resistor resistor with the BOB, assuming I took into account the 4.7K in parallel with it?

I seems I have more work to do before I release that part of the tutorial. It is better that I run into these problems now and resolve them then pass the information on than to jump the gun and create headaches for people. I agree, the tutorial should cover things like noise immunity, grounding and proper shielding. And once I have figured out the debounce component, I will share that too.

Thanks Andy,

Joe