Operation Times Reporting In an Assembly Line

In our previous post, I have told about a customers request for reporting operation times of stations in their assembly line.

They were going to use it for assembly line balancing

Many readers may think that 'well, assembly line balancing should be done before establishing the assembly line', you are right.

But our customers assembly line was producing mixed products, I mean there could be several types of product at the same time. In the other hand they had too many types of product, and new types of products were being developed by their R&D department.

If you want to see the performance of stations in your assembly line, what would you like to have in your reports?

• I would like to see the operation times distribution as an histogram.
• I would like to see the idle time to find out bottle necks.
• I would like to see the efficiency of stations.
• I would like to see how mechanical movements limit my productivity

We had a budget limited with only software change, customer did not wanted to add any extra devices or operations on assembly line.


Let's consider our scenario with a single station:

• Station is free.
• New product comes from previous station
• Operator starts working on product.
• Operator pushes the 'operation complete' button to send the product.
• Product waits if the next station is busy.
• Product moves to the next station when the next station is free.
• Station becomes free.

What we have as hardware:

• Product complete button
• Product presence sensor
• A buzzer to warn the operator on exceeding the cycle time

 

Customer has approximately 70 stations, designed system should be flexible to add new stations.

We had to design the system for both convenient for PC and PLC software development.

First we discussed about storing the measured operation times in PLC, then transfer to PC. Not so convenient. There were more than 70 stations, meaning 70 more timers or counters in PLC.  For our project it was impossible without PLC upgrade.

And not only operation times of course, we had to think about transfer times and idle times also. It was impossible with customers existing PLC system.

And making necessary software changes in PLC should take at least one week.

So we decided to copy only hardware inputs from PLC to PC. Solving the problem in PC was more convenient.

In PLC, we made two flags:

Product presence flag, which is directly connected to product presence sensor, set to “1” if station is occupied with a product and reset to “0” when station is free.
 

Operation complete flag, which is set to “1” when operator pushes to the operation complete button and resets to “0” when product leaves the station.

Let's draw a timing diagram, this is not an handshake, just a timing diagram for two flags:

 

T1,T2 and T3 shows only one products timing. TA,TB and TC is the next products timing.
Normally  T1, T2 and T3 corresponds with TA, TB and TC respectively.

T1 is the time interval that the station is free, however a new product may be on the way.
T2 is exactly the operation time which spend for assembly operations.
T3 is the idle time, where all assembly operations are completed and product is waiting for the next station to become free.

T2 and T3 were the exactly time intervals we would like to see. But, what about transfer time? We also needed to report transfer times.

For an exact transfer time calculation, we have to measure the time between our stations product presence flag and next stations product presence flags rising edge.

However, it is just a little bit difficult because to do this, we also have to consider order of stations to know which station follows which. It was difficult to manage because assembly line was not straight, there were branches and loops.

So we decided to accept that TA as a transfer time.

Why not T1?  Also T1 was possible, but we considered that PC is an unstable device, may be frozen or application may hang. So PC software may be restarted anywhere in the cycle and measure time intervals as shorter than it is.  We wanted PC to record clear measurements only.

In PLC software, we had represented the flags as bits in a byte, so a single byte stored 4 stations information.

For 70 stations, 18 bytes were enough. PC was going to read 18 bytes from PLC and was going to write 9 bytes for buzzer alarm.

In PC, we have considered all stations as an array, just wrote few lines of code for one station and applied to all stations in a For..Next loop.

Overall code except 'Read all inputs' and 'write all inputs' took less than 100 lines of codes.

Data was collected successfully.

For our next post, I am planning to tell you about the database structure and web page reporting of this project. We had some limitations in DB.

I think may people guessed our problem, there were 70 stations meaning that each product will produce at least (at least because there were some loops in assembly line) 70 records in database.

One shift was producing approximately 600 products.

There were three shifts daily.

Working 5 days in a week.

