Python Interface makes race conditions - mayby
zz912:I would also suggest not using HALUI MDI commands.
Ask the Gmoccapy devs to add INI MDI command ability to Gmoccapy.
Now I'm confused, why would Chris suggest NOT to use 'HALUI MDI commands' and then tell you to ask that 'INI MDI commands' are added to Gmoccapy if they were the same thing?HALUI MDI Commands = INI MDI Commands
Please Log in or Create an account to join the conversation.
HALUI MDI commands
We think this:
github.com/LinuxCNC/linuxcnc/blob/2.9/src/emc/usr_intf/halui.cc
"Ask the Gmoccapy devs to add INI MDI command ability to Gmoccapy."
I don't like duplicating the same function.:
github.com/LinuxCNC/linuxcnc/blob/2.9/sr...gmoccapy/gmoccapy.py
I don't like duplicating the same function, but it would be easier for a programmer.
Please Log in or Create an account to join the conversation.
github.com/LinuxCNC/linuxcnc/blob/f7187c...r_intf/halui.cc#L253
I dont know how it read in Gmoccapy.py file. Unfortunately, this is only one of many problems. On the other hand, I think there are programmers who can read variables from c++ in python.
That's why I'm writing here a concept of how everything should work overall. I don't think it would be that complicated.
Please Log in or Create an account to join the conversation.
The difference is which program runs the MDI command. The GUI can't 'wait_complete' HALUI commands. You should ne able to avoid the race if the same program runs all MDI type commands.Cmorley:
I would also suggest not using HALUI MDI commands.
Ask the Gmoccapy devs to add INI MDI command ability to Gmoccapy.
zz912:HALUI MDI Commands = INI MDI Commands
Now I'm confused, why would Chris suggest NOT to use 'HALUI MDI commands' and then tell you to ask that 'INI MDI commands' are added to Gmoccapy if they were the same thing?
Please Log in or Create an account to join the conversation.
If I have a remap with
' yield INTERP_EXECUTE_FINISH'
does that only wait for c.mdi() or 'self.execute()' commands of that particular remap to finish?
Please Log in or Create an account to join the conversation.
I am talking of [Halui] MDI_COMMANDS=
They mostly work.
Please Log in or Create an account to join the conversation.
i was thinking about the problem with HALUI MDI_commands.
How it works:
1) Here it finds out what mode the LCNC was in before the commands start being executed:
if (!halui_sent_mdi) {
// There is currently no MDI command from halui executing, we're
// currently starting the first one. Record what the Task mode is,
// so we can restore it when all the MDI commands finish.
halui_old_mode = emcStatus->task.mode;
2) HALUI MDI_commands are executed.
3) old mode is returning
if (halui_sent_mdi) { // we have an ongoing MDI command
if (emcStatus->status == 1) { //which seems to have finished
halui_sent_mdi = 0;
switch (halui_old_mode) {
case EMC_TASK_MODE_MANUAL: sendManual();break;
case EMC_TASK_MODE_MDI: break;
case EMC_TASK_MODE_AUTO: sendAuto();break;
default: sendManual();break;
}
}
}
There is usually a problem with restore mode. Python interface does not know that halui will change mode and start working.
I've been wondering all this time how to make the Python Interface know that halui is going to change modes.
But today a different philosophy occurred to me. If halui knows something is going on, it won't execute restore mode.
if (halui_sent_mdi) { // we have an ongoing MDI command
if (emcStatus->status == 1) { //which seems to have finished
halui_sent_mdi = 0;
if (emcStatus->task.interpState == EMC_TASK_INTERP_IDLE) {
switch (halui_old_mode) {
case EMC_TASK_MODE_MANUAL: sendManual();break;
case EMC_TASK_MODE_MDI: break;
case EMC_TASK_MODE_AUTO: sendAuto();break;
default: sendManual();break;
}
}
}
}
What do you think about it?
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
You don't have to worry about that. I will definitely do a PR. Unfortunately, I've already made a lot of mess on Github with my theories.Otherwise it is likely to just get buried here.
For example, there are many of my theories in which I contradict myself.
github.com/LinuxCNC/linuxcnc/issues/2453
That's why I like to put only what I'm at least somewhat sure about on Github.
I also contradict myself in this thread. First I started with theories where I would like to add signals to check if a process is already running. After that I thought about it and now I think it could be solved via IDLE mode. IDLE mode is stuff that is and has always been part of LCNC, so I wouldn't complicate anything.
For example, Issue 2453 is very insidious in that some developers are unable to simulate it at all or only to a very limited extent to be able to fix it.
Therefore, it is necessary to go through the code manually and remove situations where race conditions could arise.
The problem is that a problem can be caused by several situations, so if we remove only one, nothing may appear, but it is necessary to proceed in this way if we want LCNC to be a stable system.
Please Log in or Create an account to join the conversation.
If your unhappy with an issue or pull-request you made on github then just close it to tidy things up.
I usually need several attempts with pull requests and issues myself.
Please Log in or Create an account to join the conversation.