Thanks for the reply.
The accumulating conveyor is actually a roller conveyor, not a belt. It is set up with 6 zone sensors which I am able to get a status signal from.
Define "status"
davehask said:
It has only one drive motor. The zones are 5ft long as the parts are fairly large.
Just for clarity, all the zones move together (no clutches) at the same surface speed, correct?
davehask said:
All I am after is to make sure that each part that enters the oven is in the oven for 20 minutes before being released.
Then all you need is to run a test and scale the command signal to the measured time it takes one piece through the input and exit eyes.
The command speed sent to the drive must be scaled linearly preferrably between two points other than zero, and then you oven "dwell time" can be the operator control, and the PLC simply scales it (y=mx+b and it's variants) before passing it on to the drive when called for by the mode and status logic.
More questions:
4) Can anything bad happen to the parts to disturb their position on these rollers inducing unpredictable slip?
5) How much slip do you see?
davehask said:
There can only be 6 parts in the oven at one time, but as one is released the next one moves into the next zone amking room for another part to enter the oven. So what I need to do is first, see the part enter the oven, then start a 20 minute timer and at the end of the 20 minutes, release the part.
Thanks again for your help.
Okay, so take my last abstraction and flip it inside out.
So few objects, nice tight loops, and still, you will know hte length and position of hte oven contents. If you are not comfortable with indirect addressing, read no further.
Know the command speed (measure moving product or the roller surface accurately with a handheld tach) and if variable, obtain feedback and/or speed command being sent to it to figure out how many inches per second this conveyor moves.
At regular intervals, calculate the delta of the position change of the conveyor, and increment the array of products (length 10, because memory is cheap) positions.
But wait how do we get those product arrays in the first place?
We monitor an entry sensor and if possible, use it to measure the length of the product. Pass the result thru a LIM block to see if it qualifies as a real product and not a moth or a power hiccup. If the measurement falls outside the limit, flag an alarm and take appropriate action (if any...maybe these products can go through back to back).
When a product qualifies in length, record the pertinent values in the next available spot in your array(s), starting with the position.
The program that updates the positions of the array, will loop through all ten of them every update period (I like to use an STI for this) by adding the update period scaled into "inches" or "mm" of travel for each active product.
Your loop will check the position to determine the entry time (based on any offset of the entry sensor), exit time, and when to drop it from the list.
This list can be a FIFO, but I prefer a rolling pointer and lots of members of the array structure:
N100:[0-9]:"Product ID Code INT"
F101:[0-9]:"Position"
ST102:[0-9]:Barcode value
N103:[0-9]:"Oven entry time formatted MM:SS"
or
T104:[0-9].acc:"Bake time"
Use your imagination and build in spares.
Then the windows can be adjuastable to match what your sensor(s) see, and even if they fail, you can't get out of sequence, and can activate machinery, sort, and display the products you KNOW are really there accurately.
I spent almost 3 years as a green tire sorter and two of my machines had automatic sorters with FIFO zone based logic, so my first deep venture into PLC programming was to write bullet proof sorting code, so forgive me for the long posts. When you have had to hand carry dozens of tires over a monstrous roller conveyor system to resort them because a moth landed on a photoeye...and do this for months daily...you develop sort of a passion for the subject and a disdain for oversimplified FIFO tracking.
Paul