Blockview / nomenclature / components / drinking from a fire-hose..

I found this linuxcnc.org/docs/html/code/LinuxCNC-block-diagram-small.png

Helped some - but I'm trying to understand where and what the different components inter-connect.

Part of what confused me, is I assumed that all the components were loaded from lines in the hal file -- but my little breakthrough for today is some components are created out of the ini file...

I think - guessing - that inihal is a hal-component generated from the miltask section in the ini file and creates hal-pins that start with "ini." ??

The other two components I am puzzling on are halui and iocontrol

I can see the pins that they create - but I'm trying to locate where they function in the block-diagram.

From the name, halui probably is created for GUIs to interface to? - so for example it connects axis with some part of linuxcnc? Mixed into this is a software layer - NML - that I think transmits statuses between different tasks ?? but is NML just for halui or is involved with all pin and signal communication?

The other component - iocontrol - I think creates connections to non realtime io parts? (Tool changing,lube, coolant )..

For instance - I see the following pins on my system:

10 bit OUT TRUE halui.lube.is-on
10 bit IN FALSE halui.lube.off
10 bit IN FALSE halui.lube.on
4 bit OUT TRUE iocontrol.0.lube
4 bit IN FALSE iocontrol.0.lube_level

If I connect lube information to these pins - what would it do? Where does this information go?

If someone can correct my guesses - or tell me if I got anything right - I think I can create a block diagram that might help people

PS question: software likes to startup as a tree - one program starts another - PID numbers tend to go up - but can be misleading:
The order I see:
linuxcnc -> linuxcncsvr -> io -> halui -> trivkins -> python -> axis -> milltask -> gladevcp

Likely more like a tree -

The docs page that diagram comes from might help.
linuxcnc.org/docs/devel/html/code/code-notes.html
It would be nice if these docs can be expanded to keep the promises made on that page.
Its a long journey.

Yes - I've read that page -- it is important to realize that the people programming are not always the best ones to provide the documentation. I'm slowly getting a birds-eye view of the system..

So more digging -- I'm fairly sure that NML is a 30-year-old system of buffers that is used for inter PID communications via shared memory. (old but working - people generally undervalue working code (rewriting bits always takes longer - best to first come up with an interface between the old system to modern abstraction methods so old stuff can be picked out one function at a time))..

Anyway - the main linuxcnc program is a BASH scrip that starts linuxcncsvr - which :

# linuxcncsvr now holds/creates all the NML channels,
# so it needs to start by default, as the first process

So I resorted to grepping the code - looks like there was work for controlling lube via MDI - and various GUI extensions..

The halui.lube parts I think were for the XHC−WHB04B−6 pendant..

The iocontrol.0.lube pins I think have to do with gcode?

,.,
I think halui and iocontrol are sort of the same thing? Could be some duplicated effort?

halui Observe HAL pins and command LinuxCNC through NML.
iocontrol Accepts NML I/O commands, interacts with HAL in userspace.

I was able to set pins with halcmd to see what happened - nothing with the halui signals ..

Non of this matters much for lube - but I have the same confusion with estop .. both iocontrol and halui..

Looking at some example hal - I think iocontrol likely came before halui - and is where meshing a physical estop should happen..

www.nist.gov/publications/neutral-messag...geneous-environments

There is a link at the bottom to the NIST paper

I think lube maybe able to be controlled via custom M codes.

In the Linuxcnc GCode docs I couldn't see any specific G or M codes for lube.

For the lube this is my of thinking based on the docs.
Quoting from the docs:
iocontrol − accepts NML I/O commands, interacts with HAL in userspace
halui − observe HAL pins and command LinuxCNC through NML

halui.lube.is−on bit out pin for lube is on - I would imagine this is for user status via nml from controller
halui.lube.off bit in pin for stopping lube - I would imagine this is for user input via nml to controller
halui.lube.on bit in pin for starting lube - I would imagine this is for user input via nml to controller

iocontrol.0.lube - (Bit, Out) TRUE when lube is requested. This pin gets driven True when the controller comes out of E-stop, and when the "Lube On" command gets sent to the controller. It gets driven False when the controller goes into E-stop, and when the "Lube Off" command gets sent to the controller. - I would image this is the pin that controller controls the "outside world" with.

iocontrol.0.lube_level - (Bit, In) Should be driven FALSE when lubrication tank is empty. - I would imagine this is a signal from the "outside world" to the controller. I haven't had a look if there is internal logic that prevents the controller from switching the lube on if this pin is FALSE.

And if anyone with more knowledge sees this could you be kind enough to point out where I got it right and where I got it wrong. Sometimes my interpretation can be off and yes English is my only language.

halui = hal user interface so you use that to interface with a physical control panel.
iocontrol manages the machine start/stop/estop etc

from the docs:
halui is used to build a User Interface using hardware knobs and switches. It exports a big number of pins, and acts accordingly when these change.
ref; linuxcnc.org/docs/devel/html/man/man1/halui.1.html

Just to muddy the water, there are two io modules that can be loaded from the ini file. io and iov2
A user could write their own.
there is also a user definable task module but so far only one has ever been written. milltask
Its been suggested a couple of times that a plasma machine might benefit from a custom task module (plasmatask?)
So a different task module might require a different io module (its a different class of machine so it might have different io requirements right?)

I did play with his once. I created a copy of the /sec/emc/task folder to src/emc/plasmatask and modified the make files to compile it.
It only took about 30 min to do this and then I could load my plasmatask task module.

But I think plasmac.comp works around the limitations of milltask so effectively, there is little to be gained from moving code from plasmac.comp to plasmatask.