Mks sbase z-probe wont invert

[swashman]

Hello,
I am working on setting up a cnc using a MKS Sbase.
I noticed in testing my limit switches that the probe pin was showing as activated. I changed the $6 to invert it however this has made no change. It appears to be expecting a NC switch either way but I am using a touchplate with 2 wires. When I attempt to run a probe command it fails saying the switch is in the wrong state.
I am using the precompiled bin file. is there a setting somewhere i need to change and compile myself?

[cprezzi]

Limit switches expect an NC switch by default (for protecting from broken wires), but the probe pin should not. The default behaviour with $6=0 should be that the pin is pulled up from the board and the probe trigges when you connect the pin to ground.

[swashman]

So I switched the limits back to the original setting and connected them as NC. However my probe still shows as tripped.
I will try and reflash the firmware and see if it fixes.

[cprezzi]

Are you sure that you use the probe pin for the probe? This pin should not have anything to do with the limit pins and config.

[swashman]

Yes so maybe I got it a little confused at the beginning talking about the limit switches. I tried reflashing and this didn't change anything.

So when I do connect the probe, it does work just
backwards , as if I'm going to do probe away. So I was reading the the probe.c file and was thinking if I just switch the return in probe_get_state this should fix my issue. Would this cause any adverse effects?

[tscofield]

The setup you are describing should work. Trying on my setup ($6=0, probe connected to pin P1.27), here is the status output of an open probe and a closed probe.

Grbl 1.1f ['$' for help]
<Idle|WPos:0.000,0.000,0.000,0.000|FS:0,0|Pn:ZA|WCO:0.000,0.000,0.000,0.000>
<Idle|WPos:0.000,0.000,0.000,0.000|FS:0,0|Pn:PZA|Ov:100,100,100>

[swashman]

I was never able to get it to work normally. I ended up just changing the code to invert what is returned, and it seems to be working just fine.

For some reason changing to $6=1 never did anything at all. Since no one else seems to have the issue, I just chalk it up to some form of board defect that isn't of major issue. Maybe a bad pullup or down, whichever one it is, I can never remember.

[tscofield]

I'm not sure how many people have used this function, so folks other than yourself may have had the same issue. I think I found the problem, I haven't done any testing yet.

Probe.c line 25 should probably be changed to a uint32_t from an 8 bit. I never tested trying to invert it the output with previous testing. Right now the logic is ((PROBE_PIN & PROBE_MASK) ^ probe_invert_mask), with the probe_invert_mask being 8 bit you have a bitwise operation of ((32 bit AND 32 bit) XOR'd with 8 bit). Since we are dealing with the 27th bit, and the xor could only possibly change the first 8, nothing happens.

I can try testing this out, but it might be a few days before I get a chance to re-setup a build environment for this.

[cprezzi]

@tscofield Good catch! This may have been forgotten when porting grbl to LPC. If you have time, please add a pull request after testing. Thanks!