Production Counting White Paper

 By Rob Anderson of ATSI

Presumably, you are reading this because you are at least thinking about the benefits of installing a production counting system at your facility.  This paper is intended to address the essential parts of a good production counting system. 

A production counting system can be divided into 5 parts.  Each part building on the strength of the previous.  As you will read, I elaborate on the first stage, Data Collection, because I feel that this is the single most important part of the system, do a good job here and the other four sections will be greatly simplified.  Do a poor job here and this counting system may be a never ending job.

1. Data Collection

2. Data Storage

3. Real-time Feedback and Displays

4. Management Reporting

5. Data Analysis

Data Collection.

  A good solid method of data collection is as important to a production counting system as a good foundation is to a house.  With a house, if the foundation isn't "square" you will be forever compensating by adjusting floors, walls, ceilings, windows and doors for the original mistake.  With the counting system, if the data collection method isn't sound, you may lose counts or worse, mis-count.  If the foundation isn't constructed from good materials, i.e., good quality concrete, rebar, block and mortar then the house can sag and cause you problems until the day you sell the house, or it falls down, whichever comes first.  If the counting system isn't constructed from good materials, good quality industrial components using sound engineering practices, like the house, you can have problems for the lifetime of the system.

Method.  By method, I refer to the general architecture of the counting system.  The best method, that I have found, is to use a centralized computer system for storage and computation and a field device like a PLC or dedicated Counter that is physically linked to the real world as shown in the illustration below.  Don't try to bring the counts in directly from the field to the Computer System.  A computer system typically isn't designed to receive the type of real world signals and respond to them in the way that you would want it to.  If someone writes a big file over a network for instance, that may cause a delay in processing some counts, so any reports that you print may "look" wrong to the end user, because counts that should have been recorded, were recorded late due to the file transfer.  Another problem with using the computer system as the data collection device is that when it fails and is down, you won't get any counting information for the downtime period.  Using the PLC or counter method, the counts are still there and can be collected when the computer is back up.

Counts should always be taken from limit switches, photo eyes, proximity switches or other field devices that are necessary for the production line to operate.  Counts should rarely be taken (if ever) from field devices installed for the sole purpose of counting.  The reason is maintenance.  A field device that is necessary for the production line to operate will be maintained, it has to be.  A field device that is only there for counting purposes will get very low priority from the maintenance department, and it may be difficult to prove to them that it isn't functioning properly.

Another good way to get a count is from the output of an already installed PLC or material handling device, like a robot.  If the PLC sends a signal to a conveyor telling it to start running, after it has placed a part onto it, and it sends that same start signal every time it places a part, that might be a good way to get a count for parts out of that machine.  Similarly, other machines have signals that they send to other devices that cause some action to be performed on the part of the device.  In many cases these types of signals are a much better way of counting than a sensor at that location.

Something that must be considered when programming the counting PLC or counter is the length of time the signal sent to it is made and how to condition that signal within the PLC or counter.

• The first thing you must watch for is the signal being too fast.  If the signal is being taken directly from a switch, you must ensure that the signal is in the "ON" state long enough for the PLC to "see" it and react to it.  PLC response time can vary depending upon the type of controller and the size of the program it contains.  By PLC response I mean the rise time of the signal within the PLC and the scan time of the program.  Minimum sensor on time = Rise time of the PLC + 2 scan times + the ON Delay.  We'll cover ON Delay in a minute.  So, the rise time for a given PLC (the time it takes an input to go from 0 to 1 because of internal capacitance) might be 50ms.  The scan time might be about 5ms.  So assuming that you have no ON Delay at all, the sensor must be on a minimum of 60ms.  If it doesn't stay on long enough ( see Figure 3 and Figure 5 ) you might miss a count, so your finished counts would be less than actual.

