Problem: Limit switches trigger on noise and not on TTL 5V to 0V (i think)

[mdzoidberg]

Wiki Search Terms

limit switch triggered shielding pe

Controller Board

XPro V5

Machine Description

xPro V5. 2.2 kW spindle. XYYZ 2.8A. Modified Shapeoko 3

Input Circuits

Three limit switches, XYZ. 3-core shielded wire. Shields are terminated to PE. 3-core to respective V+/GND/SIG.

Configuration file

Working with shielding not connected to PE

Startup Messages

Working with shielding not connected to PE

User Interface Software

CNCjs

What happened?

I went from a Shapeoko 3 to upgrading it to using a CNC xPro v5 Controller. The original firmware didnt work with my VFD Spindle through RS485 so i flashed it to FluidNC.

Grbl has been around for a while, and maybe i am spoiled to just being able to google anything, and i will find some answer in all the great communities. I guess FluidNC is new-er, but either i am the first in the world to have some issues or i am just looking at the wrong place!

I can share my issues with you guys nevertheless, because you are awesome! Here goes:

I just rebuilt my cnc, and wanted to take every precaution i have learned from previous experiences. So i bought shielded cables for both steppers and limit switches. For a day-living, i am working with analysers and should be knowledgeable about how to terminate wires, and how to bring the shielding to PE on only one side, etc etc. That said, i am not an electrician.

Whenever the shielding of one of my limit-switch is connected to PE, it triggers as "active"(?!). If i disconnect the limit switch(es) shielding' from PE, it works as intended. At first i thought i had botched some termination and by connecting the shieldings together to PE i was pulling all the 5V lines for xyz low or something. But no.

When i am scoping the signal, it stays around 4.9V when shielding is floating. If the shielding is connected to PE it is also 4.9V. I do however pick up detect more noise, but still avg. 4.9V. It seems as the noise is detected as the limit switch is active (falling edge detection or something) but it is never below 4.8-4.7V. When the switch is really activated, the signal falls to ~0V. But my controller seems to think that this noise around 5V is the same as 0V.

For now, i have just disconnected the shielding from PE...but i think its strange.

2. I have a powered probe/bitsetter-thing (from Carbide 3D). I have connected V+ to V+, GND to GND and SIG to SIG. It lights up red when its not pushed down, and lights up red and green when its activated. In either case, the probe is detected as active. When i scope the signal, it is somewhere around 4.5V when not pushed down and 3.5V when pushed down. Is the bitsetter made for 24V? Can i do anything in the config? My googling have returned in not so many answers, hence i am hoping for you guys.

GCode File

No response

Other Information

The limit switches are run along with the stepper motors (also shielded). I tried disconnecting all four XYYZ stepper motors. Still problem. The VFD (also shielded) goes in a separate dragchain and is not close to the limit switches. Even if the VFD and Stepper motors are disconnected and not even powered up, the controller picks up the noisy ~4.8V as "triggered" ie low/0V.

Yes - the gnd should have less noise, but this ripple at 4.8V should not be interpreted as low/0V. Seems to me that the falling edge detection in software is too rigid. I would at least ask for a feature to choose a threshold.

Same goes for my probe pin - or maybe i just cant find the setting for it, it has an active hi/lo, but it seems at it is constantly detecting it as high. Where is the setting for >XV then high, else low?! Dont ask me why Carbide designed it this way. All i know is i have a $150 probe switch that FNc refuses to recocgnize high/low - And i know it can!! Am i missing something in the config? Should i add some "advanced" features to the yaml, i dont know.

Searching internet for answers have resulting in zero. Seems like i am just being guided to your discord, so...here's to that. Trying.

Christmas season is soon upon us, so i realize that you guys and girls may be occupied, as i plan to be. Nevertheless, i hate to go to bed with some non-resolved issue

I can send you pictures from my scope if you want, but really, it is just showing: 1: All limit switches' shielding connected to PE: ~5V to SIG. ~0V when switch is actually active.. $? would show P:xyz

2. All limit switches' shielding disconnected (floating): ~5V go SIG, 0V when switch is active. $Limits or $? would show they are all ok
3. If i disconnect all from the common PE (f.ex if i botched the wiring termination and shorted e.g. some 5V to PE), no matter what - if i connect X to PE The X limit switch will be detected as active. Same for Y, Y2 and Z.
4. They are all lounging in the ~4.7-4.99 department. Not even close to 0. Why are they being picked up as 0.0/high?!??!?!?

