Heat tunnel jam detection using FIFO

[Rube]

Ron you might also want to program a timer that automatically clears the counter after a certain time. If you don't, the counter value could take hours or days to go above the "jam value". We used to use this very logic to control a filler. When bottles went into a rejector they were ctu'd, when they came out they were ctd'd. When the .ACC went too high we stopped the filler. We reset the .ACC every two minutes to prevent nuisance stops.

 

[dandrade]

Yes!
Method is Time insert in FIFO. Work good.
Here is method and complete detail graphic.
http://www.plctalk.net/qanda/showthread.php?t=8033

Only have restrition in "Width band" it is dimensions product, space, numbers start-stop include in segment and speed variation 30%.
Is possible add "tune", preview acceleration/desacelaration
more details, alarm count max. start/stop in segment.If control enable/disable in situation correct for not get "false alarm".
Paralyzed, if continue development make "expresion math" for determine the limits and test application more conditions.
Good project

 

[rsdoran]

Ron you might also want to program a timer that automatically clears the counter after a certain time. If you don't, the counter value could take hours or days to go above the "jam value". We used to use this very logic to control a filler. When bottles went into a rejector they were ctu'd, when they came out they were ctd'd. When the .ACC went too high we stopped the filler. We reset the .ACC every two minutes to prevent nuisance stops.

Rube I kinda thought about that but couldnt see a reason. I was more worried about negative counts thats why I reset on startup or if a jam occurs.

What I did think about doing was changing the timer preset if X amount of packages entered the tunnel (note: have to assume some things here). Lets say packages will be 1 sec apart at the max production rate (I assume there will always be a gap between packages). That means that 9 packages should be the max in the tunnel, maybe 8 didnt really look at it close so used 10 to say..HEY TOO MANY PACKAGES IN TUNNEL. I thought about doing a MOV to the timer preset of 5 secs if C5:0/ACC greater than/equal to 5 and put it back to 10 secs if less than 5.

I just jump on these things to get practice. I like to keep it simple as possible in the beginning then see what happens when its in actual use.

 

[Rube]

I was more worried about negative counts thats why I reset on startup or if a jam occurs.

That's cool--the reset of the counter will take care of negative counts as well.

If you set up for 10 counts and it takes three hours to reach 10 do you really have a situation? Or did someone remove a part after the count up/before the count down? It may not fit monkey's application but it might fit someone elses. Food for thought.

 

[rsdoran]

If you set up for 10 counts and it takes three hours to reach 10 do you really have a situation?

There are always variables involved, in this case it was a "tunnel" so I "assumed" product couldnt be removed after passing entry sensor and/or before exit sensor except in the case of a jam where all product would be removed and counter reset. Making that assumption the counter ACC should "never" reach 10 (or max amount possible in tunnel) unless there is a jam. Its also possible to clear the jam the machine will be shutdown which would mean a "start command" could also be used to clear the ACC.

I like to work on the assumption that jams will be "rare". If for some reason jams occur on a frequent basis then some form of modifications need to be made to eliminate or minimize the occurences....IMHO.

Minor rant alert
Dandrade posted a link to this thread: http://www.plctalk.net/qanda/showthread.php?t=8033

Personally I didnt see a reality in that process. I have never seen a conveyor with constant gap but varying speed. Muliple sized products that could domino or fall off (that part was confusing). Usually you will use a faster conveyor to place a "gap" between product especially when a secondary process is involved...ie heat tunnel, labeler/printer, weigh scale etc.

The whole scenario is using a PLC to "try" to overcome poor design in the system...IF IT IS NOT COMPLICATED LETS MAKE IT COMPLICATED seems to be the motto.
end rant

 

[monkeyhead]

Nice... I likes it. Clean and simple.

Thanks again Ron.

 

[monkeyhead]

There are always variables involved, in this case it was a "tunnel" so I "assumed" product couldnt be removed after passing entry sensor and/or before exit sensor
<snip>
I like to work on the assumption that jams will be "rare".
<snip>
The whole scenario is using a PLC to "try" to overcome poor design in the system...IF IT IS NOT COMPLICATED LETS MAKE IT COMPLICATED seems to be the motto.

hahaha... i find your frustration amusing because i'm always being asked to modify logic to compensate for bad design decisions. I rarely get to set up systems, so i only really get to do mods on existing machinery.

but you did assume correctly that packages can't be removed once in the tunnel, as well as jams being rare.

