RFC: Re-work handling of coolant / lube / worklight pins

[andypugh]

Prompted by #2471 and #2531 (the former trying to remove pins, the latter to add them)

Both the references above show how much code is needed to control a single HAL pin.
It seems that all IO pins could be switched with a single message, and handled in a standardised way. Still a lot of code, but at least it isn't redundant code.

Furthermore, there will frequently be user requirements for additional pins (through-tool coolant, separate lube pump for each spindle, several worklights, possibly even include a stack-light in this)

Initial proposal:

1. Combine the existing pins in a single message, passing a 32 (or 64)-bit array of values.

Sub-Proposals (for discussion)

A) Alias flood, mist (others?) to M64 / M65 using a P-word > 100 (or, use a different index word). There is currently a limit of 64 for the existing, conventional, digital IO pins, so the higher index number should be safe. A letter code might be better, though. I think that DHIJK are possibilities. D for "Digital" or I for "IO" would both fit (I haven't checked their current type)

B) Allow override of the names flood / mist etc from the INI file, and also allow adding of extra signals the same way

Proposal (B) should include GUI updates to display GUI buttons on-demand in the same way as they currently do for mist/flood etc, but using the names from the INI. HALUI should use these names for HAL pins too.

The pins should probably use NIST logic, so I think that we would also need to extend M66 to read back the status of these pins.

[andypugh]

To elaborate on the motivation for this: The idea is to have a set of HAL pins that are equally easy to manipulate from G-code, HAL and UI code. You can achieve the same thing now using the motion.digital pins, and HAL and toggle-2-nist, mux and other logic. But even then the GUIs don't know about it.

[hansu]

The idea sounds good to have all those in one message. Would that change the pin names?
Flood, mist and lube have their own messages currently, did I get that right?

[c-morley]

I agree it's worth thinking through the idea. I don't see a bad side at the moment.

[grandixximo]

Why not using motion digital output pins? and set an alternative name for display from ini file.
I have found difficulty figuring out the toggle-2-nist logic when there are specific timing delays requirement at abort, and when I'd like to run it outside of a running program, like MDI for testing, maybe I just need look more into it.
But I was also thinking to help with user with similar questions
https://forum.linuxcnc.org/38-general-linuxcnc-questions/43038-motion-digital-output-value-on-stop
It will just make it easier for the user to be able to choose which of the motion pins will go off at abort time, and if the state before abort should be saved by M70, and restored by M72, that could enable convenient resuming of G-codes that use lots of motion digital outputs, just food for thoughts...