Ok.. the normal M66 wait for input is bound to cause some issues as it waits and then... woosh.. the machine will take off.. (yes, I know you can check for the timeout but that actually leads to more coding)..  any other machine I have seen, and nearly any device, plc, robot, etc. would never do this.. so I wrote my own m66.. I actually call it m166 to distinguish between the two and ran into the following issue.. I have a While do loop that waits for an input to go high (or low).. and it works fine with one exception... if its waiting and you close Mach4.. well it doesn't actually close.. I'd guess because its still looping and can't stop the thread... so it would be nice if I could do a check and see if M4 is still running, and if not Abort and close. Can't seem to locate any function to return the state of the application.. any suggestions?
thanks, Bob

You can do something like this:
function m166()
local inst = mc.mcGetInstance()

--Wait for input0 to go high, timeout 2 seconds
rc = mc.mcSignalWait(inst, mc.ISIG_INPUT0, mc.WAIT_MODE_HIGH, 2)

if (rc == mc.MERROR_TIMED_OUT) then
--Stop the program if timed out
mc.mcCntlMacroStop(inst, rc, "Timeout waiting for signal")
return
end

end

if (mc.mcInEditor() == 1) then
m166()
end

You'll have to adjust it for the signal you're waiting for and the wait mode. There are a few options FALL, HIGH, RISE, NONE, LOW

thats the standard method and thats pretty much what I don't want to do.. I'm interfaced to several other pieces of equipment.. and frequently those pieces are waiting on either components or some operator operation.. and often the operators can could break for lunch.. or a meeting.. I don't want to break out of the loop and then need to determine with more code why I'm suddenly in a place I shouldn't be (in the Gcode).. so waiting in a 'while do' loop resolves this.. however in testing, if I enter the loop, then disable the run mode, the loop doesn't seem to stop, even if I use a program (Gcode) reset.. and if I press run screwy stuff possibly occurs..

Closing Mach4 if the loop is running is only a marginal issue.. once you do so, Mach4 doesn't actually stop and unload.. so you can't restart it (you get an error that an instance is already running).. I know I can use Task Manager to abort the program, but an operator can simply reboot the pc.. so thats not a big concern. Pain in the proverbial butt though..

Ok, what happens when you press the Disable button or E-Stop button?  The machine goes into the IDLE state, right?  Simply check for the idle state in your loop.

local state = 0
local rc = mc.MERROR_NOERROR
local loopCondition = 1

state, rc = mc.mcCntlGetState(inst)
while (loopCondition == 1) and (state ~= mc.MC_STATE_IDLE) do
    wx.wxMilliSleep(10) -- Sleep for 10 milliseconds
    state, rc = mc.mcCntlGetState(inst)
end

Steve

I've resolved this issue and some others.. I only noticed this since I'm testing in my office not the actual machine.. so I was testing my WHILE loop.. I pressed STOP.. then tried something different with my GCode.. but when I tried to CYCLE START the demo had expired.. So I closed Mach4 and surprise!! I couldn't restart.. seems some portion of Mach4 couldn't release... Yes, if I looked for the estop or enable prior to closing I could add that to my WHILE LOOP but STOP didn't actually stop the loop, (neither would RESET) and it would restart with the loop running.. never reported IDLE (probably because the loop is still operational)... that's not acceptable.. I did try looking for the ENABLE signal but that proved unreliable. I ended up setting up a GLOBAL register and setting to something (100) when I pressed CycleStart.. My while loop looks for this and for the variable I'm waiting for to change state.. If I press STOP, RESET, or close MACH4 I set the variable to zero and the loop breaks and closes the routine. I found this worked every time without failure. I've also worked on not losing position if pressing STOP or RESET and have two options for my application. I'm deciding which is best. And I've also interlocked the CycleStart to the axis being HOMED like most industrial equipment would be. Can't start a program legitimately without actually knowing where the machine is. Unless you want to rip off a robot arm, demolish a fixture, or do something else that should end up on YouTube as an example of what not to do.

