Jogging while in MDI mode

Since I started using LinuxCNC, I've been using qtdragon and a VistaCNC P4-S pendant.  Jogging with the pendant works fine when the Manual mode is selected (as opposed to MDI or Auto).  Any time I run an MDI command, it switches to MDI mode - and when it's in MDI mode any time I try to jog using the pendant, I get an error like "Homing is REQUIRED to jog requested coordinate because joint (0) home_sequence is synchronized (-1)" (screenshot attached).  No idea if the issue has anything to do with the pendant or just LinuxCNC itself, just figured I'd mention it.
I can click a button to put it back in Manual mode and then jogging works again.  That's annoying though - and anyway, the error doesn't make much sense to me.  

I poked around in the code and found the specific error text in command.c  (emcmotCommandHandler); the only thing that jumps out at me from the logic that triggers this error is that it only occurs when GET_MOTION_TELEOP_FLAG() is False.  
Digging around a bit, I found some notes that suggest that when in MDI or Auto it's in "Coordinated" mode, as opposed to "Axis mode (aka teleop)"

Is this some fundamental limitation, that MDI and jogging are incompatible?  Or is there something I can change to make it work? (maybe some way to make it go back to teleop mode even if MDI is active, any time it's not actively running any MDI commands?)

Any clues or pointers would be appreciated.

I like your detective work.

Im fairly sure its only meant for jogging while an MDI is active, But qtdragun is like most cnc machines, and require you to exit mdi mode. Its probably a safetly feature in the gui setting it to mdi mode when the mdi is raised.
In Axis gui I think its only in MDI mode when the command is actually executing

What version of linuxcnc you are using?

I'm using a RIP build, built from source (master) within the last week, which identifies as 2.9.0~pre0.

Digging into the documentation some more, it seems that in the motion controller Coordinated mode (as used for running code, e.g. MDI) and Teleoperating mode (supports jogging) are similar in that they both work at the axis level using kinematics, but Coordinated is controlled by the trajectory planner while Teleop does not, instead taking a velocity vector. That does make it sound like they're mutually exclusive.

What's throwing me though is that the error message here seems to suggest that if only I had a machine which was safe to jog at the joint level (trivial kinematics, no joints set for synchronized homing) then I'd be allowed to jog it while in MDI (Coordinated) mode(?) That doesn't seem logical, since Coordinated mode uses kinematics, unlike Free mode. Unfortunately my CNC router doesn't technically have entirely trivial kinematics (dual drive joints on Y) so I'd have to mess around a bit to test this theory.

This makes me suspect that this error message may actually be a red herring altogether; the text of the error message only makes sense if the controller is in Free mode on a machine which needs to use kinematics to safely jog - however the logic that triggers the error doesn't actually check if the controller is in Free mode, it just checks that it's NOT in Teleop mode - so the error gets triggered just the same when in Coordinated mode.
If that's true, then I see two possibilities:
1) The error is invalid, change the logic so it doesn't trip in Coordinated - ostensibly allowing it to (try to) jog in that mode - not sure if it'll work, or if bad things will happen!
2) Or, if bad things happen with the above, then the logic should be changed so that a different (relevant) error message is thrown in that case - e.g. "Cannot jog while in Coordinated mode"

Thoughts?

I've had issues with my Vista P4S, but I don't think it's the same thing you're experiencing.  And I agree that the error message you've described may be a red herring.

Just to make sure - you want the Vista to work (i.e. jog) whenever you activate the handwheel, as long as LCNC isn't currently running a program in Auto mode or MDI mode?  Selecting "manual" mode every time you want to jog is irritating, right?  (I agree, TBH).

I wonder if you (maybe me, too) can add to the vista vc-p4s.hal file something to automatically trigger halui.mode.teleop whenever the handwheel is turned.

Right now it's got the following to 'trigger' jogging:

Which I don't really understand... How does the vc-4ps jog by triggering both the axis jog and the joint jog?  It works, but I don't get it.

More importantly, I wonder if you can add a connection so the signal is also connected to halui.mode.teleop.  In theory every time the handwheel counts change, the handwheel itself would command a change to teleop mode.  You wouldn't have to press any 'manual' buttons - just jog the thing and the pendant takes over the machine mode.

Might need an or2 & NOT logic connection to ensure moving the handwheel doesn't interfere with running a program.

Worth a test I think.

-R


 

Like you, the vc-p4s.hal file has me scratching my head with all the joint references... especially since my machine is XYYZ so Joint 2 is the second Y axis motor, not the Z axis. But it seems to work as is, so I've left well enough alone...

Thanks for the additional idea. I also agree with the need to somehow prevent it from triggering teleop mode while something was running in MDI or Auto mode.

In any case, I've ruled out possibility #1 from above - I changed the logic to not trigger this error when in Coordinated mode, and I don't get the error, and nothing bad happens, but it also doesn't jog. Oh well, scratch that.

Well, for what it's worth, a very small change to qtdragon_handler.py (see attached) was enough to get it to automatically kick back into Manual mode after running an MDI command.  The qtdragon gui button indicators for Manual/MDI update accordingly without me needing to intervene.

I tried triggering this off signals like `command-stopped` but it wasn't working for single MDI commands - I'm guessing based on the code where these signals are emitted (in hal_glib.py) that since they're based on polled status, running a single MDI command happens so quickly that the status change from RCS_DONE to RCS_EXEC and back to RCS_DONE happens too quickly for it to even register the state change and trigger the signal(s).

I'll play with it some more to look for unintended consequences, but I'm cautiously optimistic that this small change might suffice.

Nice job with the diagnostics, and thanks for reporting back.  Might help someone else in the future (like me!)

funkenjaeger wrote:

Like you, the vc-p4s.hal file has me scratching my head with all the joint references... especially since my machine is XYYZ so Joint 2 is the second Y axis motor, not the Z axis. But it seems to work as is, so I've left well enough alone...


 

I just had a brain wave...

I think the vc-p4s is referencing both joint and teleop jog so the pendant works before and after homing the machine.  In your case, you probably have a forced-homing-before-jog feature turned on, so you'd never notice a joint jog.  And in my simple XYZA mill I don't notice the difference between pre- and post-homing jogs.

But you'd better be sure not to turn off forced homing...I bet the p4s could rack your gantry in joint mode with the hal file as-is.

spumco wrote:

But you'd better be sure not to turn off forced homing...I bet the p4s could rack your gantry in joint mode with the hal file as-is.

Somewhat ironically, the logic in emcmotCommandHandler that started this whole inquiry protects me from exactly that, regardless of any other settings that might be in place - because I (necessarily) have my two Y joints set to synchronous homing.