Collecting Machine Data

There are three things you will need to know about a production machine:

  1. What is it doing?
  2. Why?
  3. How much has it produced?

Any production machine should be able to give you this information at anytime, but let’s break this down a little more.

 

What is it doing?

This means what “state” is the machine in. Typically there are four basic states that a machine can tell you about itself:

  • Stopped — due to a fault
  • Running — or available to run
  • Starved — it could run, but needs material
  • Blocked — it could run, but it cannot because its output is full

There are other states the machine can be in — out of production, being cleaned, etc — but in most cases these are dependent on human decisions in the wider context, so the machine cannot identify them reliably.

Why?

If the machine is stopped due to a fault, you will want to know what is the cause. Remember that at any given time there may be several different faults, some more important than others.

How much has it produced?

How a question this simple can cause such confusion always amazes me.  At the least you want to be able to count how many units the machine produced. I have  yet to find a machine that doesn’t have a proxy for this somewhere. It is best if you can get both inputs and outputs, so you can report yield as well, and help the quality as well as production departments.

Reject counts are of surprisingly little use, they tell you what came out the official reject chute, but not about the unit an Operator picked off the conveyor.

Some suggestions about the format of the counts. It is best to count over a reasonable period — units per minute / units per 10 second period, depending on the speed of the machine. This gives good data while minimizing transactions. Next best is just a pulse, tick or flag every unit — at least then you can aggregate them into counts whatever way you want.

Least useful is a cumulative count which can be reset by the Operator. Why is this the worst? Because any software using this count doesn’t know when or why the Operator has reset. Unfortunately, when asked if their machine can provide a through output count, this is what every single machine builder I have every met proudly points me to. It is possible to reverse-engineer useful data out of this type of count, but very annoying!

With this simple set of information, if you are buying a new machine you can specify to the builder a robust set of performance data, and if you have a legacy machine you need to manage, you can still get a satisfyingly complete picture of what is happening inside it!

Cheers,

Leave a Comment