Stop NEVER stops the loop.  E-Stop will not stop the loop.  Once a script starts, it runs to completion.  So if you use loops you MUST provide a way to break out of the loop.  It is designed that way and it is perfectly acceptable.  Here is why: Manual tool changes or any operation that requires the control to be taken out of automatic/run mode.  Also, some scripts may need to detect the E-Stop, Reset, or Cycle Stop condition and perform some cleanup or safety action.  I just gave an example in another post where the script needs to continue to run even when the control is put into the idle state. 

I took my M3 script and modified it to test the code I gave above.  I tested this script and I could break out of the loop with cycle stop and disable 100% of the time.

function m3()
    local inst = mc.mcGetInstance('M3')
    mc.mcCntlSetLastError(inst, 'Going into the loop')

    local state = 0
    local rc = mc.MERROR_NOERROR
    local loopCondition = 1

    state, rc = mc.mcCntlGetState(inst)
    while (loopCondition == 1) and (state ~= mc.MC_STATE_IDLE) do
        wx.wxMilliSleep(10) -- Sleep for 10 milliseconds
        state, rc = mc.mcCntlGetState(inst)
    end
    mc.mcCntlSetLastError(inst, 'Broke out of the loop.')

end

if mc.mcInEditor() == 1 then
m3()
end


And I've also interlocked the CycleStart to the axis being HOMED like most industrial equipment would be. Can't start a program legitimately without actually knowing where the machine is. Unless you want to rip off a robot arm, demolish a fixture, or do something else that should end up on YouTube as an example of what not to do.

Mach is designed to run with as little modification as possible on as many machines as possible.  We simply cannot make a configuration that covers every machine.  So it is up to the machine integrator (you) to make it work how you want it to work if you want something different than our defaults.  If you want it more industrial, then we give you the tools to make that happen.  That said, there are lots of examples with auto homing (PMC objects and LUA scripts) to help in that goal.  I really like using the PMC to do tasks like this as it doesn't require any scripting.  There is also an option in the general tab of the configuration dialog that lets you select if you want the axes to be dereferenced in e-stop.  Believe it or not, we have a lot of customers that don't even have home switches.  All machines are different unless you are an OEM that is building lots of the same models.  For instance, my machine, once homed, will not lose position even if you hit e-stop.  I can reference the machine once when I turn it on and never have to reference it again until I turn it off.  If it homed every time I pressed Cycle Start after e-stop (I have no Cycle Stop button on it), I'd lose my mind!  And we have machines with absolute encoders that never need homing.  So we have to be able to cover a wide gambit of machines.

Steve

