I have my output from my VFD set to trigger when it is at zero. I have this connected to the Spindle at zero input. When I check with a meter this is going low. It takes 10 seconds for my spindle to stop.

So I added some script to make sure my spindle is stopped when doing a tool change.

    ------ Make sure the spindle is stopped ------
    mc.mcCntlGcodeExecuteWait(inst, "M5\n")
    local SpindleAtZero = mc.mcSignalGetHandle(inst, mc.ISIG_SPINDLE_AT_ZERO)
    --local ret2 = mc.mcSignalGetState(mc.ISIG_SPINDLE_AT_ZERO)
    local ret = mc.mcSignalWait(inst, SpindleAtZero, mc.WAIT_MODE_LOW, 10.0)

The first line appears to work and tells the spindle to stop.

The second line returns a number

The third line (Commented out) crashes Mach 4?? So I have no way of telling what mach reads this as.

The 4th line always returns -2, and the is immediately skipped over even if the spindle is still rotating.

What am I doing wrong? I thought this line would make the machine stop and wait until it had stopped rotating, or the timeout expired. It's doing neither.

How do I wait for spindle at zero?

Hi,
couple of things I have spotted.

the  API is;

LUA Syntax:
rc = mc.mcSignalWait(
      number mInst,
      number sigId,
      number waitMode,
      number timeoutSecs);

But note in the descrition:

sigId A valid signal ID. (NOT a signal handle)

A signal ID not a signal handle. You are using a signal handle and that is incorrect.

The potential error states are:

MERROR_NOERROR No Error.
MERROR_INVALID_INSTANCE The mInst parameter was out of range.
MERROR_INVALID_ARG sigId or wiatMode is out of range or timeoutSecs is negative.
MERROR_NOT_ENABLED The control is not enabled.
MERROR_TIMED_OUT The timeout period was reached without a change of state.

         0  =   MERROR_NOERROR   
   -1  =   MERROR_INVALID_INSTANCE
         -2 =    MERROR_INVALID_ARG
        -31  =   MERROR_NOT_ENABLED
        -40  =   MERROR_TIMED_OUT

I will attach a file that has the list of numeric error state equivalents.
Thus given that you are using a signal handle instead of a signal ID in line 4 is why you are getting MERROR_INVALID_ARG.

As for line 3 you are using a signal ID when you should be using a signal handle.

 --local ret2 = mc.mcSignalGetState(mc.ISIG_SPINDLE_AT_ZERO)SpindleAtZero)       SpindleAtZero is a handle.....

Craig

Thanks for the help. I am used to the C programming world, and learning LUA, And the mach functions for it. I think I get the difference between the signal and the handle to it. I'm thinking the handle is LUA's version of a pointer in C.

Anyway my code now looks like:

    ------ Make sure the spindle is stopped ------
    mc.mcCntlGcodeExecuteWait(inst, "M5\n")
    local SpindleAtZero = mc.mcSignalGetHandle(inst, mc.ISIG_SPINDLE_AT_ZERO)
    local ret2 = mc.mcSignalGetState(SpindleAtZero)
    local ret = mc.mcSignalWait(inst, mc.ISIG_SPINDLE_AT_ZERO, mc.WAIT_MODE_LOW, 10.0)

The first 3 lines work, with line 3 returning 0 while the spindle is moving and 1 when it has stopped, which is good.

But line 4 is still giving the MERROR_INVALID_ARG error. Looking at the documentation, and the very little I could find online I think I have this set up correctly. But it still says one parameter is wrong. If I remove the 'mc.' from in front of the second two parameters it gives the "Error running Chunk" error.

Hi,
there was a time when I had a similar problem with the mcSignalWait() API, and the MERROR_INVALID_ARG.

It turns out that at that time the numeric range of the signal IDs was only up to 64 whereas ISIG_SPINDLE_AT_SPEED
is 120 or so. Try using ISIG_INPUT20 say. I thought the fault had been corrected but maybe you have an early build.

Craig

Thanks that was it. I tied "Spindle at Zero" to Input 20 and it worked right away!

I have version 4.2.0.3481, Build 3481

I installed it a few months back after a hard drive failure, Is there a new version I should get??

Hi,
I'm using 3804 and the numeric range of the valid input signal ID's is complete for ALL defined input signals.

mcSignalWait() is one of the few APIs for which I test EVERY MERROR.....I've been caught too many times with this API
doing something weird because of some condition that I didn't think about.

Craig