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

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. We connect to LinuxCNC'sSTATUS 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 ain your config directory, copy the system default there. LinuxCNC will automatically prefer the local copy over the system one.Step 2 — Edit the handlerOpen your localand make two small changes:In the method, add the signal connection:Add the callback method somewhere in the class:That's it.How It Works

• interp-idle

  fires whenever the interpreter becomes idle — MDI command finished, program finished, etc.
• The

  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.

• 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

  STATUS

  and

  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

  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!

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.

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

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