I'm not complaining.. I do understand what Mach4 is and does (sometimes).. my posts are either questions because there is a lot of documentation and often someone else could have run into the same problem and already knows the solution, or can point me in the correct direction. Or I post the solution I have found so that someone else possibly can use the solution.. or get pointed into the correct direction..
I'm an Electrical and Mechanical Engineer, and I've been doing Industrial Automation for nearly 40 years.. I make no claims to being a high level programmer, though I have written in C, C++, VB, Pascal (everyone laugh), Basic and Assembler.. I did Fortran in college (now everyone laugh harder).. so I do have a basic understanding for coding. So I can guess why something might be happening, but not necessarily know what the solution might be.. I'm normally working on plc's (AB, Siemens, etc.) and data acquisition systems.. I also do lots of motion systems, Robots, servo's, etc.
I agree.. less is probably more.. fewer, and smaller changes to the basic functions of Mach4 are probably better.. I don't expect the developers of Mach4 to make Mach4 work for my application.. that's a ridiculous  concept for the manufacturer of any piece of hardware or software. I do expect them to be able to tell me how their device or s/w works however so I can determine if its appropriate for my application.
I already know that there are certain issues in Mach4.. pressing the STOP or RESET, or ESTOP during a run will absolutely make Mach4 lose position integrity.. you will lose the buffered information between Mach4 and any of the motion controllers.. ESS, Pokeys etc. I know this because I've read the information, contacted the mfg, etc. and they've indicated this.. its not a problem per se as long as you know ahead of time, and can possibly take precautions against it. As I am doing with either operational procedures or really really minimal coding.. keep the impact to the basic functionality of Mach4 as minimal as possible.
My most curious observation is that I've seen many, many, posts concerning getting what I would expect is relatively easy procedures or operations done.. and spending what appears to be an extraordinary amount of time on the problem. And normally during the course of this, I've noticed that someone will bring up that Mach4 is designed to run without major modification.. and then supply pages and pages of scripts that might resolve the issue. As a case in point, there must be dozens and dozens (possibly hundreds) of posts concerning Homing.. and you yourself have indicated to the posters that Mach4 Doesn't do the homing.. only listens for the result.. and they should contact the motion board developers.. knowing this I designed my system (I'm retrofitting 8-10 machines) to do their Homing procedures outside of Mach4 and the motion controller itself.. basic assumption.. don't force Mach4 to do something it wasn't designed for.. I'm not interested that some have spent days, weeks or months, and finally have gotten Mach4 to do something apparently correctly. That's not a solution.. that's the road to more problems.. often ones you least expect or don't expect at all.
And yes, I did expect originally that STOP or RESET, or possibly dropping the ENABLE would close the thread and stop a loop.. I was mistaken.. but that's why I test before applying the modifications to the machine. Its more problematic to live with a self completing WAIT loop as originally implemented in MACH4... then to try and work out a solution for a non terminating WAIT loop. Or possibly determine that MACH4 can't be used for our application.. that's what Engineering is..
and I expect that this is a forum for people to Post problems, solutions and possibly observations.. so that any interested party can make a more educated estimation of what they can and can't do with the product.
and I still believe MACH4 was the correct choice for my application(s)...

and I should add.. this is what I do to make a living (not Mach4, the Automation part of things).. and so I'm charging a customer for my time.. within limits of course.. but once I turn the machine over to them I personally don't run it.. their operators do.. and they aren't engineers, coders or maintenance personnel.. they simply push buttons and make parts.. so the machine(s) better work correctly once I'm done.. and hopefully they never call me again (I've known this client for 20+ years)... so estops, resets, stops or whatever operations I allow them to preform have to either self correct, or work correctly 99.9999% of the time.. I used Servo's as they won't lose position anywhere near as easily as do steppers (I actually hate steppers and NEVER NEVER use them).. my actual Mach4 application would make most if not all of you laugh.. I'm drilling a 0.007" hole (thats correct..0.007") in a part.. then moving over to a 2nd fixture and drilling another hole.. the real issues are operation and positional accuracy.. and oh yes.. I'm interfacing to a robot removing and placing parts into the fixtures.. the fixtures themselves have sensors to detect parts.. clamps to hold the parts.. drill detection sensors (they do break occasionally).. and sometimes the vibratory bowl doesn't feed correctly.. so the robot simply waits.. and in turn the drill better wait.. and I do have home and OT switches.. I wanted to go closed loop but determined that was too much of an impact initially.. I am still debating.. and I also understand the limitation of Step/Dir which is what I'm using.. just in case someone  else doesn't understand.. if you lose your step signal, Mach4 won't know you didn't move.. so yes, you will probably crash one of the other axis.. if you lose your Dir signal.. well you will only move in one direction regardless of what direction you programmed.. so its anyone's guess as to where the machine is and what may happen.. for my machine(s) this is somewhat problematic but not overly dangerous.. you have a gantry machine and are running a 4" cutter at 1000rpm, you may have an issue with all sorts of shrapnel coming out of the machine. So application is a very important component of determining the hardware and/or software you should be using.. not if you can write LUA code to do a tool change (which I also would try to avoid if possible)
just a passing thought..

You are correct.  This forum is a good place to get answers to questions.  I saw you had an issue with your scripts and I posted a solution.  If you have an Industrial license, we also have phone support.  But the solution I gave you, because I honestly wanted to help you out, is sound and it works flawlessly 100% of the time.  I realize not everyone is a programmer (and not everyone is an engineer), so I try and help out when I can.

