Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: TTalma on February 02, 2019, 05:55:01 PM
-
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