Mach4.. ESS.. anyone have any idea why program would hang randomly? cycle is very short for a mill program.. 45 seconds sometimes less.. motion seems not to be the problem.. if I run only the motion it seems to work correctly.. during the cycle I need to turn on and off several outputs, and read several inputs. When I add the I/O, the Gcode program will hang in different parts randomly. Sometimes after a couple of minutes, sometimes a couple of hours. Worse if I use M99 at the end of the cycle which is how it was normally setup. Better if I use M30 but still problematic. Nothing special about Gcode.. no circular interpolation.. no 3-axis moves. problem is very repeatable and I've been attempting for several weeks now to find a solution. Nothing in the diagnostic logging indicates any problem. No error messages in Mach4.. Its now running on a test bench so no other equipment, heavy machinery, power surges, etc. in vicinity. Just the pc, ESS, M26 relay board and a regulated 24vdc supply. Its not losing communication with the ESS.. its not hooked up to the internet or any other pc's. Same across three different pc's, three ESS boards, three M26 boards. It is not a hardware issue and hard to believe its a Gcode issue with a short nothing program. If I can't resolve I'll need to trash Mach4, all the other h/w and my time at a loss of over $30k. I'm doing this for a client so if it doesn't work I don't get paid!!!! 

I don’t know if this helps but…

Some time back I encountered problems relating to compatibility issues between various Mach4 builds and ESS plugin versions.
The most stable pair was Mach4 build 4809 with ESS v.285 but moving more up to date Mach4 build 5382 with ESS v.309.

Just out of curiosity, which builds are you currently using?

Tweakie.

mach4 4612.. ESS v284... this is the recommended versions I believe.. I'm pretty sure I know what the problem is.. not so sure I can fix.. I've tried a bunch of modifications to my original Gcode.. its somehow may be related to several items.. G04.. M99 and I now believe it may be the way I was implementing the M64 functions.. I was duplicating the Gcode from the original machine line for line.. I am using Mach4 as a retrofit.  At first it appeared that Mach4 didn't like G04's anywhere in the code.. using any G04 caused all issues with hanging on moves, io not synchronized between Mach4 and the ESS. As well it would now hang on one of the G04 lines pretty consistently.. not any specific line.. if I used five G04's, it could hang on any one, and after a random number of cycles. Didn't like the M99 at the end of the program either.. that also seemed to magnify the problems.. I removed all blank lines in the Gcode just in case they were causing a problem of some sort (they were simply there for readability). I've tried a bunch of things but now I've also changed all my M64 coding.. at first I thought it could be that there was no motion command directly after some of the M64's.. so I modified the program and placed one after each. That did not resolve the issue.. so my current test has every M64 in a motion line.. in some cases where I had 2 M64's in a row, I split up my motion on at least one axis and placed every M64 in a motion line.. this appears to be working. Not sure if this was the actual issue. I'm letting this cycle for several hours. If this works I'll go a bit backwards and change my M30 to an M99 and see if the problem resurfaces. Then I'll try adding in a G4 and see if the problem resurfaces. Then I'll add a few blank lines back in. Could be they all played a part or they are fine but magnified in some fashion the M64 problem.
So I'm pretty sure it has something to do with the way Mach4, and/or the ESS, handle motion and io. Probably very few programs have such a short cycle, and have so many io changing states in that period.. could have easily been something that was never tested in that fashion. So either Mach4 and/or the ESS, simply don't handle the API calls and something either overlaps, or causes some low level procedure to exit incorrectly, or not exit at all. Placing the M64 in a motion line, somehow changes the methods of how Mach4 and/or the ESS implement, handle and keep track of what they are doing.
First run after I modified the M64 calls ran for nearly 3 hours without a problem. I'm on the second test run and its been cycling with about 90 minutes without any issue. Hopefully this is the resolution, but I've been working on fixing this for nearly 5 months so  I was pretty frustrated. Its one of those bizarre issues where it could run for anywhere from 2 minutes to an hour or more, and then hang or not synchronize io. You don't usually expect that would be caused by the way you are turning on an output using the canned function that comes with the software. So I was looking at everything else, including the modifications I made to the screens and what I would have thought were minor changes to the screen scripting.
and thanks for the reply.. I do appreciate it.. 

