Architecture LinuxCNC-block-diagram - update

[zz912]

I tried to update the block diagram of the LinuxCNC architecture. I would like the image to include both the ideal state and the current unwanted state that has arisen.

I am currently observing that some problems are being solved at the frontend level, instead of being solved at the background level.

When I started with LinuxCNC, I was missing a display where the HAL is. So I drew it.

If anyone knows how other parts of LCNC should work that would be good to draw. Feel free to send them to me drawn with a pencil on paper and photographed with a mobile phone. I can then draw them in the image.

I will be happy if there is a discussion about my proposal.

[andypugh]

I am surprised to see spindles in EMCIO. I am pretty sure those are in EMCMOT.
In 2,9 there is src/emc/iotask/iocontrol.cc but that is gone in master (and doesn't do very much at all in 2.9)
764655e

So the whole EMCIO block is probably not there any more.

[zz912]

I am interested only aboat 2.10 version. I made quick modification:

If I understand correctly, here are the HAL pins of the TASK:

linuxcnc/src/emc/task/taskclass.cc

Lines 46 to 70 in 764655e

	struct iocontrol_str {
	hal_bit_t *user_enable_out; /* output, TRUE when EMC wants stop */
	hal_bit_t *emc_enable_in; /* input, TRUE on any external stop */
	hal_bit_t *user_request_enable; /* output, used to reset ENABLE latch */
	hal_bit_t *coolant_mist; /* coolant mist output pin */
	hal_bit_t *coolant_flood; /* coolant flood output pin */
	hal_bit_t *lube; /* lube output pin */
	hal_bit_t *lube_level; /* lube level input pin */
	// the following pins are needed for toolchanging
	//tool-prepare
	hal_bit_t *tool_prepare; /* output, pin that notifies HAL it needs to prepare a tool */
	hal_s32_t *tool_prep_pocket;/* output, pin that holds the pocketno for the tool table entry matching the tool to be prepared,
	only valid when tool-prepare=TRUE */
	hal_s32_t *tool_from_pocket;/* output, pin indicating pocket current load tool retrieved from*/
	hal_s32_t *tool_prep_index; /* output, pin for internal index (idx) of prepped tool above */
	hal_s32_t *tool_prep_number;/* output, pin that holds the tool number to be prepared, only valid when tool-prepare=TRUE */
	hal_s32_t *tool_number; /* output, pin that holds the tool number currently in the spindle */
	hal_bit_t *tool_prepared; /* input, pin that notifies that the tool has been prepared */
	//tool-change
	hal_bit_t *tool_change; /* output, notifies a tool-change should happen (emc should be in the tool-change position) */
	hal_bit_t *tool_changed; /* input, notifies tool has been changed */
	// note: spindle control has been moved to motion
	} * iocontrol_data; //pointer to the HAL-struct

[andypugh]

Yes, though the lube pins don't exist any more. (They didn't have any useful behaviour)

The tool-change pins are missing from the diagram. (change / changed and number for both tools and pockets). They always have been despite being the main point of emcio.

[zz912]

@c-morley disagrees with me that HALUI should not be associated with GUI

#3580 (comment)

HAL and NML are for two different uses and are not really interchangeable. NML and ZMQ are similar and could be interchanged.

So yes if NML was easier to use, I might have used it instead of ZMQ for this pr.

The reasons for having the GUI communicate to HALUI:

• It's the defacto standard way to connect HAL to a control panel.
• it does not preclude using sinething else, where as if you put it in task you are quite stuck with what we decide.
• it's small/simple enough I can see it through
• it should not break configuration that use the current way, at least for now.
• there is information that task/motion don't know, such as jog rate. Currently if you use HALUI and a GUI then there are two jog rates.

I understand the functional reasons, but I would be interested in others' opinions from the perspective of preserving the architecture.

[rmu75]

If we are going to replace this diagram I suggest to

• make it more correct than the current version and
• use a diagram generation tool like graphviz or mermaid or something the current documentation generation pipeline understands already (ar there any? can somebody in the know comment?) maybe draw.io?
• check in sources of diagram and svg / png formats

[c-morley]

HALUI should not really be in this view.
HALUI and the GUI act the same in this overview.