Data Overload

Over ten years ago, I was asked to explain how I was using data to improve results.  How do I think about what is important and where should one start?  The presentation I developed is pasted below:

One of the main reasons for this presentation was the concept of data overload. A number of my peers were questioning the value of differing types of data, and the approaches that had been taken in a number of plants. My goal was to clarify what was important and share results from using data in the way I recommended.

Enjoy! And as always, your feedback is appreciated.

Posted in stops | Tagged , , , , , , , , , | Leave a comment

The Machine Cycle

In many modern manufacturing improvement systems the Machine Cycle Chart is a key ingredient in helping the operation understand how equipment works.  The idea is this: every machine or process runs in some sort of cycle.  In some equipment this is fairly straightforward, as you can see a series of steps that a machine goes through to perform its function.  Others take a little more inference to decipher, and a few take some creativity to illustrate.  My observation is that most people are first asked to make a Machine Cycle Chart, their efforts are very superficial.  They capture the big things that happen and then put a checkmark on the list that they have completed the task and move on to the next task in the improvement process.  Most people I’ve worked with don’t see much value in the Machine Cycle Chart, because they don’t dig in deep enough.  It is one thing to see things happening, but quite another to be able to explain why they happen.  The “why” is what makes the Machine Cycle Chart powerful.

In continuous processes where a product is transformed by flowing in some way through a processing mechanism, it sometimes is hard to discern a machine cycle.  I’ve found two ways to view the cycle to consider that can be of help.  The first way is to look at process as it controlled overall, the start-up, the transition to steady state, steady state operation, process upsets and recovery, and process shutdowns.  Illustrating these can help explain how well the system is designed to respond to abnormalities and the ways it tries to remain stable.  The second way to think of a machine cycle is to consider the process through the vantage point of the product being processed as it goes through each transformation.  Some projects I’ve worked have developed Process Transformation Diagrams that illustrate what is required for the product to be produced at acceptable quality.  Often there can be important equipment conditions that must also be considered for the process to be maintained that you should add for your Machine Cycle Chart.

In equipment that makes discrete products, the machine cycle generally follows one of two principles, either event-based intermittent motion, or continuous 360 degree rotating motion.  Some machines are a combination of the two, which make it even more interesting.  Add to this that much of what happens in a machine is the result of electrical sensing inputs, mechanical motion, and potentially pneumatic or product flows, you start to see that things may be more complex than you first think.  And finally, recognize that some things work on a delayed basis- when an electrical system tells something to move, it takes time for motion to begin and for the motion to be completed.  So the idea that you just observe what happens, draw it out, and you now understand is a little naïve.  A basic cycle chart is not bad and shouldn’t be discounted completely as I’ve seen many problems solved by people who needed to put just a little observation into a process to understand it and improve it.  However, once the low-hanging fruit has been picked and problems still remain, I’m often asked to help dig deeper.

So what should a Machine Cycle Chart look like?  For most situations, the engineer in me likes to make a timing chart style diagram.  I find it to be precise and a good way to illustrate relationships between various parts of the equipment that interact with each other and with the product.  While I find this the most helpful, I’ve seen that many operators have a difficult time comprehending a diagram like this and prefer a simplified block diagram.  However, if detailed interactions are lost in simplification, I think the whole point of the diagram is lost.  So if the issue is explaining interactions, the next form I use is to draw a cartoon picture of the process in Powerpoint and make it move through the various points of the cycle, but that’s another discussion completely.

Let’s look at an example of a box erector.  This particular machine separates a blank from a magazine and opens it, while a second box is being folded and discharged.  There are nine steps in total.  The first chart I saw drawn for this machine showed nine blocks linked together.  In looking at the PLC program, it isn’t clear that one box starts being erected before its predecessor is finished.  But once you see the steps and watch the machine, you realize that the machine has to pay attention to both boxes and their interactions to get the most out of the equipment.  In addition, this machine has the ability to “pause” during the cycle when the discharge of the erector is blocked by boxes.  It is important to note when this happens in the cycle- the most stable condition of the process where both boxes are fully under control.

This machine is event-driven.  Each step starts when a sensor detects that the previous step is completed.  A cheaper alternative would be to assume that a motion occurs after an output is turned on or off, based on time.  Spending a little extra to verify that each step is completed brings several benefits.  First, you take as long as it takes for a movement to occur and no more.  Second, as components wear or material varies the time can slow but still make good quality.  Third, if a jam occurs and the motion isn’t completed in a timely fashion, the equipment can be stopped before any more damage to the product or the equipment occurs.  In addition, a nice side benefit is that you time each step of the cycle, as described in my article on Trap Timers.