• The second thing you must be concerned about is how much time your signal is in the "OFF" state between counts.  Minimum sensor off time = Fall time of the PLC + 2 scan times + the OFF Delay.  Using this equation you can be positive that the PLC has "seen" the transition from "ON" to "OFF".  If your signal doesn't remain "OFF" long enough then your PLC might not see that it was ever "OFF" and fail to count the next part ( see Figure 2 above ).  This would result in a count that was lower than actual.

• Another problem that you can encounter is if your signal is sent to the PLC more than once for the same part.  This can happen if for instance, you have a limit switch that "swings".  When the part first contacts the limit switch, the signal is sent to the counting PLC and the signal remains "ON" for some period of time while the part travels under the switch.  At the moment that the limit switch is free from the part, the wand on the switch physically swings back to and through its normal position, and then swings up and "makes" again.  If your PLC happens to read its I/O at this point, then you can get more counts than actual.  The way you fix this problem is by having a debounce time or ON Delay programmed into your PLC or Counter that will allow it to ignore signals that are active for only a small amount of time.  You may also need an OFF Delay which will act like the ON Delay to filter out erroneous signals.  The ON Delay and OFF Delay time for each sensor is usually arrived at by trial and error, but it can be no longer than the amount of time your sensor is "ON" and must be greater than one scan time of the PLC.  As a good starting place try one fourth of the sensor "ON" time.  Look at Figure 1 for an example of how an OFF Delay can filter out a bad signal.

Look at Figure 4 for an example of the perfect counting signal and response.  In the preceding sections I have shown you a few things that you shouldn't do, and I've also given you some formulas for calculating the minimum amount of time your sensor should be on and off.  But remember the longer your sensor is off between counts and the longer your sensor is on while the part is there is better, you don't have to use the minimums.

From a software perspective, counts should always be retrieved as delta values and stored.  So, for example you program the computer system to scan the PLC's once a minute, the computer would poll the PLC for any counts that had occurred since the last polling and then zero out the register(s) in the PLC.  Something you don't want to do is to allow the PLC to count continuously without zeroing.  The computer system can poll the PLC periodically and retrieve the new count, then calculate the difference between the old and the new.  Although, it doesn't seem much harder on the surface, there are hidden pitfalls with this approach.  The simplest method is the best, just zero out the PLC count after reading it.  Store the delta value in a database.

Materials and Installation.  I don't have a whole lot to say about the materials you use.  I have never used anything other than industrial grade equipment and haven't had many problems there.  I do know of a system that used Bar Code readers for data collection on the factory floor.  They used the type of bar code wands that you use to find in retail stores.  The system was plagued with problems, the equipment just wasn't good enough.  Not only did they have their share of normal hardware breakdowns, but also the inspection people entering the information would purposefully damage the equipment, to get out of work.

As far as installation is concerned; if you have been involved with factory floor installations before, just do what you normally do.  If you are from the IT world, make sure your Data Collection equipment is housed in the appropriate Nema enclosure for the job you're doing.  Some sites may require a water tight enclosure, others may suffer from dust, others may need stainless steel.  Do some research on your conditions and take the time and spend the money to use the right enclosure for the job.  Protect your wiring.  You will either want to run conduit or armored cable from the PLC enclosure to the machine.  You will also need to protect your networking cable.  This too should probably be in conduit.  If there is a cable tray leading back to the computer system, then by all means use it, just don't drape your cables from the rafters or leave them exposed for people to swing on.     (TOP)

Data Storage.

 All I can say here is to use a commercial database.  Do not try to write your own code to store data in a user file.  You will suffer from this later.  There are many commercial databases available today that should do the job quite nicely.  MS Access and FoxPro come to mind for smaller systems.  If you need something larger MS SQL Server, Oracle or Sybase are leaders in the field.

When storing the information, store it as deltas.  So, if you are retrieving information once per minute, you should have an entry for every count each minute.  Then when it comes time to print out a report, all you have to do is give the report a time span to look at and summarize.  You may also want to have the ability to create summary data files.  For example a daily file that has hourly entries for every count.  This can be useful later on for displaying or reporting data, it's more efficient.    (TOP)

