I have finally rewired all limit switches with shielded cable and NC configuration and

Controllers g2core and TinyG
1

I have finally rewired all limit switches with shielded cable and NC configuration and connected to the gShield/ArduinoDue running TinyG2 on Chilipeppr. When I test a motion by manually typing g-code (G91) motors randomly go on Hold in the middle of a movement. Resume from hold (~) completes programmed movement, but for long distances few clicks on ~ are needed.
Another issue is homing, which doesn’t work as expected. Homing any axis move the machine axis back and forth few millimeters and consider axis as homed, but this is in no relation to homing switches. Actually setting machine to a middle table location will home it there.
I tried 0.78, 0.87 and 0.89 firmware, none of them working ok.

Disconnecting switches from the gShield board helps getting rid of Hold issue, but I need limit switches at least for homing.

Does anyone use the gShield and ArduinoDue as TinyG2 and have it properly configured? It seems to me extremely unstable platform.

2

I see $fb=78.03 for Due + Gshield at http://synthetos.github.io/g2/.
Are you building 87.xy and 89.yz yourself?

A “misfire” (noise) on limit/homing switches would cause an non-recoverable hard stop, not a pause, so something else is amiss.

Can you dump your setup parameters ($$) to a cloud drive for a look?

3

I used the 078-edge and 087-edge firmware available via Chilipeppr Programmer and a manually compiled 89.02 (source downloaded from github).
I wonder if ArduinoDue pull-up resistors are enabled. But anyway those are 100k giving rather weak pull-up.

Is there an option in the code to make sure internal pull-up resistors are disabled, so I could use external pull-ups of ~1k and eventually a low pass RC filter?

Although I would strongly prefer using tinyg workspace, I also tried the same gShield board connected to Arduino Uno running grbl 0.9j compiled with NC switches support (default is NO) and got false alarms triggered immediately after initiating motors movement until I enabled software debouncing and compiled grbl code again. Not yet tested with spindle, which may start another chapter.

4

@sszafran What sort of switches are you using(e.g. micro switches, hall effect, inductive, etc.)?

I am not all that familiar with DUE (or UNO) pull ups, would assume they are enabled.
I don’t see why one could not parallel the internal 100K with an external resistor as well - but admit I have not researched the topic.
I can observe that a development prototype tinyGV9, which is a tinyGV8 like PCB with DUE clas micro-controller has on PCB pull ups of 2.7K to 3.3VCC rail and 0.47uf to ground for each port pin. You might try that on the ports you need for homing and just enable those switches…
With only 100K pullup, any capacitance on the port would translate to a slow ramp up from gnd if a switch activated, such a slow ramp could result in oscillation of the detected state. But I am still wondering why the state would be changing mid-travel.

5

I added a stronger pull-up resistors 0.47k plus RC filter (1k resistor + 100nF tantal capacitor) for each limit pin on the Arduino Due. No single false positive so far.

6

@sszafran Great news. Did you pick those values based on a Uno/DUE recommendation somewhere, or perhaps because that is what you had in the drawer?