I originally made this chart into a spreadsheet well over 10 years ago.  I was interested in making the machine run more consistently with less stops, yet have a higher cycle rate.  Over time I added details- the inputs that are sensed at each step, the condition of each solenoid valve at each step, a total listing of all inputs and outputs.  The machine is simple enough that this chart can tell someone looking at it almost everything about how the PLC program functions, even if the person looking at the diagram knows almost nothing about electrical systems.  For the programmer or troubleshooter, every device on the machine is accounted for with the basic uses of it for logic.  You could write a PLC program for the normal cycle using just this diagram.

I’ve also used this machine cycle chart to study the cycle and improve it.  When the erector came from the factory, step 4 didn’t occur until after step 9 was complete.  It wasn’t obvious at first, but as we watched the machine, we realized that we could open the first box as soon as the second box was out of the way and didn’t have to wait until the pusher returned home that pushed the second box out.  We changed step 3 to exclude the pusher being home as part of its completion.  After checking all the various inputs and outputs, we were able to change the program to start step 4 right after the revised step 3 was complete.  This saved about a half second on a four second cycle, over a 10% improvement in throughput without speeding up any motion.

The erector example is relatively simple in that all motion occurs by air cylinders and verified with sensors.  The next example is from a coffee espresso pod maker.  In this machine, one piece of paper is formed into a mould and then filled with a dose of coffee that pressed in tightly.  A top sheet of paper seals in the coffee and the pod is cut out from the web and transferred to a packaging station.

This machine is a combination of continuous mechanical motion from a drive shaft and a number of discrete intermittent motions driven from position settings linked to an encoder on the drive shaft.  The first Machine Cycle Chart was done by a controls contractor who draw out the pneumatic part of the chart, based on when things were turned on and off.  The operation was experiencing a number of “crashes” or incidents where the machine bound up mechanically, sometimes damaging parts of the machine.  The machine’s 360 degree cycle is about 1 second, so everything moves faster than you can see.  One of my co-workers tried to use high speed video to capture more detail to understand what was happening, but he couldn’t position the camera and light it in a way that provided images that were helpful.

Additionally, one of the mechanical motions, the chain that held the moulds, was made intermittent by an oscillating gearbox that had internal cams to pause motion for part of the cycle and move in others.  All the mechanical motions of the machine could be adjusted in relation to the others by loosening and moving the connecting parts of the drive system.

I decided that we needed to better understand all the mechanical motions and also determine how they were related to the postion settings from the encoder.  I downloaded a spec sheet from the gearbox vendor to get a good understanding of the motion profile as well as to understand how the input and output shafts were designed to start from a home position.  Using each mechanical connection, the gearbox motion profile and the output of the encoder, I was able to determine exactly how many degrees each action took place in relation to the others and then put it together with the position settings from the encoder.  I added buffers for motion that took time to happen from when the encoder signal was given until the motion was complete.  When I put it all together, I was able to see places in the cycle that were high risk for problems.  With the research I had done, I was able to adjust the mechanical interactions to avoid conflicts and then change position settings to the safest spot in the cycle for best quality performance.

I re-drew the Machine Cycle Chart and explained it to the operators, so they could see the impact of any changes they made.  I also made a series of lessons on how to mechanically set each component in relation to the drive shaft and to each other, taking pictures to explain items that were hard to comprehend.  Finally, I decided that the best way to teach people about how the machine operated was to make a Powerpoint movie of key points in the motion, as a moving picture is much easier to understand than a cycle chart.  With the Powerpoint presentation, I was able to show operators exactly what the concepts were with the machine and relate it back to the Machine Cycle Chart.  Then operators could understand the importance of inspections and proper set-up of each component whenever there was a question.  The number of problems on the line decreased substantially and major machine breakdowns from improper adjustment were virtually eliminated.  We even made progress on eliminated a source of contamination.  But, I’ll leave that discussion for a future article on Using a Powerpoint Movie to Explain the Machine Cylcle.

My final example of a Machine Cycle Chart is from a tray erector that was giving us some problems after it was purchased and installed.  This tray erector made trays with triangular corner posts for bearing heavy loads.  To make these corner posts, a number of folds were required with glued joints.  The machine put out a tray every 4 seconds and all of the folding and compression occurred in a period of about one second, with so many motions so fast that you could watch for an hour and not catch exactly what was going on. 

Similar to the first example, more than one tray could be being made at one time.  In fact, depending on the circumstances, one, two, or three trays could be in process at any given time.  As I studied the cycle, I realized that each tray required some air flow, and that the trays being made at the same time could alter air pressure at the line and cause the machine to perform differently when trays were back to back compared to a single tray.  In fact, as I timed out all the motions, I found that glue heads for tray 2 were operating at essentially the same time as air operated folders were moving to fold tray 3.  Both used compressed air.  Air pressure noticeably dropped when two trays were in these positions, compared to times when only one was in one of these spots.  As it happened, the machine was running twice as fast as the line required, so I was able to change the logic, so that the machine picked a tray to glue and fold every other cycle, which made the machine run much more consistently.

