Gmoccapy-integration halui MDI commands

[zz912]

When the "halui MDI command" is run, the modes are switched in the background:

1. Original (Manual or MDI or Auto)
2. MDI
3. Original (Manual or MDI or Auto)

This Pull Request ensures that the mode screens in the Gmoccapy GUI are not switched.

[Sigma1912]

Maybe @hansu could review this.

[gmoccapy]

This patch does the MDI Running Check in the button press functions, IMHO the check should be done in Hal Status change function instead.

On the other Hand I do not like that the code is introduced on several places, so we have the same code on several places instead of having it in its own function.

Norbert

[zz912]

This patch does the MDI Running Check in the button press functions, IMHO the check should be done in Hal Status change function instead.

This patch has three parts:

1. in init it detects if LCNC configuration contains HALUI MDI commands
   line 216
2. blocks mode buttons during run HALUI MDI commands
   line 2534 - 2558
   It is debatable whether this part is important. Theoretically this situation should not occur, because during run commands these buttons are no sensitive. However I have problems with real implementation of LCNC, when during use of remap and HALUI commands I have random horrible things happening and therefore here are logs that could help in finding problems.
3. react to Hal Status change and block screen change
   line 2804 - 2888
   This is the main part of this patch.

On the other Hand I do not like that the code is introduced on several places, so we have the same code on several places instead of having it in its own function.

I also thought about enclosing part of the code in a function.

But does it make sense to make a function for 3 lines?

    if self.halui_cmd_exist:
        if hal.get_value("halui.halui-mdi-is-running"):
            MESSAGE
            return

The problem is that the MESSAGE is different every time.
Moreover, in part 2 I use LOG.error
in part 3 I use LOG.debug

I don't know how to do it so that it doesn't make it even worse for clarity.

Or do you want to move the code in the init part into the function?
To make the init function cleaner?

[zz912]

Is there anything I can do to get this Pull Request merged? Or is it just that no one has gotten to it and I should wait?
I don't want us to wait for each other.

[andypugh]

Is there anything I can do to get this Pull Request merged? Or is it just that no one has gotten to it and I should wait? I don't want us to wait for each other.

I saw that @hansu had self-assigned it, so I have not been paying much attention to it.

[zz912]

Hello Andy,

Thanks for your response. I don't want to put any pressure on Hans.
I just wanted to make sure that there was no need to do anything on my part.

I didn't want a situation where I would be waiting for Hans and Hans would be waiting for me.

Zdeněk

[zz912]

This PR solves the problem with switching modes using a HAL signal. I now know that HAL signals in GUIs are not a very clean solution. On the other hand, I still think that this PR should be merged as a temporary solution to the problem, which will make life more pleasant for users for at least a year, until the switching pages issue is properly resolved.

[hansu]

I have it on my list =)

[hansu]

I wonder why it is a problem when the screen switches to MDI mode while a MDI command is being executed.
This has the advantage that you get an abort button while the MDI command is running...

[zz912]

Short commands are very often used. For example:
MDI_COMMAND = M6 T1
MDI_COMMAND = M61 Q2
MDI_COMMAND = G43
MDI_COMMAND = G49
Mainly in physical panel with physical button.

So you only see a screen flash.
Then there is the problem that it starts very quickly :
def on_hal_status_mode_mdi(self, widget):
and immediately after:
def on_hal_status_mode_manual(self, widget):
Which causes a race condition on some PCs and some parts of the previous functions are not implemented completely. Then some buttons in gmoccapy are grayed out and they shouldn't be. Mainly it behaves unstable.

I admit that I have never needed long HALUI mdi command.

[hansu]

Then some buttons in gmoccapy are grayed out and they shouldn't be.

You mean they stay grayed out then due to the race condition?

But for longer lasting MDI commands we should do something on the screen At least disabling the mode-switch buttons and maybe also display a message like "MDI command is currently executed". Otherwise the user just wonders why the GUI doesn't respond.
Do you thin a pop-up dialog is annoying, which pops up while a halui MDI command is running and then disappears automatically?

