PLC code fault finding approach

Hi all,

I've been tasked with finding a glich in a program/programs... A barcode data array is moved through a line where pallet strapping and shrink wrap is occurring... The barcode is the decisive factor for determining the number of straps or yes/no to shrink wrap....

The data passes through 4 plc's from start to finish... 3 of these plc's have been programmed very poorly and have few comments and the comments are in Korean...

There is an intermittent fault which causes a wrong barcode to be associated to the wrong pallet causing the wrong number of straps etc

I am by no means a beginner to Plc code,

But what I would like to know does anybody have any good work practices about how to go about solving this issue,

My only theory right now is that it's gonna take a lot of debug hours to track everything back considering the fact it only occurs around 20-30 times in an 10 hour shift,

Would love to hear people's opinions

Thanks in advance!

When an automation task is split between controllers, that is the worst.

If possible log relevant values from all controllers, and use the same timestamp in all controllers.
If possible, log with cycle precision, so that every single state change is logged. To save log memory, only log when a change is detected.
That gives you a chance to pinpoint where the problem is located, if not exactly what causes the problem.

What tells the strapper/wrapper that a pallet has moved into/out of a zone?
Maybe a sensor is double-pulsing and the pallet data is clocked more than one time per pallet/zone transition.
So, as JesperMP advises, log. Log zone/data transitions with a synced timestamp - if possible.

Since it happens that frequently, I would set up my laptop and camp out at the line.

When the error happens, stop the production on all the machines long enough to save the online copy of the each plc program with the data.
Where is the data transfer failing, specifically which plc?
Then look at the triggers of each plc for the data transfer logic and see if there is a problem there.

I would also look at the plc code itself to see if an instruction is writing into the transferred data registers for some reason.

Hope this helps,
James

You might also want to look for a pattern in the data error. For example: Does the incorrect data match the pallet before or after the problem pallet?

taward31 said:

Hi all,

I've been tasked with finding a glich in a program/programs... A barcode data array is moved through a line where pallet strapping and shrink wrap is occurring... The barcode is the decisive factor for determining the number of straps or yes/no to shrink wrap....

The data passes through 4 plc's from start to finish... 3 of these plc's have been programmed very poorly and have few comments and the comments are in Korean...

There is an intermittent fault which causes a wrong barcode to be associated to the wrong pallet causing the wrong number of straps etc

I am by no means a beginner to Plc code,

But what I would like to know does anybody have any good work practices about how to go about solving this issue,

My only theory right now is that it's gonna take a lot of debug hours to track everything back considering the fact it only occurs around 20-30 times in an 10 hour shift,

Would love to hear people's opinions

Thanks in advance!

Click to expand...

I would create an array in each PLC and each time a barcode is scanned, push that value onto a stack.

When the issue occurs, compare the barcodes in each of the stacks and see if there is a break in the sequence.

kwade said:

What tells the strapper/wrapper that a pallet has moved into/out of a zone?
Maybe a sensor is double-pulsing and the pallet data is clocked more than one time per pallet/zone transition.

Click to expand...

This is the first thing I would confirm/correct. Many many problems can be traced to shrink wrapped pallets (wrap not pressed down and then dragging and catching on hardware, PEs, etc.). Check also that any sensors which detect the pallets aren't getting multiple hits per pallet - like seeing through forklift cutouts.

It could be the code but you state things work right most of the time. Something like this is more often than not a hardware issue

The first thing I would try is to see if Google Translate can help me with whatever documentation there is. Next stop is to see if there are some obvious things you can add to the documentation such as I/O.

Once you've got some kind of documentation you may find something that will point you in the right direction. Even if you don't you've now got some kind of documentation.

The next step is st set up traps to try and see what happens to that bar-code as it traverses the program(s). Perhaps set up a logger to trace any and all references to bar-codes in a parallel table (all values once every x seconds) so that you can trace what's going on.

