Machine Monitoring "advanced"

[themetalbarn]

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!

[txcncman]

I would think all you need is to capture the time of M30 (program end). Then match that with actual part count.

Then fire a couple of people and I bet your production numbers go up.

[underthetire]

Ive done it, but on only Mori's.

MORI SEIKI GLOBAL WEB SITE | PRODUCTS | Network

[themetalbarn]

We've got a variety of controls that we're dealing with. We've got Mazak, Fanuc, Siemens, maybe some others. The main one I'm concentrating on right now is a Fanuc 15TA, basically for test purposes. This is the oldest of them all, so if we can do something with this one, the rest may be easier.

I'll have to look into the M30 idea, but we may not finish a part in one shift, if that matters with M30.

I need some more brainstorming here.

[christinandavid]

We have a similar scenario, so I added custom G codes at start and end of pgm to ensure that part was only counted once, and a G code at end of each sequence to check for rework. It does require strict program format to do it this way though...

DP

[themetalbarn]

We have a similar scenario, so I added custom G codes at start and end of pgm to ensure that part was only counted once, and a G code at end of each sequence to check for rework. It does require strict program format to do it this way though...

DP

Can you send me an example of this? or post it?
Thanks

[christinandavid]

At the start of the program, before any processes, we have a g code that saves the cycle start time and initialises all cycle data. It only does this, however, if the 'cycle status flag' macro variable is zero. It ends by setting the flag to 1.

Each process has an N number. Straight after the N number another g code macro will store the start time of that process. Each process has either M0 or M1 at the end. Just in front of this a third g code will save the time of that process into a corresponding macro variable, as well as updating the cycle total. If it is found that the variable was not initially zero, the same time would then be added to the 'cycle rework' macro variable.

At the end of the program a fourth g code increments the part count and sets the flag back to zero. It only does this, however, if the flag was initially set to 1.

That is a simplified version of how I tackled the issue, you may do something similar just to ensure M30/dprnt only happens once for each part. You may prefer to use N and M1 to call macros so that you don't need extra g codes, but I wanted to make sure no mdi operation or off the cuff programs affected the cycle data.

DP

[themetalbarn]

At the start of the program, before any processes, we have a g code that saves the cycle start time and initialises all cycle data. It only does this, however, if the 'cycle status flag' macro variable is zero. It ends by setting the flag to 1.

Each process has an N number. Straight after the N number another g code macro will store the start time of that process. Each process has either M0 or M1 at the end. Just in front of this a third g code will save the time of that process into a corresponding macro variable, as well as updating the cycle total. If it is found that the variable was not initially zero, the same time would then be added to the 'cycle rework' macro variable.

At the end of the program a fourth g code increments the part count and sets the flag back to zero. It only does this, however, if the flag was initially set to 1.

That is a simplified version of how I tackled the issue, you may do something similar just to ensure M30/dprnt only happens once for each part. You may prefer to use N and M1 to call macros so that you don't need extra g codes, but I wanted to make sure no mdi operation or off the cuff programs affected the cycle data.

DP

Thanks for the detailed information. Looks like this would be a pretty good solution, but we do not have macro capability on all the machines. Looks like the challenge is steering more towards monitoring outputs from the plc/pmc.
Thanks again.

[gm3211]

I think your on the right track and really need to wire in multiple points from the PLC to the system to captured the desired results. I would generally recommend, cycle light, spindle, axis movement as "spindle time". Single block, cycle and spindle could be something different, just "cycle time". Most systems only capture one type of time.

The combo of Emonitor boards and Macros could be a good thing but tedious to maintain.

Ideally with the other controls, if they have MT Connect, Focus, OPC they can spell this out pretty clearly and with some solutions you can update the PMC with a value to lock status for operators to tell you want is happening with downtime reason.

How many I/Os do you have on the Emonitor boards? Is this something off the shelf you can modify the ladder on and do the IF/THEN you suggest?

[guypb]

We've got a variety of controls that we're dealing with. We've got Mazak, Fanuc, Siemens, maybe some others. The main one I'm concentrating on right now is a Fanuc 15TA, basically for test purposes. This is the oldest of them all, so if we can do something with this one, the rest may be easier.

I'll have to look into the M30 idea, but we may not finish a part in one shift, if that matters with M30.

I need some more brainstorming here.

What controls do you have? We can monitor some Siemens, Mazaks and Fanucs through the Ethernet port and give a load of information that is unambiguous including Feed Rates turned down etc.. It does depend on age. My advice for the older controls, accept the limitations - you will spend a lot of time and effort and frustration trying to eek out every signal from them. DPRNT & data acquisition modules work but can be time consuming to add. If your Mazaks are Fusion / Matrix, your Siemens is 840D (PCU50) and your Fanuc an i Series with FOCAS we just install some software, plug in a cable and away you go... no major program changes or signal finding required.