Working nearly 50 weeks in a year.

So we were expecting:

70 x 600 x 3 x 5 x 50 = 31 500 000

more than 30 million records.

And customer was planning to apply the project to their second assembly line if project not fails.

More than 60 million records. So huge that consumes too much CPU in database server and possibly may slow down other applications.

For the next post, we are going to focus on database design and some statistics. 

Customer is always right and sometimes undefined

You may remember the cartoon  about ‘IT Project Management’

This is a great similitude and fits for most IT projects.

In this post, I would like to tell you about a project of mine which is different at the beginning.

Normally customers may request features that are contradictional, those contradictions are eliminated during project design in co ordinance with customer.

One of our customers requested us a project.  It was a modification on an existing assembly line which was developed by our team.

Let’s see how our customer described the request:

“We need to see cycle times of all stations on a web page, and also want to warn the operator on exceeding the cycle time.”

That’s all? No.

“We have a limited budget and don’t want to spend too much money and don’t want operators to do extra operations for reporting cycle times.”

Yes, that’s all. I just imagined the cartoon below:

On the left, how most of the customers explain their request. And on the right, my customer.

A warning light lit in my mind, it may be risky without handshaking clearly. Something was wrong.

So I asked:

“What do you want to get by reporting cycle times?”

The answer was:

“For line balancing of course”

Well, no more information.  Just all, we had to guess what customer is really requesting.

First of all, “cycle times of all stations” was cloudily, because assembly lines don’t have distinct cycle times. Assembly lines have an average cycle time during a time interval, and that is calculated as:

Cycle Time = (Total time spent [e.g. in a shift]) / (Total number of products)

It’s the average time needed to produce one product, and it is same for all stations because all stations are cascaded to each other.

So, probably the customer was mentioning “operation times” actually.  Now it was clearer, probably customer wanted to see “how their assembly line balanced, and how efficiently working”

Even customer did not request clearly, they should need the following reports:

-          Where are bottlenecks? (To consider dividing station or sharing some operations between neighbor stations)

