Unify the way MDI commands are executed from HAL / GUI

[zz912]

Background

There are currently several ways to start an MDI command in LinuxCNC. This can lead to different behavior depending on how the command was triggered and how the particular GUI handles the resulting mode changes.

I originally opened PR #3441 to address a specific problem in Gmoccapy. When a halui MDI command is executed, LinuxCNC temporarily switches to MDI mode and then returns to the previous mode:

Original mode → MDI → Original mode

For short commands, this can happen so quickly that the GUI may only briefly switch to the MDI page. In Gmoccapy, I have also seen cases where the rapid sequence of mode changes can result in GUI elements remaining disabled when they should not be.

I don't think that making this screen change less visible, or simply preventing the GUI from switching pages, is the right long-term solution.

One mechanism for MDI commands

I would prefer LinuxCNC to have one common mechanism for creating/executing MDI commands, rather than maintaining several parallel mechanisms with different behavior.

This was already discussed in PR #3580. I wrote:

"I would like to have only one way to create macros."

HansU replied:

"Agree."

PR #3580 then explored using communication between HALUI and the GUI, with the GUI being responsible for executing the INI-defined MDI command. The idea was interesting because it also allows the GUI to decide how it should react to the command, instead of reacting afterwards to mode changes initiated elsewhere.

The particular implementation of #3580 was later reverted, so I don't want to prescribe that implementation here. The architectural question, however, still seems relevant to me.

What I would like to achieve

I would like to see a common way of handling MDI commands which:

• provides the same basic behavior for all GUIs;
• avoids unnecessary Original → MDI → Original GUI page switching;
• gives the GUI enough information to provide an appropriate indication that an MDI command is running;
• provides a consistent way to abort a running command;

The exact implementation should be decided separately. This issue is intentionally not proposing a specific implementation.

Why I am closing PR #3441

PR #3441 addresses a real problem, but I no longer think that its Gmoccapy-specific implementation should be merged as the final solution.

The problem is more general than Gmoccapy, and I think it would be better to solve it at the appropriate level so that all GUIs can benefit from the same behavior.

For that reason, I am closing #3441 in favor of this issue rather than continuing to modify Gmoccapy around the current MDI mechanism.

Current situation

I also think it makes sense to wait before implementing another solution here.

Chris has been working on the HALUI ↔ GUI communication using ZMQ. I don't understand the ZMQ implementation well enough to judge what the final architecture should look like, and I don't want to introduce another solution in parallel while that work is still evolving.

My preference is therefore to keep this issue as a record of the problem and the desired direction, and first see where the work on the HALUI/GUI communication leads.

Once that direction is clear, this issue can be revisited and the appropriate solution can be implemented at a level that is useful for all GUIs, rather than adding another Gmoccapy-specific workaround.

[gmoccapy]

@zz912

if I understand the problem correctly, the "race condition" is caused only if the MDI command is executed from Halui commands.

That is why I am asking myself, should an MDI command be handled through halui, or is an MDI command in the responsibility of the GUI?

IMHO halui is not the correct way to handle halui commands. A lot of problems we solved on gmoccapy was caused by mixing Halui stuff and GUI related parts.

I would suggest a way, where a GUI does get an information if an halui MDI command should be run, as this way the GUI may avoid mode switches

I am open for more discussion.

[zz912]

I think that, technically, it should be possible to make several different architectures work reliably and without bugs. However, I don't want to get involved in the discussion about which architecture would be better for us. I have done that in the past, and in the end I think I only added confusion to the discussion.

So I can discuss LinuxCNC only from the perspective of a tester, user, and integrator. Personally, I don't want to advocate either HALUI MDI commands or GUI MDI commands.

What I would like to advocate for, though, is that there should not be two different ways of doing the same thing, each with different behavior or different problems. I think we should look for a solution that is consistent and reliable from the user's point of view, regardless of which architecture is used internally.

Are you familiar with Chris's work with ZMQ? #3580 If I understand it correctly, he has actually created a third approach: halui.gui.mdi-command.

Here, I have proposed a new type of macro from the perspective of the user and the integrator:
#3580 (comment)
What do you think about it?

[rene-dev]

In my opinion this should clearly be a part of task(Im moving halui into task) - running a mdi command is also useful if you dont have a gui at all.
of course the UI needs to be aware of it, but what exactly does it need to know? just a signal when a command from hal is run?
I addressed the mode problem in a branch where I made tasks mode readonly - it can figure it out on its own.
setting the mode is completely removed in this branch. https://github.com/rene-dev/linuxcnc/tree/task-modeless
Its not ready yet, the UIs need fixing. currently only axis works, the others are confused by the readonly mode, as switching the tab doesnt emit the mode changed signal.

[c-morley]

So HALUI has MDI commands for when you might not have a GUI. But because it was easy for users to use it was used when there was a GUI in the mix. That does not work well as we agree.

So you should not get rid of the HALUI mdi command, you just shouldn't use it when using a GUI.

If using a GUI, the GUI must be the one to run the command for several reasons.
Only the GUI knows what is appropriate to do first. Does it deny the command because the mode is not right or does it put a message up first? Does it set a blinking LED on the button to show what command is running. Does it first need to ask the user for input?
All these things are currently done in different GUIs.
If we put all those choices in task then we are also stuck programming in C++ to change anything.
TaskUI pins should just message the GUI that a command was requested.