i was put on this project simply because an operator wandered off and somehow managed to let 30 some odd orders build up in the heat tunnel which resulted in 120 products getting melt and burnt.

so this time around, i wasn't even compensating for a bad machine design, but a lazy operator.

 

[dandrade]

Understool now you point
Minor rant alert ugly translation or slander
Dandrade posted a link to this thread: http://www.plctalk.net/qanda/showthread.php?t=8033

The whole scenario is using a PLC to "try" to overcome poor design in the system...IF IT IS NOT COMPLICATED LETS MAKE IT COMPLICATED seems to be the motto. Yes, guys put it slogan.You not first
end rant

Not infuriated, it only needs to raise the understanding level. I will return in the original topic with sharpened detail. No imediate, last weeks, time less it month.
Monkeyhead, if applied the code and help contact PM.

 

[OkiePC]

Monkeyhead...Your FIFO code is better than the simple timer method because it will set the alarm one second after any piece is due to exit. Analyzing the timer method, it could theoretically allow a piece to cook for almost 20 seconds. If two pieces enter the tunnel one second apart, and 9.9 seconds later the first one exits, the timer will reset, and it will take another ten seconds before an alarm occurs.
Most of the time "simpler is better". Sometimes a little complexity provides a better solution.

 

[rsdoran]

Sometimes a little complexity provides a better solution.

It may be a faster solution but that doesnt mean its better. In 9 seconds you shouldnt be able to burn more than a few packages but then again this code could easily be modified to adjust to the number of packages that have entered...ie if entering at a rate of 1 per second then exit timer is adjusted to compensate.

I am just an old maintenance guy, the FIFO with time stamp is fancy and effective but not as easy to undestand as counters and timers when troubleshooting.

You should use what is needed when needed though. This application didnt seem to need the complexity of a FIFO though but there are many systems that would.

 

[richie]

count up and down

how will the greater than or equal to know what is what if count up and down fillow each other shoul not count up be before greater than or equal to and counmt down be after ??? P.S. Hey guys be easy on me I am new at this !!!!!!!!!

 

[tom_stalcup]

Well, I'll see if I can give a stab at an explanation for you. You might already know some of this, and I'm going to do a simplified, generic version. Most(not all) Allen Bradly plc's will follow this general guidline, but if you are doing more advanced programming you'll need to do some further research on your specific processors.

*DISCLAIMER: THIS IS NOT HOW THE PLC WORKS... THIS IS A GENERIC OVERVIEW OF HOW SOME PLC'S WORK, AND IS NOT TO BE MISTAKEN FOR ANYTHING OTHER THAN AN ATTEMPT TO EXPLAIN BASIC CONCEPTS. THERE IS A LOT MORE GOING ON THAN I AM TALKING ABOUT HERE*

The plc works on what's called a "scan cycle", which is broken up into 3 basic sections. You will have an input section, a calculation section, and an output section.
1. The input section reads the current status of all information being used in the program(input values, current data table values, etc) and stores them for this 1 cycle
2. Based on the values being stored for this 1 cycle, the plc calculates what all actions need to be taken(outputs turned on, counters incremented, comparisions used, etc)
3. The plc implements all of the things that needed to be done, based on the calculation section.
Phil has an illustration that might make a little more sense here.

So... The plc will take a "snapshot" of all input states, counter values, etc..... The plc will then figure out which outputs and bits need to be turned on(based on the snapshot values), and then the plc will turn on outputs, bits, etc. based on the evaluation. And then the plc will do it over...and over...and over....etc.

Hopefully that makes sense, and is not just confusing you more

 

[darrenj]

well i guess i am with ron on this one..I am just a dumb old electritian..A programmer may be able to make my code smaller by using fancy instructions but i still like the simple stuff..I do try every once and a while to get more complex and hell it works..but a 3 am and bleary eyed i prefer something easier on the head!! For an example i have a machine that i completed (Thanks to all here!!) and now have a another one to do..This time i plan to get a little more complex..using bit shifts..perhaps a fifo to detect lost cartons ect..However it wont be the same as the first one..I did that one 6 months ago and can still look at the code and know exactly whats going on with out having to think..

KISS

(Words to live by sometimes!!)

D

 

[monkeyhead]

Wow... I forgot about this project.

Happy to report that the 'complicated' logic I implemented has been running damn near 24/7 since I originally posted this in late May without a single complaint.