and I try not to change versions unless that version specifically targeted the problem I'm experiencing.. Updating versions is the first line of defense for nearly every s/w manufacturer, and sometimes they force me to change before they will even discuss the problem. And we are talking big companies now such as Rockwell, Siemens, etc. In a couple of cases, upgrading to a newer version actually crashed the entire application and its sometimes difficult, or impossible to go backwards easily.  And in other cases it introduced additional and different issues.
and my application is really really simple.. I move x and y. check that there are parts in two fixtures.. raise a slide.. check if the slide is up.. drill a hole (a really tiny one).. retract the drill partially.. turn on an air blow-off solenoid. Turn on a vac solenoid. Retract the drill out of the hole.. turn off the blow-off and and vac. Move x and y. Check if the drill is still there (there is a drill detection sensor).. move over to the second fixture. Repeat the process as per the first fixture. Move the x axis to a point where the fixture is accessible to the operator. Lower the slide and check if its down. Check to see if the parts have been removed from the fixture. Wait until new parts have been placed into the fixtures. Wait for an input goes high signaling that the plc has completed cycling some other devices. And continue as above. Not exactly rocket science. 

ok... now we get silly... so I thought I had this resolved last nite.. ran twice for 2-3 hours without any issues .. but when I ran it this morning it stopped twice at the same point in the Gcode.. waiting for an input that is turned on by an output.. now this is the exact code that ran last nite.. and Mach4 shows the output as on, while the ESS reports it as off.. its at the end of the program where a number of outputs get turned on or off basically at the same time. So I played around and added in some motion but nothing seemed to help.. so I said its never the Mach4 end thats reporting the incorrect state.. only the ESS.. so you would think that has to be the ESS right? So I did something simply to see if its tied to how the Gcode  and io together are being handled.. so I changed the Gcode to turn on or off outputs that are not pinned to anything on the ESS side.. so they are only signal states in Mach4 .. in the PMC code i connect the Mach4 output to the actual output connected on the ESS.. and I took all the extra moves out of the Gcode and simply did a line for each M64 or M65.. in one place I now have six in a row.. this the way it was at the beginning and never operated correctly as such for very long... and now it seems to operate correctly.. doesn't seem to miss a sync between Mach4 and the ESS, and doesn't seem to hang in any other part of the program. I still need to run it a few more times.. and I also need to determine if I can change back to an M99.. while I can cycle with the M30, that actually turns off the spindle each time. So i would need to separate the spindle control from Mach4 and the ESS. Sorta like a parallel universe where the physical laws of science are different. 

and it definitely doesn't like M99 and G04 either.. after testing what appears to be successfully using an M30 at the end of the program I modified the end and swapped the M30 for an M99.. and placed a G04 P1000 in front of it.. first test ran 4 cycles and then stopped on a motion line... next test ran 7 cycles and stopped on a different motion line... I changed the G04 P1000 to an M66 P12 L3 Q1.0. There is no P12 so it simply waits 1.0s and continues. Ran 27 cycles and hung on a motion line. Changed back to an M30 at the end and once again it appears to be operating correctly. For those who are wondering how an M30 is cycling the machine, when I use the M30, I turn on output 12 in the line above the M30, which is also simply a dummy output not connected to anything. The pmc code looks for output 12 to be high, waits 4s and then issues a cycle start and resets output 12. So it seems Mach4 and/or the ESS, much prefer whatever the M30 is resetting, as opposed to the M99 which I believe is only a return to the beginning of the program. All this non-sense is most likely tied to my very short cycle, and that my motion commands and io commands are nearly 50/50. I may actually have more io commands.  I doubt that either Mach4 or the ESS were tested to do anything like this as its very unusual. The only saving grace was the variety of tools in Mach4 that let me test different scenarios to see what may have worked. Without these I would have been dead in the water fairly quickly.