My HALIU ZMQ code allowed three different ways, only to support the popular ways till we agreed on a single process.

[zz912]

I understand why you want to keep the HALUI MDI command, and I appreciate the work you've put into it. However, I'm not convinced that telling users not to use it when a GUI is present is the right long-term solution. I'd prefer to avoid duplicated functionality and have a single, consistent mechanism for both use cases. I realize that removing the existing command would be a significant change, so I'm not suggesting we do it without carefully considering the alternatives.

[c-morley]

@zz912 What the most amount of MDI commands you have added to a system?
My only complaint of your MDI proposal is it is a lot of text to add if there are a lot of commands but it definitely is clear. I would want the separately run commands separated by a colon included.

[zz912]

My requirements come from my experience integrating a carousel-type ATC. So this is not just about trying to make LinuxCNC perfect — these are real-world requirements that many machine integrators will face.

My complete M6 sequence consists of three commands:

• Move the spindle to the ATC position.
• Rotate the carousel to the requested tool position.
• Move the spindle away from the ATC position.

For the operator, I provide physical buttons for:

• Moving the spindle to the ATC position.
• Rotating the carousel to the next position (current position + 1).
• Rotating the carousel to the previous position (current position - 1).
• Moving the spindle away from the ATC position.

I don't use this approach myself, but a friend does, and many CNC machine manufacturers use a similar concept: dedicated physical buttons on the control panel for M6 T1, M6 T2, M6 T3, M6 T4, M6 T5, M6 T..., etc.

There is also a difference between the developer's perspective and the machine operator's perspective.

From an LCNC developer's or integrator's point of view, it makes perfect sense to treat M6 as an MDI command and place it on the MDI GUI page. However, from the operator's point of view, a tool change is simply another machine operation that should be available directly on the MANUAL page.

Operators expect this because this is how commercial CNC controls such as Siemens and Heidenhain typically present these functions: as part of the machine's normal operation, rather than something the operator needs to execute through the MDI interface.

If we add M6 commands to the MANUAL GUI page, we also run into the problem of automatically switching between MANUAL mode, MDI mode to execute the commands, and then back to MANUAL mode.

Professional CNC machine builders typically define the machine's control interface and operating concept at the beginning of the project, and then keep it largely unchanged throughout development. As a hobbyist, I started with a virtual control panel and gradually moved some functions to physical buttons. That's why I needed to use HALUI commands from the beginning — they allowed me to move functionality from virtual buttons to physical ones without changing the underlying control logic.

Unfortunately, Gmoccapy's macros cannot be triggered via HAL pins, which makes them unsuitable for my use case. That's a pity, because otherwise they could be a useful solution.

So, to answer Chris's question about the maximum number of MDI commands: a lot. And that's just for the ATC functionality alone — I'm not even counting the MDI commands needed for the machine's other functions.

Regarding the semicolon suggestion, I think it's a bit premature to discuss syntax details at this stage. We haven't agreed on a solution yet, and I believe we should focus on reaching a consensus on the requirements and desired behavior first, rather than jumping straight into technical implementation details.

Once we agree on the approach, we should document that agreement in the LinuxCNC GUI Developer Reference, so that the requirements and design decisions are clearly documented and can guide the implementation.

[grandixximo]

How does the UI know the MDI command is finished? Does it need to know?

[zz912]

Yes, the GUI needs to know when an MDI command has finished, especially in Gmoccapy.

The problem occurs when an MDI command is triggered while the machine is in MANUAL mode. LinuxCNC switches to MDI mode to execute the command and then switches back to MANUAL mode. This rapid MANUAL → MDI → MANUAL transition can cause GUI issues, such as controls remaining disabled when they should be enabled again.

Knowing when the command has finished would allow the GUI to handle the command lifecycle correctly and restore its controls to the appropriate state.

[rene-dev]

I have to agree with zz19 here, there should be one way of doing it, that works.

mode switching

all the problems with mode switching are gone in my branch - mode is readonly, and cannot be changed.
this addresses the majority of problems.

running mdi from HAL pin

this should be a buildin feature of task, that always works with any UI, or even without any UI present.
it should only be used when there is no involvement of the UI required/wanted.
when you do this, the UI sees that the mode changes from manual to MDI, and back when the command is done.
It can react to it, but it doesn't have to. It cant do much about it, other than display it, abort it, or queue another command.

running mdi from the UI

I dont know why hal/halui needs to be involved here at all? you can just run the command, show messages, check things, and do whatever you want. its one line of code. just run the command.

Configuration

It probably makes sense to unify the configuration.
have a list of macros, configure if a hal pin should exist, or a UI macro button, and extra code in case its a macro.
maybe a setting if queuing is blocked for this command? may make sense for hal pins.
should the command be added to the mdi history?

[zz912]

Hello Rene,

I’ve already started working on a configuration proposal for shared MDI commands here: #3580 (comment)

I approached it purely from the perspective of a LinuxCNC integrator, not a LinuxCNC developer.

What do you think about this approach?

[rene-dev]

nice, I have not seen that! this is exactly what I talked about, one way of defining the macros, and multiple ways of running them, depending on what you need.