I'm not going to argue much of anything here.  I just don't want people reading and getting the wrong idea.  My goal is no misconceptions.  So I'm just going to throw out some facts based on a system that I'm intimately familiar with.

1.  If Mach is used with a closed loop system with encoder feedback, Mach will NOT lose position when e-stop is pressed or Cycle Stop is pressed.  This includes closed loop controllers like the Galil, Vital Systems DSPMC, or any Step/Dir controller with encoder feedback used to drive so called "digital" step/dir or position controlled servo drives.  With these motion systems, Mach 4 is no different than a Fanuc.  If anyone tells you something different, they are giving you bad information.  Even if they work for a motion controller company, they may not know exactly how Mach operates.  As the primary developer/programmer for Mach 4, I can promise you that these motion systems do not lose position when e-stop or Stop is pressed.  If I had to home every time I pressed stop or e-stop on my Matsuura (Mach 4 conversion), I would freak out and start sky screaming and probably start throwing rabbits. 

2.  Mach 4 commands the motion controller to home most of the time when the reference button is pressed.  It doesn't care how the system is homed, whether by the motion controller or a motor.  All Mach cares about is "Are the axes homed and if so, what is the position of each with which to to synch the planner."  Home the best way you can.  I think it is cool that the motors have a homing routine. 

3.  With M66, you can specify the timeout with the Q word.  A value of 4294967 seconds can be use in order to make it wait for like 8 years.  Hopefully the operators don't take a lunch that long!    M66 works in the very same manner on Linux CNC, BTW.  So Mach 4 isn't the only device/controller in the world that works like that.  I don't want people getting the idea that M66 is just junk and doesn't do what it is meant to do.  It works exactly as advertised.  M66 does work best with industrial so that conditional G code can be use to check for a timeout.  But failing that, writing your own m166.mcs is good means of not requiring the G code conditional statements. 

And I have an observation that may not be immediately apparent to all that just pop into this forum.  When you first see these forums, all you see are people with problems or questions, real or perceived.  And most likely anyone that comes to these forums has a question of their own.  Sometimes people figure out what they did wrong or need to do and fix it themselves.  Sometimes they found something that genuinely needs fixing in Mach.  But most of the time people that are as spending an a bunch of time to solve a problem are people that want something custom and they need help doing it.  And they are most likely not engineers or programmers.  They understand what they want, but not how to get it.  So they come to the forum for help and the community tries our best to help them.  But it can still take a long while to sole their issue because we are not sitting at their machine.  Also, a lot of times people don't even know the terms to use to ask.  So yeah, there may be a lot of code and examples flying around the forum while everyone is trying to get on the same page.  So what you see on this forum are people needing help.  You do not see the majority of people that don't need help posting on the forum.  The VAST majority of people buy their machines turn key and don't need any help at all.  Then there are people that install Mach and run their machines fine because they don't need anything custom.  Otherwise, we would have to hire thousands of support people.

I'm not going to laugh at .007" holes.  A friend of mine used to make glue dispenser pumps with holes around that size. He made a fortune!     

Steve

thanks for the information.. i haven't tried it as yet but will over the weekend.. and I probably will test the closed loop feature as well.. as I said its one of my main concerns.

and I didn't expect the 0.007" hole itself to be laughable.. (I made aircraft parts years ago on Long Island, NY.. and never drilled anything that small in diameter.)
only that the entire Mach4 operation (motion wise) is to move to a single position (x/y), feed down(z), feed up, move in a single axis(y), feed down, feed up, move to the first position... repeat. Thats a pretty lean Gcode program

and in this particular application whenever the operators stop the machine they always re-home.. they can't restart the drilling cycle in the middle so feed hold is n/g.. while there are places they could do this, it just turned out that they were instructed otherwise to eliminate issues.. the original machines don't lose position but are now obsolete for a number of years and there are basically no spare parts available for the CNC side.

thanks again.. and have a great weekend