Similar to the second example, this machine was a combination of a continuously running drive shaft and several intermittent pneumatic folders that are driven off of timers triggered as mechanical parts pass proximity switches.  The main actions of the machine are a long horizontal drag chain that pushes flat blanks under glue heads at a constant speed to allow a pattern to be put on the card board from 10 different glue nozzles.  The box is then positioned under a horizontal ram which drives the blank down through a series of passive and active folders.  As I tried to optimize the cycle, I realized that the relationship between the mechanically driven parts and the pneumatically driven components were not as simple as they appear.

Since cycle time is short, short delays in motion are critical to understand.  Using high speed video, I was able to determine exactly how long it took for the pneumatic cylinders to fold.  However, it took more effort to see how long the delay was from when a solenoid valve was turned on electrically until motion began.  It takes time for a solenoid valve to slide from one position to another and for air to enter one line and exhaust from another.  Movement can’t begin until the pressure is greater in the side of the cylinder that needs to be pushed than on the side being exhausted by a difference enough to overcome friction in the cylinder and the mechanical components attached to the cylinder.  Normally, in most applications this time is insignificant.  But on this machine, some of the cylinders had several feet of tubing between them and the solenoid valve controlling them.  This tubing had to be filled with air and then drained each cycle, which takes time.  I considered trying to model the pressure changes over time, but I decided that there were too many diameter changes in the system that would act as flow restricting orifices to effectively calculate how much air would flow through the system at any point in time using calculus and the laws of physics.  Instead, I decided to use more observation through high speed video.

Before going further, I should point out that this machine did not have sensors to detect when a motion was complete, so unlike the tray erector example, I couldn’t just trap times.  Installing sensors was cost prohibitive for this machine, and some places didn’t lend themselves to getting sensors in a position that would be effective.  As a result, this machine was not totally event driven, but was driven based on the assumption that needed motions were taking place.

To determine the delays involved, I noted the position in videos of the tray being rammed through the forming section in comparison to the motions I observed.  I then modeled the motion of the tray based on a sinusoidal motion profile that occurred from the rotary motion of the drive to the ram mandrel.  I was able to calculate where the tray was in relation to the timers that were turning on the pneumatic solenoids.  I found that two of the folders had delays of around 0.2 seconds before motion began, an amount approximately the same as it took to move the cylinder.  I have illustrated this in the Machine Cycle Chart and on the settings page of the operator interface.

With an understanding of the machine cycle, I was able to define what the best settings were for the most robust folding in the machine.  I was also able to take the various relationships and make a CADD model of the machines various motions.  By doing this, I was able to identify a number of points of instability in the folding process that allowed us to make small modification and greatly improve the consistency of the machine.  I made a Powerpoint Movie of the cycle to be able to explain what I learned to the operation, so they could keep the machine in optimal condition and know what happens when it varies.

Machine Cycle Charts may not be a solution for every problem, but I have found that they are a great starting point.  The exercise of digging in to how a machine actually works is an investment that will pay dividends for years to come.  The better you understand the theory behind how a machine runs, the easier it is to solve problems and make improvements.  In other articles, I’ll expand on how I’ve moved forward using the Machine Cycle Chart as a foundation to build on.

So, next time you are asked to produce or review a Machine Cycle Chart, put the effort in that it deserves.  This item is far more than just one of many on an improvement process checklist.

Posted in timing | 1 Comment

The Powerpoint Movie- Part 1

Have you ever tried to explain a simple concept to someone about how something changes over time, but the other person couldn’t grasp what you were saying?  How about drawing a sketch and trying to show how something moves?  What if the person you are trying to explain something to is half-way across the country and can’t see what you are talking about?  For some of these situations, I’ve found a technique I call the Powerpoint Movie.

I like Microsoft Powerpoint for lots of things, but mainly I like it because it is simple to use- at least for the things I need it for.  I’ve become especially fond of the basic drawing capabilities that are part of Powerpoint.  You can make very colorful sketches in a short period of time, and then put them into a slideshow to explain concepts in a short amount of time.  When you make sketches in Powerpoint, you can move individual objects, group them, copy them, ungroup them and do any number of other manipulations.  Powerpoint isn’t AutoCAD, but it’s great for sketching simple concepts.

More than anything, Microsoft Powerpoint is a slideshow.  Most of the time people make slides and click through them when they are giving presentations to a group.  But, with a few clicks of the Set Up Show located in the Slide Show menu (your version of Powerpoint may vary), you can set up a slide show that starts automatically, advances through slides and loops around and starts over.  For most people, this isn’t news, but for showing a moving visual concept, it is very powerful.

