We are currently using eNetDNC to upload/download programs, which works great. But we are also attempting to use it for machine monitoring/data collection, which is turning out not so great. We have the eMonitor boards that are hard wired into cycle on/off. We have alot of cycle on/off signals being captured, due to the way the machines are being ran. We are not a high production shop that produces many parts within a shift. Also, we tend to start and stop, sometimes even startover our programs in certain areas to accomplish the machining of a large casting, this is where most of the cycle on/off is coming from.
The problem we are seeing is that cycle off may not mean that the machine is down, as in nonproduction, the operator may be checking the cut, checking tooling, measuring, etc.
We have tested the DPRNT function to try and capture some of this activity, but since we bounce around in the program so much, the DPRNT lines may not be "read". Also, it seems that the only thing that terminates a "cycle on" condition is a "cycle off" condition, according to eNetDNC. So event definitions are worthless using DPRNT if cycle off occurs before the DPRNT line, and if you switch, then the event definition does not terminate the cycle on condition.
Has anyone ever had these types of conditions to deal with?
I was thinking about supplementing eNetDNC by doing something in the machine ladder, or adding an additional small plc to create some intelligence to capture certain conditions. I was thinking maybe some "If........THEN......." statements or something to capture more conditions, then output them to the eMonitor board.
Maybe capturing "single block signal" and "spindle on" in a IF THEN statement to keep a "cycle on" condition true just for the eMonitor board input?
I think everything would be great if we ran parts back to back, running through programs nonstop, but we don't.
Any help on this would be greatly appreciated!