Python command.wait_complete() does not wait for c++ halui commands

I apologize for duplicating the information I provided in the Gmoccapy section.
forum.linuxcnc.org/gmoccapy/49335-self-c...lete?start=10#274170

Unfortunately, no one helped me in this section, so I'm trying to put this information here, because more people come here. The Python Interface section is not here on the forum.

To avoid having to create my own button, I use the coolant button in Gmoccapy. I added this code to it:
Video:
 
The video shows that the LCNC is behaving as it should.
First, the X-axis moves by 10 mm.
The command.wait_complete() waits for the X-axis to finish.
Finally, the Y axis moves by 10 mm.

I added the following to the Gmoccapy.ini file:
Video:
 
You can see in the video that everything works as it should.

The problem is when I run halui mdi-command and immediately after python mdi-command.
Video:
 

In the video you can see that command.wait_complete() does not wait for halui to complete its commands. It will run python commands and thus LCNC will fall into an error.

I would like to ask for your help, or at least for your opinion, if you also think that this is a bug that should be fixed.

Zdenek
 

IIRC wait complete asks for command's next available serialized id number.
It then decides the command is done when that id number (or higher) is send in the status message.
So wait complete only waits within the context of the python that called it.

I wonder if it's possible to request a command id number for the python command but the halui command actually runs first. Or some other out-of-sequence event.

Unfortunately your answer is too complicated for me. I don't know what it is IIRC. But still, I thank you for it.

I would like to ask you if you consider this LCNC behavior to be a bug that should be fixed?
Or do you have a different opinion on this behavior?

I tried this bug fix, but I couldn't transfer the variable "halui_sent_mdi" from one file to another.
forum.linuxcnc.org/gmoccapy/49335-self-c...lete?start=10#274203
What do you think about this FIX? Is this the right way?

Can I do anything more to fix this bug?
 

sorry IIRC - If I Recall Correctly

It's a problem for sure.
A proper fix would take a smarter then me programmer, to see if I am on the right track and to think of a good fix. I think it's a difficult problem.

The simplest fix is not to use halui, instead use the screen code.
Unfortunately As Far As I Know, Gmoccapy was not build to give access to it's internals for extensions.
Gmoccapy does have macro buttons though.
What behavior are you using halui for?

cmorley wrote:

It's a problem for sure.
 

Can be the bug added here:
github.com/orgs/LinuxCNC/projects/1
?

A proper fix would take a smarter then me programmer,

Who is the smarter programmer?

cmorley wrote:

Gmoccapy does have macro buttons though.
What behavior are you using halui for?
 

Hello Chris,

Did you mean such a test?

I modified file go_to_position.ngc :
Test number 1:
Run button Macro, then button Cooling.
 
I think it works as it should.

Test number 2:
I wanted to try the other way around, but if I press the Cooling button, the Macro button cannot be pressed.
 


Unfortunately Gmoccapy Macros are unusable for me.

I saw your question:
github.com/LinuxCNC/linuxcnc/issues/2561
Is this question related to this topic?

You could add the problem to the tracker, but I don't think it is defined specific enough yet.
Since it's a problem for only a few people, it probably won't get much attention unfortunately.
But at least it would be documented.

There are only a few developers that are really knowledgeable on the inner workings of linuxcnc's motion controller. they don't usually read the forum. the IRC or github is the best way to have them see your questions.

Yes I was prompted to ask about GMoccapy extensions by this situation.

The problem of the 'macro can't follow directly after the coolant button', is probably something that could be fixed in GMoccapy's code.

cmorley wrote:

You could add the problem to the tracker, but I don't think it is defined specific enough yet.
Since it's a problem for only a few people, it probably won't get much attention unfortunately.
But at least it would be documented.
 

What tracker do you mean?
This:
github.com/LinuxCNC/linuxcnc/issues
?

The oldest is from Jan 20, 2016.
I think a lot of Issues will remain open forever.
Every time I start a new Issue, I wonder if my Issue will also end like this.

I don't know how to solve it ideally. That's why I'm opening this topic.

I would like a list of bugs that are planned to be solved. I understand that different bugs can have different priority. But I would know that I don't need to raise the issue anymore.

I understand that this project is a volunteer project, so no one can be forced into anything.

On the other hand, I always have a dilemma, what are the reasons why the problem is not solved?
- is this really a bug or am I using LCNC incorrectly?
- have I explained this problem well? Shall I continue to explain?
- did I explain the consequences of this bug well? Shall I continue to explain?
- how long should I wait if no one answers?
- is my explanation too long? Will anyone be willing to read that much?
- is it just my selfishness? That I want my problem solved?
- did I upset anyone with my pressure to solve the problem?

Now I would go back to the "wait_complete() does not wait for halui" issue.

If the problem is evaluated as a problem for a few people and is not addressed, we should issue a warning.

Unfortunately, we don't know if this bug is the cause of this problem:
github.com/LinuxCNC/linuxcnc/issues/2453
I think so, but I don't know.

This bug is very dangerous. It is random and can crash the machine:
user-images.githubusercontent.com/966185...5db-c6b508149f73.png

The question is, what kind of warning should it be?
"Do not use HALUI - MDI commands, it may cause unexpected LinuxCNC behavior"

The question is, where should the warning be?
- at HALUI?
- with almost every GUI?

It would be ideal to disable HALUI MDI-COMMANDS. I think it is better. when a feature is disabled than when it behaves randomly.

I've been working on this bug since Apr 27. I accept that I won't be able to use HALUI MDI-COMMANDS, but I think I deserve a warning for others not to make the same mistake I did.