new Component probefilter to handle "probe tripped ... errors"

More
20 Apr 2021 07:14 #206504 by freisei
Hi!

With current build of 2.9-pre it is very hard to handle bouncing/flickering probes because linuxcnc stops on every . This is the main thing i want to create a realtime hal component "probefilter".

Problem: probing for a rotating endmill on a laser.

possible solution 1, filter for motion.motion-type 5 does not work.
Even if i create a hal-filtered probe (only active when motion.motion-type is 5) there are a couple of signals going through in around 50ms after first probe-signal.

On a G34.2 move with running spindle for some reason i get three pulses from type-5-probe-pin until linuxcnc decides G34.2 is over.
It seems that the task that turns on watching for probe-interrupts is a little faster - so i get "Probe tripped during non-probe move."



Upper graph is probe-signal that only is active when motion.motion-type == 5. The lower one is dirctly from the probe.

possible solution 2, debounce adds latency.
as far as i see the hal components dbounce and debounce both would add latency to the probe-signal. This is very bad for a probe-signal.

Features
  • a number of probe-inputs, each can be individually enabled/disabled
  • filtering/debouncing to match problem 1 without latency
  • motion-types configurable per probe

If some you have any suggestions i will see what i can do.
btw. i'm not a pro in c - so maybe a better programmer would have to cleanup/rewrite the component to match quality-criteria to get into official code-repos.

Please Log in or Create an account to join the conversation.

More
21 Apr 2021 11:10 #206629 by andypugh
Would it be enough to make the motion-type=5 signal longer with a oneshot component?

Please Log in or Create an account to join the conversation.

More
14 Aug 2021 19:47 #217766 by freisei
Hi Andy,

i ve overseen your answer. I´ve already tried it with oneshot. It did not work for me. Because i need a fast reaction when getting into the laser beam and even getting outside. Doing that in complicated hal it resulted in the better way for me to write a small (unfinished) component "probefilter".

github.com/freisei/probefilter/blob/main/probefilter.comp

Greets!
The following user(s) said Thank You: andypugh

Please Log in or Create an account to join the conversation.

More
15 Aug 2021 09:22 #217796 by rodw
When I had this issue I and2'ed the probe signal to a digital output and added m62-m65 to my probe routine so the probe would only trigger if the digital output was true (during probing).

Please Log in or Create an account to join the conversation.

More
16 Aug 2021 23:44 #217931 by andypugh
The comp here seems to use motion.motion-type so automatically detects a probing move with no further G-code magic.

Please Log in or Create an account to join the conversation.

Time to create page: 0.097 seconds
Powered by Kunena Forum