Real-time Feedback and Displays.

  This is an interesting topic because it can be very minimalistic or all encompassing.  For starters, the basic thing you need will be some sort of operator feedback.  What's the use in keeping counts if you can't tell people what they are.  It's my belief that whether you write your own program or buy someone else's, it should have a few displays to see counts that are "standard", so you can at least look at some counts without needing a custom display.  You should also have the capability of building displays that don't require programming.  You may be able to use the built in display capability of the database that you pick for the job.  This would allow you or someone else within your organization to create and modify a display without the need to hire a programmer to do so.  Many people are familiar with MS Access and FoxPro.

Operator feedback can come in many forms.  You may wish to have an overhead display, continuously displaying a single count for several of your production personnel.  This may be the number of packed boxes from the end of an assembly line.  Or you may wish to have a single light turn on or off to indicate that a quota has been met.

No matter what types of feedback you choose, your counts, I refer to counts as a summary of deltas over a time period, need to be configurable.  The first system I put in was unique for that customer, they wanted hourly, shift and daily counts.  With the shift beginning at a pre-defined time 8am, 4pm and 12am.  This inflexibility later caused problems in the form of added work.  I advise that any system you write or buy should be flexible enough to allow your time period to begin at any time of the day and be any duration, because many manufacturers have some places in their process that don't quite conform to their norm.  For instance, the company I mentioned above had over 99% of their counts based on the hour... but for a couple of unique machines, they needed 30 minute counts, and I remember being asked about a 20 minute count.  So, keep your counting time periods flexible.   (TOP)

Management Reporting.

  Maybe the single most important thing that your counting system will yield is a management production report.  To what extent you choose to report your counts depends upon what you are trying to accomplish.  There are basically two types of reports.  Those used for problem analysis and those used for accounting.

The accounting report is simple.  You're concerned with how much raw material went into your production line and how many parts came out.  This type of report is mainly concerned with line efficiency and material usage.

The problem analysis type of report is usually more detailed.  On this type of report you are concerned with the efficiency of a machine or area.  Generally, you use this report as a tool to tell you how many parts went into a machine and how many good parts came out.  So, for a given time period you can tell how many rejects your machine is producing.  On some machines it's impossible to tell if it's making bad parts because the same number that went in comes out, regardless.  For this type of situation you would usually include this machine in a larger area, maybe two or three machines.  Or, maybe you can add a sensor of some sort that will detect only good pieces and not bad.  You may have to tie it into the machine control system somehow to make the machine dependent upon the switch functioning properly, otherwise you violate the rule about not adding switches just for counting.  In any case, this type of report will usually start at the beginning of a production line or production area and work its way through the area, so that the output of one machine or area is the input of the next, and so on.     (TOP)

Data Analysis.

  I could have covered this topic as either part of the Display section or the Report section, but I have waited until last because I feel that it is a separate way of thinking about counts.

The single most useful tool you can have in analyzing counts is a screen that will trend your counting information over some historical time period.  You can use the trend to see patterns that you would miss by looking at a tabular report or display.  

Similar to a simple trend are some SPC tools like Pareto Charts and Xbar and R charts.  These tools can be useful for operations personnel to spot their own problems.

Sophisticated users may want to use something like Stat Graphics or some other numerical analysis tool.  Which brings us to exporting data.  How you export data is up to you, but as a minimum you should have the ability to export raw data from your database for a variable time period to a comma delimited file.  If you can, exporting to an Excel spreadsheet would be a little nicer, as Excel has the ability to graph your data also.  (TOP)

Summary.  I hope that this paper has helped to educate and not been too tedious to read.  If I am successful, you will not make the same mistakes that I have.  If you should have any questions about production counting, e-mail me below and I will try my best to answer them.  --Rob Anderson

countingquestions@atsi.cc

 Copyright © 2002 ATSI