-          Where are the most inefficient stations? (This is different than bottleneck. Some stations may cause scrap and it is possible to detect if any station is producing more products than final stations output.

In most cases, data collecting terminals are placed on assembly lines to collect number of products and operation times, but ,in this project customer did not want to add anything. 

Customer also did not wanted the answer of question “why my assembly line stopped in a certain time interval”

We had approximately 70 stations with operators. Operators have pushbuttons to send the product to next station. We were going to take necessary information from this buttons and existing sensors.

As you see, some customers may have contradictional requests, and some have none.

We are going to start to a new series of a case study, collecting operation times from assembly line. We are going to tell about how to analyze the project and how to design.

I would be glad if you comment on this post, especially what would you like to see in the case study.

Simple PC – PLC Communications Part V - Expect The Unexpected

The handshake used for PC – PLC communication works well if everything is perfect. But what happens if something happens that violates the handshake?


In some countries power loss is an ordinary part of life. Generally PC is supplied by UPS, but PLC is not. In a power loss, PLC lefts the communication unexpectedly.


Even if you are using an industrial PC, it is not stable as a PLC. PC or the software running on PC may be frozen. In this case, PC or software may need a restart.


In the other hand, physical conditions may also violate the handshake. Imagine that boxes crashing on station:

It is possible; sensors may be dirty or defected, or any other unexpected reason may cause this.

So, how can we restore the stable cycle again?

Most PLC systems use non-volatile memory for holding data permanently. For a PLC system, it is not difficult at all.

If we are programming the PC, it is obvious that we have to store some information in a file or in database to avoid failure after power loss.

If we say as a rules of thumb:

1. Store all global variables (handshakes last time interval, all counters etc. and the most important; the last data you wrote in to PLC) in to a text file or database as soon as they changed.
   
   
2. Restore all global variables on start up.
   
   
3. Do not execute 'Write all outputs' before restoring all global variables.
   
   

For obeying rule 1, you can use 'Property' in addition to a global variable. Think the 'Property' as a global variable, however it is possible to execute defined subroutines when property is read or write.

VB6.0 example:

Public Property Get Data As Integer

Data = m_Data

End Property

Public Property Let Data(ByVal New_Data As Integer)

m_Data = New_Data

SaveProperty (m_Data,"Data") 'Save routine for recording Data
End Property

'Get' routine is executed whenever you attempt to read property 'Data' as

A = Data

or

MsgBox Data

And 'Let' routine is executed whenever you attempt to write property 'Data' as:

Data = 5

or

Data = Text1.Text

Use 'Property' as a global variable, add a record routine inside 'Let' and never mind again.

For the example above, restoring the 'm_Data' global variable instead of restoring 'Data' is works faster because restoring 'Data' will cause re-recording the 'Data' again and in some cases it may cause a violation error as 'File Already Open'

Rule 2 is clear so nothing to explain.

Rule 3 is also important. Think about the handshake graphics:

PC Status = '0000' also means that 'PC has completed operations, so that PLC can send the existing product and bring the new one'. Visual Basic assigns 0 into variables as they created.


C may assign anything in the memory unless variable is initialised.

Writing uninitialized data into PLC may result unexpected and unwanted results. So do not execute 'Write All Outputs' routine before loading all global data or properties and the last data written into PLC.

As the summary of those three rules of thumb, you are free to last time intervals in handshake as long as you want, however do not switch into another time interval or do not cause PLC to switch into another time interval.

You can consider putting a button on screen for resetting the handshake cycle against deadlocks, you can simply switch to T1 and clear 'PC Status' with this button, but never switch to T1 on start up. Let the operator decide for reset if necessary.

If it is not possible to control write and reads?

If your application writes 'PC_Status' into PLC before restoring it on initial start, it may cause unexpected movements on the assembly line. Some may get injured or you can miss one product.

Some SCADA systems also uses 'Read All Inputs' and 'Write All Outputs' routines for PC – PLC communications. However some of them may execute those routines in a separate thread so it may be possible to write a global variables (mostly named as 'Tag' in SCADA systems) value into PLC before initialising or restoring it.

So, what can you do if you are using a SCADA and not be able to manage 'Read All Inputs + Write All Outputs' process ?

One solution is using a cyclic counter in PLC. PLC has an increasing counter and PC echoes it into another data memory of PLC. If counter value is equal to the echo, PLC increases the counter and waits the same value from PC. If PC can not update in a certain time, PLC understands that PC has failed, and the data from PC is untrusted. This method also can be used to understand if PC is still working.

Fragmanted Information

Other than power interruptions, communicating with lots of data may cause unexpected results. Most PC – PLC communication protocols have packet length limits. For that reason, if PC wants to write too many information into PLC, it should use many data packets to write information in to PLC.

This may be dangerous if automation system designers don't take sufficient precautions.

Assume that PC is writing a receipt into PLC data memories, and 'receipt ready' flag is at the beginning of the data memory area.

PLC may apply the receipt as soon as it realises 'receipt ready' flag is set, however receipt may not be ready on time. This results of this design may be difficult to debug.

How can we avoid fragmented information?

1. We can use checksum at the beginning or at the end of data memory area reserved for PC's write operations. However, there is still a probability that something may leak because there are too many possibilities to produce the same checksum value.
   
   
2. We can use the counter solution stated above. Reserve two data memories in the data memory area which is reserved for PC's write. Let the PC fill two data memories with the echo from PLC. If both data memories are same and fresh, PLC can trust that information is consistent and trustable.
   
   

With this post, we completed the 'Simple PC – PLC Communications' series.

Our next post will be about customers. 'Customer is always right and mostly undefined'. And we will have another series with a case study. We are going to examine a data collection system to use for assembly line balancing and reporting the bottle necks on an assembly line.