Probing improvements

[aldenhart]

This issue is opened to document some changes to improve the probing functions. This issue is related to issue #232

• First off, need to get rid of the hard-wired probing input (current set to whatever input is used for Z homing) and be able to select the probe input using digital input function assignment: for example {difn5:4} to assign digital input 5 as the probing input (function = 4)

• Second - fix probing to work in coordinate system offsets (as it used to)

[aldenhart]

The branch dev-237-probing-improvements is available for test. This branch is submitted as PR #240

[hurr1k4ne]

Fantastic and a quick job again! Thank you guys.
I will have time at the weekend to give it a brief test. Will post results.

[hurr1k4ne]

i did some tests the last days.

I do have problems with the probe pin changing logic or being always "true" after some quick toggles.
I tried different physical setups with the probe wiring. i use RG174 coax-cable added a ferrite ring and added a 4.7k pull up. Also tried adding 100nf capacitor.

testing:
-recompiled edge with merged branch 237 and 209b
-setup: di5fn:4 ; di5mo:0
-touchplate is open (oszi=3.2v)
-{in5:n} --> {"r":{"in5":false},"f":[1,0,9]}
-closing touchplate (oszi=0v)
-{in5:n} -- > {"r":{"in5":true},"f":[1,0,9]}
-touchplate toggeling and sending {in5:n}

and after some tries in5 gets always true but oszi is toggeling 0v <> 3.2v
but when i physically toggle touchplate i can see {"sr":{"stat":3}} appearing in console.

probing fails with {"er":{"fb":100.19,"st":254,"msg":"Probe is already tripped - probe error"}}

Any clues if my physical setup is incorrect?

[hurr1k4ne]

another test, i got {in5:n} always reporting true.

then i disconnected the touchplate and connected a bare wire between pin and GND. But {in5:n} is still "true"

then bare wire to pin and 3.3v switches to false, changing to GND, false again...

[aldenhart]

Can you try running the in5 test again, only from a reset? It could be a few different things that would be good to isolate:

• Hardware fault. Test other inputs
• Configuration error. is the polarity set correctly in the di5mo setting?
• Random state error after running some code. Did the input read correctly before probing, then stick on TRUE after it was used a few times - like in your tests? Is this reproducible?

If you can eliminate 1 and 2 then 3 is the likely culprit.

[hurr1k4ne]

Sorry for the long delay,
a quick update from me.

I disassembled my whole cnc setup because i got huge problems calibrating the motors (bad running, lost steps, squeeking, no torque...) after a lot of days i now definitively hunted it down to the Arduino DUE as signal source.
Will try to check step signal with oscilloscope this weekend.
Setup worked great with an Omron PLC as signal source...

Maybe my problems with probing do get influenced by this.

Will then come back with my result in Probing

[hurr1k4ne]

Hey alden,

i reassembled my CNC now.

1. i use a brand new genuine Arduino Due
   • same behaviour, shutdown after some probing
   • tried different input also
2. di5mo is 0 So NC

 {di5:N}
 {"r":{"di5":{"mo":0,"ac":0,"fn":4}},"f":[1,0,9]}

3. after shutdown input is still TRUE, with physically open.

-shutdown
-probe open
-{clr:n}
{in5:n} = {"r":{"in5":true},"f":[1,0,9]}
-probe close
-{in5:n} = {"r":{"in5":true},"f":[1,0,9]}
-probe open
-{in5:n} = {"r":{"in5":false},"f":[1,0,9]}

this is reproducable
it seems a very short pulse (barely grazing bare probing wires) seems to provoke the shutdown.

probe setup is RG174 coax wire with gnd on shield. and 4.7k pull-up near input pin on arduino.

[hurr1k4ne]

g2core is 100.21 merged with 237-probing-improvements

git log:
commit 2ea8daaad77b41badb0827fc7cf7dc34b68f4072
Merge: 8df3aea 6c5359a
Author: hurr1k4ne <[email protected]>
Date:   Fri Feb 24 19:15:03 2017 +0100

    Merge remote-tracking branch 'remotes/origin/dev-237-probing-improvements' into MillBox

commit 8df3aeada66345b78315ec3986c3c5754bdffb06
Author: Rob Giseburt <[email protected]>
Date:   Thu Feb 23 10:50:11 2017 -0600

    100.21  // Merged dev-209b-random-pauses to compelte USB changes (only fix travis-ci from 100.20)