If you combine the graphic capability with the automated slideshow, you can get a Powerpoint Movie.  What am I talking about?  Well, sketch out a machine, a layout, or something else that moves onto a slide in its initial position on slide 1.  Next, copy slide 1 and paste a copy in slide 2.  Now, highlight the objects that move and drag them or use arrow keys to move them into the spot they need to be in for the next step in motion.  When you have slide 2 the way you want it, copy it and paste it into slide 3.  Keep going until you have completed a cycle of whatever motion you are trying to illustrate.

Take a look at the following examples:

The top slideshow shows a manual packing system that was proposed by a design firm I was working with.  I thought there were problems, but couldn’t really explain it over the phone.  I had a different layout in mind that I thought would be more ergonomic, but just drawing the layout didn’t really explain why it would be better.  So I made sketches of each and moved the objects around to make an animated Powerpoint movie of each concept. 

The top concept has issues with how the boxes are handled with potential for jams.  The packers are moving and twisting, plus the boxes they are filling are against each other in a constrained space.  The two are separated and can’t really help each other if there is a problem with the equipment in their area.

The bottom concept shows a smoother flow of boxes.  The packers have everything right in front of them.  If there is a problem upstream or downstream, either packer can move to the problem.  Things just move smoother.

Both slideshows have 10 slides to represent packing 5 bags into a box, and run at 1 second per slide which is close to what the planned line was to run.  They are timed the same so viewers can quickly see a fair comparison.  The design team was able to  debate the merits of each system and determine which idea is best- or maybe come up with something even better now that we can envision what the impact of layout is to the work being done.

Webpage note:  I had to do a few tricks to make this show on a web page, so you aren’t seeing a Powerpoint file.  If you don’t have Flash, you may not be able to see the embedded show.  I had to save the slides as individual pictures and use a Flash-based picture slideshow to show the slides automatically on this page.  If you want to do something similar, I used a Plug-in called Nextgen Gallery, along with JW Imagerotator.  If there is interest, I’ll write up a separate step by step procedure on how to implement this, as getting a slide show to automatically display and loop was much more difficult to achieve than I expected when I started the process of writing this post.  I tested a number of ways to do this, and this method was the easiest I found.  If you have a better, easier way, leave a comment below.

If you have trouble viewing the Flash version of the Slideshow, you can also download and/or save the actual Powerpoint Files: File#1, File#2

While you may find that there are other ways to do this type of thing, I have found this simple method to be very powerful in explaining concepts that aren’t easy to grasp.  With practice, you can whip these types of Powerpoint Movies up in no time at all.  In Part 2 & Part 3, we’ll take this concept a little further with some other uses of the Powerpoint movie that are a little more “data-driven.”

As always, your feedback is always welcomed with a comment below.

Posted in sharing | 1 Comment

Trap Time to Optimze Speed

One simple programming technique I like to use in PLC logic is what I call the “trap timer.”  Maybe there’s a better name, but I’ve often written code for various reasons to “trap” issues- saving a key piece of information for further review when some event occurs.  Such is the nature of this technique, although I use it to continuously collect information for analysis.  I’ve used this for years, but people always seem surprised when I show them how to do this- both at the simplicity of the logic, and its usefulness.  Maybe there are some logic languages that have this function built in, but I haven’t come across this in the brands of processors I’ve worked with.  I’ve used the same basic methodology in other types of processors with different types of logic, but the concept is always the same.  The goal is to time an action and remember the total time at the end of the action.

In many pieces of equipment or processes, timing is critical.  In situations where a cycle proceeds step by step, waiting for a process to change in each step, whether it be a motion, a temperature, a pressure, a mixture, or some other attribute to change states, the time required is often a critical variable.  Sometimes alarms occur when the change happens to slowly or too quickly, but rarely do operations measure and track the time it took for a change to occur.

Take a simple box erector.  A box is separated from a stack, picked away, opened, has minor flaps folded, then major flaps folded, and then is pushed through a sealer to complete the process.  In one machine I’ve dealt with, there are 9 discrete steps.  Each step must be completed before the next one begins.  The cycle time is the sum of the times for each step.  If the erector slows down, it might not keep up with the rest of the line.  How does an operator know what is keeping his/her machine from keeping up?  My solution is to develop a timing display that shows the operator exactly how long each step is taking.  Then the operator and maintenance can determine what intervention to make to get timing corrected.  For this to work, however, we need to have times to display.  This is where the trap timer comes into play.

For a trap timer to work, you must be able to know when an operation begins and when it finishes.  For example, we turn on a solenoid valve that supplies air to a cylinder.  The valve stays on until a limit switch changes state.  The operation we are watching is the amount of time the solenoid valve is turned on.  See the ladder logic example below. 

PLC logic for a Trap Timer

