qtDragon: Auto Return to Manual Mode After an MDI Command so MPG works

More
8 months 6 days ago #343442 by Paul_W
qtDragon: Automatically Return to Manual Mode After an MDI CommandThe ProblemIf you use a pendant with qtDragon, you've probably run into this annoyance: after executing an MDI command, LinuxCNC stays in MDI mode. Before your pendant will respond to jog inputs, you have to manually click a movement button (or otherwise trigger a mode switch) to get back into manual mode. On a busy machine this gets old fast.  I use a VistaCNC P4-S.The FixThe solution is a small addition to your
Code:
qtdragon_handler.py
. We connect to LinuxCNC's
Code:
interp-idle
STATUS signal, which fires whenever the interpreter finishes executing. When that signal fires and we're still in MDI mode, we automatically switch back to manual.Step 1 — Get a local copy of the handlerIf you don't already have a
Code:
qtdragon_handler.py
in your config directory, copy the system default there. LinuxCNC will automatically prefer the local copy over the system one.
Code:
cp /usr/share/qtvcp/screens/qtdragon/qtdragon_handler.py ~/linuxcnc/configs/<your-config>/
Step 2 — Edit the handlerOpen your local
Code:
qtdragon_handler.py
and make two small changes:In the
Code:
initialized__
method, add the signal connection:
Code:
def initialized__(self): # ... your existing code ... STATUS.connect('interp-idle', self._on_interp_idle)
Add the callback method somewhere in the class:
Code:
def _on_interp_idle(self, obj): if STATUS.is_mdi_mode(): ACTION.SET_MANUAL_MODE()
That's it.How It Works
  • Code:
    interp-idle
    fires whenever the interpreter becomes idle — MDI command finished, program finished, etc.
  • The
    Code:
    STATUS.is_mdi_mode()
    guard ensures we only switch to manual when we're actually in MDI mode, so it won't interfere with the end of a normal G-code program run.
  • Code:
    ACTION.SET_MANUAL_MODE()
    does exactly what it says — same as clicking the Manual button in the UI.
Notes
  • Tested on LinuxCNC 2.9.6 with qtDragon.
  • This should work on any 2.9.x build without modification.
  • If you're on 2.8, the same approach should work but
    Code:
    STATUS
    and
    Code:
    ACTION
    import paths may differ slightly depending on your build.
  • This does not affect program (auto) mode — when a G-code program finishes it will stay in auto mode as expected, since
    Code:
    is_mdi_mode()
    will return False.
CreditFigured this out with a little help. Posting here so the next person doesn't spend 3 hours on it.Hope this helps someone!

Please Log in to join the conversation.

More
8 months 5 days ago #343479 by tightmopedman9
Are there any potential drawbacks of this? I've wondered why this wasn't the standard implementation - I figured it was for good reason, so never asked. I ended up dedicating a physical button to activate MDI mode instead, but it feels like a waste of a button...

Will this modification switch back to MDI mode after a python based probing cycle (successful or failed)? I find that's the most frequent time I need to switch back to MDI mode.

Please Log in to join the conversation.

More
8 months 5 days ago #343496 by cmorley
If this is a common complaint, I could add this as an checkbox option in master branch.

As far as other wanted/annoying behaviors - feedback welcome.
I won't guarantee you always get what you want but usually can at least help with customizations

Chris

Please Log in to join the conversation.

More
3 months 3 weeks ago #347660 by Odiug
Yes, same here. I was just searching the forum if others have the same problem or if it is just me "holding it wrong".

In my usual workflow, I load a toolprobe using a manual toolchange with automatic tool length measurement. This happend in MDI. Then I usually forget to hit the MAN button and wonder why my ShuttleXpress does not work anymore.

Same with using the toolprobe in the Probe tab. After probing we are again back to MDI mode.

I was wondering if there is a reason for being in MDI mode. From a user standpoint I was manually operating the machine, expecting to be back in manual mode after pressing a few buttons, even when those trigger MDI mode.

Guido

Please Log in to join the conversation.

More
3 months 2 weeks ago #347671 by cmorley
The switching to MDI mode is sometimes a limitation of linuxcnc.
There are a lot of 'manual' things that linuxcnc requires MDi for.

But it is also hard to predict what each users expects and also hard to control for whatever way a user sets up a machine.

Which tool probe are you using? versa, basic or the convenience button for touchoff?

Please Log in to join the conversation.

More
3 months 2 weeks ago #347683 by cmorley
Ok if you are using Master branch, I just pushed work to return to the original mode for most things I could find, probing, MDI convince buttons, etc.

Please check it out and let me know what you think or what I missed.

Chris

Please Log in to join the conversation.

More
3 months 2 weeks ago #347771 by Odiug
Hi Chris,

thanks for looking into it.
I am currently just running the normal 2.9.10 LinuxCNC. I guess it came with a version of QtDragon? I have to figure out first what's the best way to run the Master branch.
Can I check it out and use it parallel to the 2.9.10 version and be able to switch back and forth?

Guido

Please Log in to join the conversation.

More
3 months 2 weeks ago #347773 by rhscdn

Please Log in to join the conversation.

More
3 months 2 weeks ago #347787 by rodw
For interest, I had a pendant I had hardwired in that had a Deadman switch that had to be held in before you could jog. I was using Gmocappy at the time and I got sick of changing modes which also changed the tab. I was able to wire this Deadman switch to halui.mode.teleop and life was happy as I never had to bother swapping modes again.

Please Log in to join the conversation.

Time to create page: 0.092 seconds
Powered by Kunena Forum