So, between our drill and tap cycle we have an M01 optional stop.  To let the operators know it is ready for the tap I want the indicator to turn on.  I noticed Mach 4 has an Optional Stop output, this output does not do what I expected.
I thought it would go active while there was an Optional Stop in affect; instead, it goes active while the Optional Stop is enabled.  I even used a macro to set the optional stop to see if it did anything different:  mc.mcCntlSetOptionalStop(inst, 1) it behaves the same.
Is there a way to get the handle on an Optional Stop in affect instead of it just being enabled?
 

I just thought of this, could I set up a new M01 macro putting out the code I would like?  In it I could even check for the state of M01 so it can still be an optional stop.

Page 10 of the scripting manual says you may not change M00 or M01.

rhtuttle,
Thanks for pointing that out, I forgot that was even in there.

M1 runs ok for me?? are you trying to run it from the mdi?? as whilst in the mdi its not doing a cycle start after the m1 just running the mdi again.

load gcode
press optional stop in the Run Ops tab
cycle start
m1 comes alone and program stops
cycle start  and program continues

DazTheGas

Daz,  the M1 works just fine, I'm trying to get an output to turn on our light/buzzer during the M1 pause to let the operator know it's paused so they can go check the past and hit cycle start to finish the program.  The optional stop output in Mach config only gets the handle on M1 being enabled or not.
I'm wanting a signal saying that it is in a paused state due to M1 or M0.  Is this possible or should it be a feature request?

I'll be interested to hear how/if it can be done with an M1 but why not just create another macro and use it instead of M1?

function m7777()
ringBuzzer()
mcCntlWaitOnCycleStart 
end

I'm sure you have a valid reason, just offering another idea.

Rhtuttle,
I didn't k ow there was waitOnCycleStart.   I had thought about making a macro.  No real valid reason, it would just really be handy if there was a pause in affect output.  I think I'm going to out it on the feature request.   
Thanks for all the input and suggestions!

M01 (when opt stop is enabled) to does nothing more than programmatically doing the equivalent of hitting the stop button.  It just returns the machine to the idle state. 

Now, knowing this, one could craft up some code to put in the PLC script.  Here are the logic steps that you would want to take into account.

1. G code must have been running prior to the M01.
2. If G code was running AND OSIG_OPT_STOP is high AND G code was running AND the machine state is idle THEN buzzer!

#1 would need a variable to keep track of this information.  So put a global variable called gCodeWasRunning at the top of the screen load script.

gCodeWasRunning = 0 --keeps track if g code was running.

It is also very convenient to track interesting signal states with a variable as well.  So add a variable to track OSIG_OPT_STOP.

optStop = 0 --tracks OSIG_OPT_STOP

Now we need something to set this variable.  OSIG_GCODE_RUNNING will do fine for this.  So insert a bit of code in the siglib portion of the screen load script to set this variable to 1 if the state of OSIG_GCODE_RUNNING is equal to one.  And add something to track the OSIG_OPT_STOP signal here too.

[mc.OSIG_GCODE_RUNNING] = function (state)
    if( state == 1) then
       -- only set if the state is 1.
       gCodeWasRunning = 1
    end
end,
[mc.OSIG_OPT_STOP] = function (state)
    optStop = state;
end,

Next, in the PLC script add the following:

-- this assumes that mstate is declared above and that mc.mcCntlGetState() is called to set it.
if (gCodeWasRunning == 1 and optStop == 1 and mstate == mc.MC_STATE_IDLE) then
    gCodeWasRunning = 0 --reset the flag.
    --start buzzer
end

You probably would want to put something in the start cycle button to kill the buzzer if it is sounding as well. 

Steve

Steve, that's getting pretty deep.  I love the flexibility of Mach4.  I like what you have suggested, it will keep me from having to put a custom macro in.  Luckily, I've already making use of the GcodeRunning state and modifying the cycle start code as well, so I've got a good place to put this code already. 
I did still put this in the feature request, I think the versatility of this type of output would be great to have to make use of.
Thanks again for the Input Steve, you've got some great ideas!!