If you aren’t familiar with this type of notation, here is a brief explanation.  The timer in the initial rung is a “Timer On-Delay” or TON.  It is normally used for delaying actions after a condition has been present for a pre-set amount of time.  The pre-set time is contained in the register .PRE.  When the condition that enables the timer is true, then the timer accumulates time in the .ACC register.  The enabling condition for the timer is shown through the /EN bit.  When the accumulated time (.ACC) reaches the pre-set value (.PRE), then the timer is done timing, turning on the /DN bit for the timer.  Whenever the enabling condition (/EN) becomes false, the accumulated value (.ACC) is reset to zero and the done attribute (/DN) is turned off, regardless of whether the pre-set value (.PRE) has been reached.  There are many variations of timer types and ways to represent them in different processors, but the basic Timer On-Delay (TON) is by far the most common in industrial controls, which is one reason I choose to use it.

 In the initial rung (rung 1 in the example), a timer (T51:2) is enabled when the injector valve is on.  The time base of 0.01 means the timer is counting in hundredths of a second, so the pre-set of 500 is actually 5 seconds.  I chose this because I expect this action to take well under a second to complete and 5 seconds is a time that should never occur, unless something is terribly wrong.  In many situations I have worked with, the timer is being used as an alarm- if it enabled until the timer is done, then the process has a problem and the operator needs to attend to it.  If that is the case, the timer can serve two purposes.  The first rung can be the timer, which is also monitoring for an alarm, and the next two rungs trap the length of time it takes for the activity to occur the vast majority of times when an alarm doesn’t occur.

For those not familiar with PLC ladder logic, the processor executes commands in the ladder from top to bottom, one rung at a time.  When all the rungs have been scanned and executed, changes in outputs are made in the physical terminals and changes in input values from the physical terminals are put into the processors memory and the next program scan is started.  The total time for a scan on modern PLCs are often around a millisecond or less, so a timer that is timing in hundredths of a second may go through 10 or more program scans before increasing the accumulated value.  Older processors may have scan times of several milliseconds, depending the size of the program.  For our example, consider that the logic in the ladder is executing hundreds of times per second, over and over again.

The second rung (rung 2 in the example) uses a move command (MOV) to move (actually copy) the accumulated value of the timer into a storage integer (N50:22).  (The N in the address stands for iNteger- I know, integer starts with an I, but I is reserved for Input.)  This move happens only when the timer is enabled, but happens every program scan of the processor when the timer is enabled.  The accumulated value in the timer (.ACC) is not changed by the move command as it really moves just a copy of the value, and continues to accumulate time while the timer is enabled.  When the timer is no longer enabled, no move occurs and the stored value remains the same, while the accumulated value (.ACC) of the timer is reset to zero.

The last rung shown (rung 3 in the example) also uses a move (MOV) command.  This rung is true only once in the cycle, the first scan when the timer is no longer enabled.  Once the activity we have been timing is completed, the temporary value (that we stored in a previous scan in the middle rung) is moved/copied to a final storage location (N50:2) for future use.  This is the value we are interested in, and it will stay in this location until another cycle of the activity we are timing occurs.  While the next cycle is occurring, the value of the previous cycle remains in the final storage location.  Only when the cycle is complete does the value change.

Let’s review what physically is happening as this trap timer logic occurs.  In our example, elsewhere in the logic, it is determined that the Injector Valve should turn on.  When this occurs, the initial rung becomes true and the timer is enabled and starts timing.  As the injector is moving to its destination, time accumulates in the .ACC register of the timer, and the temporary storage integer location (N50:22) has the same value immediately moved/copied to it.  The final value contains the last cycles time of 31 hundredths of a second.  After 29 hundredths of a second, the injector physically triggers a limit switch.  The logic then turns off the output (O:3/2) to the injector valve.  Since the enabling condition to the timer is now false, the timer is no longer enabled and the accumulated value (.ACC) is reset to zero.  In the middle rung, nothing happens this scan because the enabling condition (the timer being enabled) is false, so the accumulated value is not moved and the stored value (N50:22) remains at 29.  Now, the final rung is true, as the timer is not enabled and this is the first scan that it is not.  The stored value of 29 is moved to the final value location (N50:2) with a value of 29 replacing the 31 from the last injector cycle.  In future scans, nothing happens on any of the rungs as all are false, until the next time the injector valve is turned on.

The end result of this logic is that the stored value location (N50:2) always contains the timed value of last completed action.


So what?  What do I do with a trap timer?

As with many nifty programming techniques I use for data collection, the power isn’t in the programming, it’s in what is done with the data that emerges.  I use trap timers for all kinds of analysis.  Here’s a few ways to put them to work.

  1. Display- maybe you have one critical item that is event driven on your machine or process.  Getting cycle time right is critical.  Just display the end result of the trap timer on a display for your operators or maintenance team.  The workers can then act to adjust timing and see immediately the impact of their changes.

