Axis not allowing MDI queuing

[dberndt391]

Have an issue with not being able to "queue up" MDI commands as I was previously able to do.

method of duplication:

1. Start sim
2. home axis
3. go to mdi tab
4. enter a command that takes a while, g1 x1 f0.05
5. enter another command, note you can not press go to queue up/submit the command.

This is what I expected to happen:

Commands in MDI queue up into the history window and are executed sequentially.

This is what happened instead:

Go button and return/enter does not import the command into the MDI history list

It worked properly before this:

I believe this behaviour changed in 301e3a1
added to def manual_ok:
...
"if running(): return 0"
...

I am using this Linux distribution and version

I'm running on linux mint 21
kernel 6.1.0.7-rt
linuxcnc RIP 2.9-pre1
using AXIS

[rene-dev]

maybe this is related, but ini variable MDI_QUEUED_COMMANDS is read and never used.
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/task/emctaskmain.cc#L3271

[SebKuzminsky]

@dberndt391 can you confirm if this is fixed in the 2.9_#2460 branch?

@dngarrett is that branch ready for a PR?

[0wn3r]

@SebKuzminsky I did a test run with attached patch on top of current 2.9 branch:
without:
Screencast from 2024-04-08 17-12-35.webm
and with fix:
Screencast from 2024-04-08 17-59-58.webm
I also executed tests after compilation:

[andypugh]

Curously, #2956 is asking that MDI queuing be removed.

[dberndt391]

Thanks for looking into this. I can't test currently as the affected machine is in production but the screencasts provided by 0wn3r look good.

As to the 2956 issue. Well I guess I'd just say they're using MDI wrong or something. The loss of MDI stacking would be tragic. I often find myself in a place where writing a bunch of g-code to file then running that would be overkill, but entering a few lines at the MDI and walking away while the machine runs is perfect. If any change from that is intended I'd like to see a behavior toggle or some sort of option.

I'm also not really convinced that not allowing stacking is the same thing as what is being quoted in NIST 3.6.1. Would it make more sense to make entering an M0/M1 in MDI actually put the machine in the pause state in the same way it would when running gcode from a file? Forcing the user to press the run to continue with any stacked (or even in the case where there are no stacked commands the next MDI command should not execute, as the machine is paused). Wouldn't that be a more consistent behavior?

[dberndt391]

Sorry about the close/reopen. Pressed the wrong button.

Thanks for looking into this. I can't test currently as the affected machine is in production but the screencasts provided by 0wn3r look good.

As to the 2956 issue. Well I guess I'd just say they're using MDI wrong or something. The loss of MDI stacking would be tragic. I often find myself in a place where writing a bunch of g-code to file then running that would be overkill, but entering a few lines at the MDI and walking away while the machine runs is perfect. If any change from that is intended I'd like to see a behavior toggle or some sort of option.

I'm also not really convinced that not allowing stacking is the same thing as what is being quoted in NIST 3.6.1. Would it make more sense to make entering an M0/M1 in MDI actually put the machine in the pause state in the same way it would when running gcode from a file? Forcing the user to press the run to continue with any stacked (or even in the case where there are no stacked commands the next MDI command should not execute, as the machine is paused). Wouldn't that be a more consistent behavior?

[zz912]

Thanks Andy for merge #2956 .

Has Axis and Gmoccapy same MDI history modul?

Here I described the MDI commands solution from a very old machine, variant 4:
#2956 (comment)
For inspiration.

[Sigma1912]

This can be closed as fixed by 7852337