[zz912]

You mean they stay grayed out then due to the race condition?

I think Yes. 90%

Do you thin a pop-up dialog is annoying, which pops up while a halui MDI command is running and then disappears automatically?

The message "External MDI command is currently executed" is not suitable for the operator. The CNC machine operator (not integrator) does not know what an "External MDI command" is. Mayby "Machine is currently working."

I would make a 1s delay so that this message does not appear for short commands. Pop-up dialog should be annoying, but with automatically dissapearing it is not a big problem for me.

Before you start working on this PR, please read this #3580 .
Because then this PR might not make sense.
This is especially important:
#3580 (comment)

[hansu]

@zz912 I think for your change it is needed to modify only one position. I modified that change and removed the changes at the other positions.

Further I display an abort button on every page when a halui MDI command is being executed. I think that is a nice and decent indicator that a MDI command is running. If it flashes on short MDI commands that doesn't matter I think.

The button doesn't have a function yet. I want to hear your opinion first before finalizing this.

[zz912]

Hi Hans,

I have kept this PR open only and solely to make sure that this problem is not forgotten. However, I don't think the solution proposed here necessarily has to be the solution we use in the future.

In PR #3580, we already discussed that we don't want to have multiple different ways to create/run macros. I wrote, “I would like to have only one way to create macros.” and you replied, “Agree.”
#3580 (comment)

Chris then proposed the GUI/ZMQ approach, and we left this particular question for later.
#3580 (comment)

Now that #3580 is completed, I think we should first build on this new mechanism and then decide how Gmoccapy should react to an MDI command being started.

Therefore, I would not like to close #3441 with a specific implementation at this point. The problem addressed by this PR is real, but I think its future solution could be completely different from the changes currently proposed here.

For me, it makes sense to first agree on how starting an MDI command from GUI/HALUI should generally work, and then adapt Gmoccapy accordingly.

One more thing from my side: as a tester, I don't understand the ZMQ technology well enough to judge all the implications of the current design. In the past, I therefore sometimes joined the discussions around Chris's work in a way that, in my opinion, brought more confusion than benefit.

So at the moment I am following Chris's work with great respect and admiration, but mostly from the background. I don't feel able to judge whether this is already the right time to reopen the topic of unifying the MDI commands, or how this should technically be done.

At the same time, I have the feeling that Chris is currently working on this area largely on his own. I therefore don't want to come up with additional requirements or suggestions that could make his work even more complicated.

So from my side, I don't think we need to open this topic right now. I just wanted to explain why I would prefer to keep #3441 open, and why I don't want to make any definitive changes to Gmoccapy yet.

[hansu]

Now that #3580 is completed, I think we should first build on this new mechanism and then decide how Gmoccapy should react to an MDI command being started.

#3580 isn't completed - it has been reverted.

So from my side, I don't think we need to open this topic right now. I just wanted to explain why I would prefer to keep #3441 open, and why I don't want to make any definitive changes to Gmoccapy yet.

Then it's probably better to close this and create an issue instead to not waste more time on implementing things you don't want anymore.

[zz912]

Hi Hans,

I created issue #4587 to capture the more general problem and my wish to have a unified way of handling MDI commands.

I agree that, given the current situation, it makes sense to close this PR rather than continue implementing a Gmoccapy-specific solution here.

There is one thing I don't agree with in your proposed solution, though:

“If it flashes on short MDI commands that doesn't matter I think.”

I don't think the flashing is harmless. My concern is not only the visual effect itself. I think that by moving the indication from switching pages to flashing the Abort/message area, we may simply be moving the same timing/race-condition problem to another part of the GUI.

However, I don't think we should solve this in #3441 anymore. The whole mechanism for handling MDI commands may change in the future, and I would rather not spend more time refining a solution based on the current mechanism.

I have therefore created #4587 as a general issue for all GUIs. For now, I think it is better to wait and see how the HALUI/GUI communication develops, including Chris's work with ZMQ, and then decide on the appropriate solution.

So I'm happy to close #3441.