search

LinuxCNC / linuxcnc

LinuxCNC controls CNC machines. It can drive milling machines, lathes, 3d printers, laser cutters, plasma cutters, robot arms, hexapods, and more.
http://linuxcnc.org/
GNU General Public License v2.0
1.78k stars 1.14k forks source link

Axis not allowing MDI queuing #2460

Open dberndt391 opened 1 year ago

dberndt391 commented 1 year ago

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 https://github.com/LinuxCNC/linuxcnc/commit/301e3a1b28a18d475f4c26d984640a1da9450504 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 commented 1 year ago

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 commented 1 year ago

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

@dngarrett is that branch ready for a PR?

0wn3r commented 5 months ago

@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: image

andypugh commented 5 months ago

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

dberndt391 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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: https://github.com/LinuxCNC/linuxcnc/issues/2956#issuecomment-2043493771 For inspiration.