commit 106c05a49bc44193f685ba355bd09264a6c675ff
Author: Rob Giseburt <[email protected]>
Date:   Thu Feb 23 10:43:13 2017 -0600

    Working on #245 - Getting Travis working again (#246)
    
    Making Travis work again (32bit linux binary issue)

[Funkenjaeger]

I'm running 100.26 built from edge today; this is the first time I've gotten g2core running. I am experiencing what sounds like the same or similar probing issue.

I have added a 4.7k pullup and 0.22uF cap to the probe input pin, which may or may not have helped a bit.

I did some further experimentation, and these are the symptoms I'm seeing - I think this is generally consistent with what others have experienced but maybe the details could help isolate the specific issue:

1. the state of the probe input (di5) gets stuck to 'true' after a probe cycle about 1 in 5 tries or so. Once it is stuck, it remains that way until I tap the touch plate to the probe momentarily (yielding a couple of {"sr":{"stat":3}}) after which it will go back to reading 'false' when open-circuited as it should.
2. currently it's not actually going into shutdown during the probe cycle that causes the input to get stuck- but rather once it is stuck, if I try to probe again it goes immediately into shutdown. If, however, I notice that the input is stuck and 'un-stick' it as mentioned above, I can run another probe cycle successfully.

[mnesarco]

Hi Folks,
I am using edge 101.03, compiled from github edge (2019-10-26) and I still have this issue: After the first probe cycle, in5 gets stuck to true, if i tap the probe a few times it finally goes back to false.

Any known workaround?

PLATFORM= DUE
BOARD=gShield

Thanks in advance.

[bartona]

I am experiencing this issue as well on a v9 board

[willmackey2nd]

Too bad this never got solved. I'm experiencing it too. Did pretty much same tests as @hurr1k4ne . Running 101.03 on DUE.

[giseburt]

This should be fixed in edge-preview. The probing subsystem has be revamped, and gpio has been reworked as well since edge.

For example, the new action system only doesn't act during the lockout, and edge detection is suspended: https://github.com/synthetos/g2/blob/edge-preview/g2core/gpio.h#L494

But polling of the value still directly consults the pin, so a pin in a status report will always be accurate: https://github.com/synthetos/g2/blob/edge-preview/g2core/gpio.h#L423

I have found a few extreme cases, such as if you test a probe by bouncing a grounded wrench gently against the side of the tool, you'll get an extreme bounce situation that wasn't handled well in edge but is now. That applies to probing and homing.

Another case that's handled now but wasn't before is when probing very slow and to a rigid material it is possible to disconnect the circuit in the 1-2 step back off and before the probe is tested. That's handled now by storing the probe state and not polling again. This makes it more sensitive to glitches, but prevents missed polling. IOW, if it fails, it'll fail thinking it hit not assuming it didn't.

Again, this is all in edge-preview. We're working and getting that pushed to edge, but I don't have a timeline yet.

-Rob

[willmackey2nd]

Thanks! I actually noticed the newer discussion about this issue just after posting this. I've used a modified shapeoko2 settings for my DUE until this but preview edge-branch doesn't compile with it (compiles ok with default) so I need to redo my setting file to verify if this got fixed on my setup too. Looks good based on the other thread.

I noticed the bug in normal plain PCB probing, using a 3mm screw as a test probe, so not an extreme case in my case.
The issue in edge branch seems very clear, it just ignores everything during lockout. Preview seems to have a major overhaul in gpio.cpp and didn't go though it in detail, but based on your comment it now has some sort of buffering for the state change. Didn't quite get tho what sort of glitches it could be more prone to now? If the first hit state is saved, it should be ok if it also reports that forward?

[giseburt]

The handler is passed the value that triggered it along with the edge it detected: https://github.com/synthetos/g2/blob/edge-preview/g2core/gpio.h#L520

The probe cycle checks the pin before the move, and then accepts that any change would be the one it's looking for after that. It was also changed to decode that it saw the pin change ignoring the actual pin state in the case of excessive bouncing: https://github.com/synthetos/g2/blob/edge-preview/g2core/cycle_probing.cpp#L137

Between those two probing should be very robust, and in case of a bounce failure it should always fail to stopping not fail to ignoring a glitch.

[willmackey2nd]

Thanks for the explanation! Took June 22 commit based on the discussion on the other thread as the head didn't compile. This didn't work for me tho. I think it's better to continue in #470 as it has more recent info on this in general.