The 1st place I would look though is the routine(s) that handle the bar-code input and, if they exist, routine(s) that decode/extract/whatever the bar-code data as it's used by the code.

Good Luck,

Yosi

Hi all,

Thanks for the responses.

spent another day in the trenches and still none the wiser.

I was informed by the in house maintenance team on the first day that they had tracked it back to one area transition, after spending the first day at that area logging the the data by hand it was clear that this is the wrong area as I could see no issue
This was line one of a dual system.

All I could do was go back to the start (or the end in my case) and trace it back from the start again myself,

when I did this I recorded that the data actually is going wrong in both lines. So I have found more problems but still no solutions

the two lines merge at the end and the pallets are either shrink wrapped or sent straight through. It seems both lines are mixing up data in a similar fashion.

When watching the data the main problem seems to be that a barcode jumps ahead at some point...

the system then runs this way until a "ghost pallet" i.e. no associated barcode reaches the end and then the operators force it out manually through the wrapper.

The system then resumes to work ok until it happens again.

It is also clear that there are many more bad barcodes happening daily than I originally stated but the fact that there styles are similar i.e shrink wrap and # of straps, it can still be right configuration but with the wrong barcode.


Anyway I have recorded all the data memory areas where the barcode is held so I guess the next stop is configure a logging system

Although as other members stated It may be some hardware double triggering. all will be revealed when we log I suppose.

Also I must state sometime the barcodes do not read on the way in to the lines and the operators then use a barcode scanner (handheld) to scan templates of the config.

This is definitely causing some of the one off problems but other issues are there also.

Thanks Again.

mendonsy said:

You might also want to look for a pattern in the data error. For example: Does the incorrect data match the pallet before or after the problem pallet?

Click to expand...

This would be my first question, as well as if the error is isolated to one pallet, or is there an offset, in which the whole line must be reset or manually entered. A good description of the issue is key to investigating it. Once you have a good description, you can hypothesize and isolate possible causes that meet that description. Inspect the pallet that is incorrect, as well as the one before and after (maybe more). The error could be in the handoff, or could be the barcode scanner reading certain pallets incorrectly.

taward31,

Since you state that the barcode jumps ahead one let me offer this.
Look at the barcode triggering system and see what triggers the barcode and puts the information in your system.

To me, you are getting a false signal or something is causing the system to trigger 2 or more times for the same barcode.

I had a similar problem like this several years ago and we fixed the problem in the following manner:
1. When the product is in place, read the information and put it in place.
2. Latch a memory bit that prevents the system from triggering a second time.
3. When the scanned container has moved out of the way and confirmed with a device, unlatch the memory bit you set earlier.

I would also break down your problem into smaller pieces, individual lines and the merge. Once you get each line working correctly, the merge should be much easier.

regards,
james

taward31

Can you put DUMMY-TEST pallets on that you can easily track in the plc software?
What plc? software/version?

Your plc software may include histogram/trend tools.
Some time back, I used the AD PAC-Suite 3000 bit histogram tool to identify and prove a double 'pallet complete' signal from a robot cell.

Quick update,

I have created temporary hmi with all the codes displayed as per their section and can now watch them as they pass through...

It's seems there is more than one error occurring,

First of all there is situations where the barcode fail to scan initially and then the operators have to scan it in by a hand barcode reader...

Instead of going to the pallet and scanning they have a bunch of "template sheets" and scan one of those in with the supposed same configuration, I have confirmed that this is causing some of the issues,

Another issue is the the third Plc (at the end of the line) does not delete it's barcodes upon the pallet leaving a conveyor etc. The operators sometimes have to force a pallet through a machine in manual mode and when this happens the barcode is not transferred and the pallet now takes the previous barcode,

Another issue is that one of the convoyers is not switching off when a pallet in on it and waiting and this is causing two pallets to enter the strapper, to which the operator has to manually sort out, I think this is causing the one barcode of set issue,

I have enough diagnosis now to make some code changes and see how it goes.

Thanks all for your input it has been very helpful!