If the process is a series of events, then time each event and make a display with each event’s time listed.  I do this on many pieces of equipment where many events are required to complete a machine cycle.  Below is a display example of the box erector from the logic above.

 Timing Display from HMI

  1. Set warning limits or alarms for timed values that are too fast or two slow.  Often just displaying a time isn’t enough information.  People need a context for the data for it to be useful.  Most displays allow you to set alarm limits for values that are too high or too low.  You can then trigger alarms on the display, or color code a time so workers know when to pay attention to a value.  For example, if a motion should take 1.5 seconds, but you know that a time faster than 1.2 seconds will damage the equipment, while a time greater than 1.8 seconds will prevent the process from making rate, you may set a low warning alarm at 1.3 seconds and a high warning alarm at 1.7 seconds. 

In the example above, note the time for jaws open is red (too fast), while the head down time and total are blue (too slow). These colors come from alarm limits in the display and display color choices picked when making the display screen.

Years ago, I asked a programmer for an equipment vendor during a design review to put in trap timers and build a display screen like this one for a machine they were building.  It probably took me 30 minutes of conversation to convince him to do it, as he saw it as a lot of work, but since I was the customer he agreed.  When I came back a few months later for our factory acceptance test, he pulled me aside and told me how much help the screen had been for the other designers in lining out the equipment.  The machine had many motions that had to be completed before the next motion could happen.  By timing each one, the designers had been able to see which motions were the biggest contributors to the overall cycle.  They changed a few components to speed up the slowest moves, and as testing continued, they spotted changes in times that indicated premature wear, which allowed them to make other changes.  The programmer said he would never make another indexing machine without this valuable tool.  When the plant installed the line, the operators monitored this timing screen constantly to keep the line at rate.  

  1. Develop centerline settings for each production set-up.  Maybe you have different products that require different timing.  Once you know the optimal settings for each motion for each product, you can dial it in my adjusting motions and seeing the impact on the operational display. 
  2. Store timed values in a historian database for trending and later review.  Almost any data equipment generates is good to historize for future reference.  That is particularly true with trap timer values.  Like a lot of data, I store this information just in case I need it.  Why would I need it you ask?  Well, when people come to me and tell me that there is a problem with a piece of equipment not running fast enough and that it has been that way for a long time, I can pull up data and see when the problem actually started.  Has it changed gradually?  Did it happen at a specific point in time?  If so, what else happened then?  Maybe someone changed a part and didn’t get the settings adjusted correctly.  Maybe a material supplier made a change.  Maybe a part is worn and needs replaced.  The trend of historical data often helps determine what happened.

Look at the example below of a trend from a historical database.  Before 8:30, the jaws were opening in about 0.62 seconds.  After 8:30, the jaws took around 0.73 seconds.  At three different times, the jaws took much longer to open, including a highlighted event at 12:19 that took 0.79 seconds.  What does this tell us?  Obviously, something changed at 8:30.  Did someone change a flow control?  Did something break?  The later spikes are likely unique issues with materials- a box with excess glue that didn’t open cleanly.

 Active Factory Trend Image of Trap timer values

  1. Do statistical analysis on the data to determine more about the situation.  If times vary from cycle to cycle, maybe it helps to average the data to give workers a better sense of how a process is performing over a longer period.  One easy way is to use an Exponentially Weighted Moving Average, a calculation that constantly recalculates without storing much data.  I’ll cover the benefits and details of that method and other similar statistical calculations in another posting, but think of averaging as a way to eliminate the noise of variation.

Speaking of variation, calculating standard deviation of a period of data can be helpful to compare to other periods of time.  Why?  Consider the fact the many equipment components don’t fail all at once, they slowly wear over time.  Pneumatic components- solenoids, air cylinders, and the like have wear patterns that are particularly hard to detect.  As seals wear, parts stick ever so much more as time passes.  Motion takes longer, but more importantly motion varies more.  If you measure this variation and look for increased variation, over time you can detect when a component is starting to fail way before it is noticeable by the naked eye.  It’s a subtle, but very powerful predictor that you can use in a structured Predictive Maintenance program.  Take baseline data when the parts are new and then sample the data periodically to sense changes.  With time, you’ll learn when variation increases enough to impact the performance of your process and be able to schedule replacement on a planned basis before performance is sacrificed.


 These are five things I commonly use trap timers for and you may have many others.  It all starts with collecting a simple piece of information that can be trapped in a few rungs of logic.  This isn’t hard, but by now I hope you can see the power of this simple technique.

Sometimes, the logic of an event isn’t as predictable.  Maybe there is bounce in the motion that causes double flagging of a sensor.  Or maybe you want to exclude times when equipment jams or delays and doesn’t work as planned.  In these cases, limiting the values allowed to move into the permanent storage register keeps errant data from being stored. 

