Studio5000 V28 Queueing Hickup

So I have wrote up a queueing sequence for a set of conveyors on one of my food production lines. The way the conveyors function is all the product comes out of a freezer and then splits into 3 identical conveyors legs to go to their respective machines to be packaged into sleeves, boxes, cases, then all go to the same palletizer. All 3 legs converge back together at the same location on their way to the palletizer. The goal of the queueing that I have wrote is to make it to where if the kickoff totes are filling up a "cycle stop" button can be pressed to stop the conveyor leg for 10 seconds in order to change out the totes then the leg restarts automatically. Also, there can not be more than 1 leg stopped at a time. The code that I have wrote was pulled off of the merge programming for the 3 conveyors going to the palletizer converging into 1. The problem I have with it is the conveyor legs will not stop in the order that their respective "cycle stop" buttons are pressed. The code works fine on the conveyors merging because there are multiple photo eyes that are used for location of boxes.


I wasn't sure what the best way to upload my code to here so I used the snipping tool and its all in the word document. The logic is from my personal controller and IO setup in my office. Currently the way it is it will work but questions may come up at some point as to why it isn't in order that the buttons were pressed and its also possible for the line to expand and may need more added to it.

When the buttons are pressed in order of input 0, 1, 2 it will cycle as 0, 2, 1. When pressed as 2, 1, 0 it will cycle in that order. When pressed as 1, 0, 2 it will cycle as 1, 2, 0. And finally 1, 2, 0 will cycle in that order. Tag CSQue is data type INT[5].

Hi HunterM83

This is because of the way your program is scanned, and the fact that you latch your "LegX_CS_Request"

If all 3 requests are high at the same time, both rung 4,5 & 6 will write to CSQUE[3].
When rung 7 is reached, the value of CSQUE[3] will always be 4, because that is the last thing that was written to the tag.

The reason that the "first" press is always accurate, is that it is proccesed right away. But the 5 second timer that you start after your first push is activated to reset CSQUE[0] and allow you to move your queue forward, makes it so that it is always the "last scanned of the 3 rungs (4, 5 & 6) that will be the next value which is processed.

I hope it makes sense, what i am saying.

I suggest that you use a FIFO with a length of 3, instead of your current queue, to make sure that the conveyors are stopped in the same order as the buttons are pushed.

Check out post #8

http://www.plctalk.net/qanda/showthread.php?t=112872

It is also about queuing sequence.

cwal61 said:

Check out post #8

http://www.plctalk.net/qanda/showthread.php?t=112872

It is also about queuing sequence.

Click to expand...

Thank you cwal61 for the link. That is super simple and works perfectly. I don't know how I didn't think of this. I tend to over think some of the stuff in this field when coming up with new things. I try to keep most things I do simple so that my technicians are able to follow everything somewhat easily.