While connected to PE - there is some additional background noise. I think i will install some filtering for the input later, but normally i dont think you would ever have to filter PE as it is the signal sink for eeeeverything.

[MitchBradley]

This seems like a hardware problem that the XPro guys should help you with, since you presumably paid them for the hardware. The software has no control over the input thresholds. They are determined solely by the ESP32 chip and whatever circuitry is between the connector on the outside of the box and that chip. My impression is that the noise filtering circuitry on XPro is generally of good quality. From what I have seen, it is not just a direct connect from the outside to the ESP32 chip, but rather a thresholding circuit based on a comparator, if memory serves. Regardless, it is not something that us FluidNC software developers have the slightest bit of control over.

[MitchBradley]

The only thing that you can control via the config file is the active state, by adding :low to the pin name, or not. GRBL has an invert bitmask that does the same thing. The hardware thresholds are established by the circuit design, with no software control. To understand exactly why the shield connection to PE is causing noise pickup, it would be necessary to analyze your complete system and how the PE ground is ultimately tied to the signal ground, if at all. Your descriptions of the scope results are not particularly enlightening, since we know nothing about your scope (bandwidth and whatnot), nor where you are referencing its ground to, nor how well it is isolated from the other grounds in the system.

[mdzoidberg]

Scope measurements should perhaps be interpreted as fancy multimeter readings in this case XD The scope is however 200 Mhz, grounded with reference to 0V of the controller.

Regarding the second part of my question - I asked you guys, because i was thinking the pins were more connected to the software. ie something along if (analogRead(22)>512) doStuff;

My probe is 24V, NC, and drops to 12V when probed. The software doesnt recognize any change (i've tried :low/high), i am assuming it needs 0V? Is it possible to change this behaviour? in instrumentation, this is perfectly sound 24/12V signifies an alive probe, whilst 0V would signify a problem

[MitchBradley]

On an XPro, there is a lot of circuitry between the external connectors and the GPIO pins of the ESP32. The XPro people have asked us not to reveal the details of their hardware, so you should definitely ask them, not us.

The analogRead() thing is not what happens. ESP32 has only a few pins that can possibly be used in an analog fashion (i.e. be read through an Analog to Digital Converter or ADC). The ESP32 ADC is not very good and it is quite slow compared to GPIOs directly sensing digital thresholds. FluidNC has no use for it at all. All switch sensing is done with digital GPIOs whose threshold at the microprocessor chip itself is approximately half of the ESP32 supply voltage of 3.3V. Most controllers have some circuitry between the switch connector and the GPIO. The threshold at the outside connector - and indeed the sensing method, which could be voltage, current, or resistance depending on the circuit - depends on that circuitry and is not under software control. You have to look at the hardware design or documentation to understand the characteristics of a given input on a given board. Spark Concepts does not publish their schematics, so in the case of XPro, you have to ask them or find it in their docs.

Most FluidNC hardware is designed around DIY-grade components so people can build low-cost systems. Industrial-grade sensors and controllers like PLCs are a completely different market.

[mdzoidberg]

Fair enough that this seems to be an issue between me and the xPro-controller/Spark Concepts. I will try to contact them, but i think their web "contact us" is not working. At least, they are nowhere to be seen. If you have some contact email, i would be grateful.

That said - did they really tell you to not tell anyone what voltages they expect on the probe inputs?! I have difficulties understanding why something like that would be secret, as it should be part of the documentation! I have no problems rigging my probe to be 0 or 24V or reverse or whatever, but in the industrial world it is kind of frowned upon to build a non-failsafe system like this. You want either 24V or 12V, 0V signifies an error. Or 4-20 mA or whatever.

I can build my probe to NO, NC, 24/12/0V or 5/2,5/0V or whatever. But i need to know how the controller interprets it.

[MitchBradley]

They let me see their schematics and asked that I not reveal them to others without permission. I am not motivated to digest them and make a list of the detailed characteristics of every pin, for the benefit of people who have purchased their hardware. I have other things to do that will further my own goals.