Take a look at the example below.  Say you have an event that normally takes 2.5 seconds and if isn’t complete in 5 seconds a fault occurs.  Also, the logic for the timer comes true for a split second during the normally idle portion of the cycle.  You decide that you want to know how often the event is faulting out for too long of time, but you don’t want to get a nuisance 0.05 time right after the correct time of 2.5 seconds every cycle.  By inserting a comparison condition in the logic, in this case a greater than comparison requiring the time to be at least 0.10 seconds to be moved, only longer times are trapped, and shorter false events are ignored.

limit logic for a trap timer 

There are many other special circumstances that may cause you to alter the logic slightly.  You can shorten the logic on many processors by combining two of the rungs.  In processors that don’t use ladder logic, you have to do the same type of logic in the language available.  The concept is always the same- trap the time it takes for an event to occur and save it in a location to access for further reference.  I’ve used this technique in many ways over the past few decades and find it one of my go-to techniques in many situations.

Share your success stories with this technique in the comment section below.  Happy trapping!

Posted in timing | Leave a comment

Getting Started with Stops

I recently had a former co-worker stop by my office with a question.  He had transferred away to a new assignment at another factory in our company.  His new factory had a lot of older equipment, mostly hard-wired control and very little communication capability with the control systems.  The plant had started using a Line Event Data System to gather data about production, but since there was no communication to the equipment, all data was being input by operators.  The operators weren’t very accurate in writing all events down or in how they timed what happened, so the resulting data was of little use.  My co-worker’s question was, “What would I do first to collect data from this equipment, given a small budget and low technical skills to install anything at the site?”

 My co-worker explained that the food line in question was a large jar packing line with many operations involved.  The jars were depalletized, cleaned, filled, pasteurized, labeled, packed into cases, and palletized.  There was a lot of accumulation conveyor between the operations as well.  He thought that maybe installing a photo-eye on the either side of the filler would be a good place to start.

 “Well,” I said, “the filler is probably a good place to start, as that is likely the constraint of the line.  Is that correct?”  He explained that yes, the filler was the critical operation of the line and that the rest of the line was set up to keep it fed and to take away filled jars fast enough to avoid shutting down the filler.  Most lines have a constraint, or bottleneck, generally the most complex and expensive part of the line, and if designed right, the slowest.  In the simplest of logic, you can assume that if the constraint is stopped, the line is down, as the time down cannot be made up.  Other parts of the line can go up and down, but as long as the constraint is not impacted, the line is still producing product.

 “Now,” I continued, “tell me how you want to use photo eyes to collect data.”  He explained that if there were jars passing by, then the filler was running.  I told him that with the right logic, that would be true, and that an additional benefit would be that if the photo eye sensor were put in the right place where there was always a gap between products, an accurate count could be made of product, which could be used to determine rates.  For this to work, though, the sensor would have to be connected in some way to communicate to the software tracking stops and counts.  Typically, this is done by wiring the sensor to an input of a Programmable Logic Controller (PLC).  Then the PLC can programmed to recognize the significance of the sensor being blocked to count each blocked condition as a product made, to time the period between products to determine if the equipment has stopped, and to time the period between equipment stoppages to determine equipment uptime.

 “If you’re going to spend the effort to wire one photo eye, then why not connect a few other items at the same time?” I asked. “The filler must have something to tell it when to start and stop, and probably has a signal to tell it when there isn’t room for it to discharge.  Most likely, there are a few relays in the electrical cabinet that we could get a signal from to tell us the status of the filler and a few of the reasons why the filler can’t run.  If those signals were wired to inputs, we can get more information to feed into your Line Event Data System.  We’d still be looking just at the filler unit operation, but we’d see some of the things that influence it and could have more insight as to what happens throughout a shift.”

 “That’s sounds great, but who can I get to do all this wiring at my new plant?” my co-worker asked.  “The mechanics aren’t into electrical work and I sure don’t have those skills.”

 “Try your plant’s best electrician.  He should be able to find the right wires to connect to and update your drawings.  Watch how the filler runs.  Ask the operators questions.  What device tells the filler to stop filling when the discharge is full?  What does the filler do when there aren’t any jars coming in?  What happens when there isn’t any product to put in jars?  Then explain to the electrician that you want to wire those conditions to inputs in your PLC and have it communicate with your data system.  If you can’t explain it to him, set up a conference call with me and we’ll work through it over the phone.”

 He agreed to try that approach.  “I can work through getting this connected up.  But, how do I get the operators to see the data and edit reasons?  And how do I get reports that I can use to analyze all this data?”

 “That’s a good point,” I said. “The most important thing about collecting data is make sure it is being used to understand and solve problems.  Often people spend a lot of time to collect data, but then don’t do anything with it.  Use your Line Event Data System to keep track.  You’ll have to think through how you want to display and share the information you collect.  But, that gets back to your original question of where to start.  The first thing you want your operators to know how many times their equipment stopped- what was the number of stops?  If you make this the most important measure in the plant culture, you will drive people to behave in the most productive way.  The less the equipment stops, the more consistent the operation, and the less effort is required.  Effort will switch from fire-fighting to preventing stops.”

 My friend agreed, but had a few questions.  “What about production counts and fault causes?  Aren’t we collecting that information, too?  Don’t I need to know causes to prevent the stops from happening?”

 “Sure,” I replied, “the more data you have, the more you can analyze the situation.  If you connect to the right devices, you’ll be well on your way to being able to dig in deeper.  But, start with the most basic and important measure of stops and build from there.  Make sure that information is correct before you go further.  If the information you provide isn’t accurate, you’ll quickly lose traction with the operation and you’ll have a harder time getting people engaged in your plans as you try to implement more tracking systems.  Besides, your operators probably know most of their stop reasons, they just don’t focus on eliminating them- they probably are more interested in getting the equipment back up, not eliminating the cause.  Once you have the organization focused on reducing stops, you can dig in on causes.  Getting accurate stop causes is much harder to determine automatically, so take your time to get it right.  That’s a topic for another day.”

