I am working on a sanding machine, and I want to be able to move away from the sanding surface quickly if I get an overload signal from the sanding motor.
I was thinking if I make each pass as a jog with the y axis, the z axis could be operated independently and moved away from the surface of the part while the y axis was still moving.

I was trying to test the  mc.mcJogIncStart function with the following code:

function m91002()
   local inst = mc.mcGetInstance()
   rc = mc.mcJogIncStart(inst, 0, -.2)
   if rc ~= mc.MERROR_NOERROR then
      wx.wxMessageBox("failure")
   end
end

I get the message "failure" when I run m91002 in the MDI, but if I remove the "function m91002()" at the beginning of the code, it works one time.
Any ideas about what I am missing or doing wrong? Also if anyone feels that there is a better way to go about this, I'm all ears!
Thanks,
David

Instead of displaying 'failure' why not display wx.wxMessageBox(mcErrorCheck[rc])?  It might give you better debugging information.

HTH

RT

You can't jog a coordinated axis from an M code.  Period.  Because the machine is in automatic mode when running G code.  Jogging coordinated axes is only possible in manual mode.  Determining what the return code is would tell you this.  We know it is not MERROR_NOERROR.  But what is the return code exactly?  If you had looked at it, you would have seen that it is -18 (MERROR_NOT_NOW).  Meaning you cannot jog now. 

To RT's point, the return codes are numbers like -18.  As such, it is hard to know what they mean unless you have memorized them.  This is why mc.mcCntlGetErrorString() exists. 

function m91002()
local inst = mc.mcGetInstance()
rc = mc.mcJogIncStart(inst, 0, -.2)
if rc ~= mc.MERROR_NOERROR then
local rcText = mcCntlGetErrorString(inst, rc)
-- wx.wxMessageBox("failure") -- you have to be careful with message boxes in scripts!!!! 
-- Better to use mc.mcCntlSetLastError().
mc.mcCntlSetLastError(inst, "m91002(): " .. rcText)
end
end

Notice the comment about wxMessageBox().  You can paint yourself into a corner really quickly using wxMessageBox() in macro scripts.  It is best not to use them.  You should use mcCntlSetLastError() or mcCntlLog() (requires the log window to be up) instead. 

Steve

Thanks for all the help with the return code info!  This will make things much easier for sure.

Any suggestions for what I'm trying to do?  Here's a more specific description:

While y axis is moving from point a to point b, check input a.  If input a becomes true, then move z axis up .005" without interfering with y axis move.

I feel like this must be a really easy thing to do, but I'm somehow just not stumbling across the right method.

Thanks for all the input so far!!

Hi,
your proposal sounds simple but it is in fact not so easy at all.

Lets say you have a Gcode move be it from a Gcode program or MDI, Machs trajectory planner will issue PVT (Position, Velocity over Time)
data in 1ms slices. This numeric data will be put in the buffer to be 'consumed' by the motion controller at the rate of one data set per millisecond.
Typically the buffer in Mach4 is around 200ms. The default setting with the ESS for instance is 180ms.

Lets assume for the purposes of this discussion that the buffer has 100 data sets or 100ms worth of moves stored up. At that instant your input 'a'
changes state and now you wish to change the trajectory of the machine. If you abort the trajectory data within the buffer then Mach has lost reference,
a bad outcome. That would be like an Estop. Even assuming that you could abort the pre-existing data sets there would be a time when the motion
controller had no fresh data sets to consume so it would be stationary which rather violates your intention that the y axis progress smoothly
while there may be a variation in the z axis.

The type of motion you want is actually very similar to THC used on plasma tables. A plasma table has typically a succession of 2D moves
in X and Y as it traces out the shape of the part but the Z axis will go up a bit or down a bit to maintain a near constant arc voltage. This has
to be achieved WITHOUT affecting the smooth motion of X and Y and must not cause Mach to loose reference.

THC has, until recently at least, been enacted by the motion controller as the motion controller works in realtime whereas Mach does not.
Even then only two Mach4 ready motion controllers have that feature, the Hicon Integra and the ESS. More recently NFS have released
a scripted version of THC which does not require realtime support on the behalf of the motion controller. It is very much slower to respond
but is none the less adequate for a good many plasma tables.

May I suggest you look closely at the THC feature of Mach4 to determine whether you might adapt it to your sanding machine.

The only other option that I can think of, dare I say it, is LinuxCNC. LinuxCNC is a realtime computing system and does not have a buffer
as Mach does. This results from the fact that LinuxCNC runs on a realtime capable version of Linux. Windows PC's are not realtime capable,
at least in any practical sense, and thus ALL Windows CNC solutions including Mach, UCCNC, PlanetCNC, WinCNC etc require a buffer.

Craig

The way THC works is by overriding the Z axis with an out of band (non coordinated axis).  So Craig has again hit the nail upon the head.  You can jog out of band axes via velocity or incrementally.

I don't have time to write this out in code, but I will give a general synapses of how it would work.

Override the Z axis with say OOB1. 
Have the PLC script track an input signal (sig lib)
If the signal changes from low to high, jog the OOB axis up .050".
If the signal changes from high to low, jog the OOB axis down .050" (if required).

Not terribly complicated, but not a one liner either.  It is left as an exercise for the user to implement it. 

Steve

Thanks so much guys!! I think I'll be able to get something working coming at it with the THC angle.