Saving I/o pins at the TinyG controller for further updates

[dampfboot]

To make wiring easier and to save some I/o pins at the TinyG controller I would suggest to chain all end stop switches in one big serial loop.

For my opinion there is no need for the software to know which switch has opened - it just has to stop.
The operator will easily find out which was the one.
Or is this a must in the TinyG software?

Also for calibration it is not necessary to look for a specific switch.

My two DIY mills are working with this principle using the MACH3 software.

Rainer

[JuKu]

Good point. I agree that the controller does not need to know which limit switch triggered and when homing, it knows what axis it is working on, so knowing that a switch triggered should be enough. In other words, a CNC controller should normally need only one switch input. I'll pass this on to TinyG people. (Last sentence sounds funny...)

[mawa]

Wow...
some ideas are so simple but one is blind to see them. A terrific idea!

I haven't looked into the TinyG code but I assume that all limit switch inputs are ORed to achieve a non-probing interrupt halt. And for probing the software knows the axis it is moving.

[WayOutWest]

To make wiring easier and to save some I/o pins at the TinyG controller I would suggest to chain all end stop switches in one big serial loop.

Neat idea! An additional wire could be saved if you used Normally Open (NO) switches wired in parallel. Then each switch connects the common signal-wire to GND (or +3.3V) when tripped. But this might be a bit more noise-sensitive.

My two DIY mills are working with this principle using the MACH3 software.

I'll pass this on to TinyG people. (Last sentence sounds funny...)

TL;DR: TinyG does a lot of stuff because that's how "CNC-land" does it, not because they took the time to think it through.

FWIW, it seems like although the TinyG people are very very smart a lot of what they do revolves around imitating existing products rather than thinking out how things ought to work. For example, my constant irritation that the TinyG demands physical intervention (physically pressing a reset switch) when a limit switch is hit. This is really annoying when you're developing software and limit switches are getting tripped on a regular basis... constantly getting up, walking over to the machine, hitting the button... doing this 100 times a day gets to be really annoying!

Turns out there is no reason why the TinyG can't allow a software-initiated reset from the limit-switch-tripped state. The only reason it does this is that the TinyG developers were imitating other products which did it for safety reasons -- safety reasons which do not necessarily apply to all machines which the TinyG might be controlling! From their webpage:

Currently when a limit switch is hit all bets are off. This is how my machinist friends tell me it's supposed to work.

Personally, if you ask me, "my machinist friends tell me that's how it should be" is not a real justification.

I'm sure there are plenty of professional CNC products where this is true. But the TinyG isn't a single-machine controller, and it's silly of the TinyG developers to force this assumption on all of its applications. Grbl, for example, doesn't force this assumption on its users.

[JuKu]

For example, my constant irritation that the TinyG demands physical intervention (physically pressing a reset switch) when a limit switch is hit. This is really annoying when you're developing software and limit switches are getting tripped on a regular basis... constantly getting up, walking over to the machine, hitting the button... doing this 100 times a day gets to be really annoying!

This is why I have a big red button and long wire, so the reset switch is by my keyboard.

[jarekk]

Personally, if you ask me, "my machinist friends tell me that's how it should be" is not a real justification.

I'm sure there are plenty of professional CNC products where this is true. But the TinyG isn't a single-machine controller, and it's silly of the TinyG developers to force this assumption on all of its applications. Grbl, for example, doesn't force this assumption on its users..

Well, I do manufacture professional CNC controlles for both small and big machines.

While not all have separate inputs for limit switches, most have at least two inputs - all axes for '+' direction and all axes for '-' direction movement.
This allows pretty safe running off the switches - it is rare that you have both directions activated at once as the calibration sequence usually uses only single axis to run on/off the switch.

And a warning - if you have serious machine ( heavy, on ball screws) then you do care that you do not hit anything. Usually it means expensive repair if you hit any limit.
So professional software assumes that hitting limit switches after initial calibration is fatal as it indicates that something went wrong ( You do know your operational area - do not you ? You do not calculate movements outside it)