Getting accurate stop counts on each line and each unit operation of a line is the first step to eliminating nagging minor stops.  It’s an easy measure to understand, and is less subject to manipulation than other calculated measures.  There’s an old adage that “you get what you measure” and I’ve seen the power of measuring and discussing stop data on a daily basis in operations I’ve managed.  With proper coaching, operators will engage in getting to the root cause of nuisance stops and eliminating them.  They’ll ask for help on problems that they can’t fix and resources will flow to problem areas.  In the end, their work day will get more predictable and less stressful. 

 The benefits to the bottom line are many as well.  With less stops come consistent flow of product, which means more consistent quality.  With less operator interventions, there is less risk for safety incidents.  Lastly, with longer time between stops, operators have more time to prepare for what’s next, the next change-over, the next maintenance intervention, or just watch the line for more improvement opportunities.  By measuring and reducing stops, every system of the plant benefits.

Posted in stops | Leave a comment

Stop Causes and Recovering from Stops

Recently, I was asked to put together a presentation for Invensys, a software company that we use at my plant.  I’ve worked with a wide variety of data in my career and wanted to share something meaningful with this group.  When I started writing ideas, I decided that it might be best to talk about some of the more basic uses of data visualization.  As I listed examples, I noticed that many recent data efforts were on a piece of OEM equipment that the plant purchased a few years ago.  I decided that it would make a good case study for the topic and also allow me to talk about the challenges of dealing with OEM equipment from a controls and data acquisition standpoint.

The machine for this case study was a tray erector, a relatively simple machine that takes a flat piece of cardboard and squirts glue on and folds and compresses it into a sturdy tray in a matter of seconds.  The vendor who supplied the machine makes many of these units and the one we purchased performed well at our vendor shop acceptance test.  Once we installed it at the plant, we realized that while it was generally easy to operate, there were times when it was tough for an operator to figure out what was needed to correct a problem.

The first challenge was getting the machine to re-start when it was stopped.  Our operators were trained to press a sequence of buttons and watch to make sure that certain lights came on.  Normally, this worked fine.  But when it didn’t, the fun began.  It turns out that there are 21 conditions needed in the programmable logic controller (PLC) to be true for the machine to start making a tray.  However, there were only two indicator lights to give operators a hint as to what the status was, so operators would have to walk around the machine and look for a problem which could take some time to find.  Without changing any code, a troubleshooting screen was installed on a nearby operator display showing the 21 logic conditions needed to make a tray.  That seemed to solve the problem for the operators, at least for a time.

A month or so after start-up of the tray erector, I came in one morning to find that the machine had been down for over four hours because the team couldn’t figure out that a safety door switch wasn’t made.  It turns out that there were 13 hard-wired contacts required to make the safety circuit become active.  This safety circuit was one of the 21 logic conditions, but again with 13 possibilities, it was hard to find the source of issues.  The electrical resource on the shift had looked at the schematic and after taking some voltage checks, determined that the problem was an emergency stop switch.  A few hours later another operator found the bad door switch and the problem was resolved.  I realized that this was a scenario that was likely to happen again based on the way the machine was wired.  We added wiring to each switch in the circuit and connected each point to an input in the PLC.  A new screen with a machine layout of all safety devices was added and now operators can quickly tell where there is a problem.

With these two changes, we have been able to eliminate virtually all downtime for electrical troubleshooting of basic equipment status issues.  Over the years, I’ve tried to do this on all equipment in the plant as a matter of principle, but often it is when an issue occurs that it becomes a priority.  With OEM equipment, you sometimes get what you get.  These changes and a few others are detailed in my recent webinar, which you can view from the links on my webinar page

Posted in webinar | 4 Comments