Advice: Tracking a reject on a conveyor

Drbitboy: The problem is if there is no boxes for a while there is no shift or if the boxes are random spaces so a shift of a box on PE1 then a gap of say 1 mtr. fine if all boxes are consistent. There is only one real way to track them is with a type of encoder, however, it depends how long the conveyor is and if quite long would require a massive shift register for a normal encoder. I have done what I described above on a sortation system. normally each leg would have a barcode reader, however, on this occasion there was not the pennies for that so a proximity and a flag was enough, normally again if the resolution was good then you would not need a PE on the diverter, which was the case on some of the lines even then the shift register was massive. I cannot remember now but the time for each shift was shorter than the box so although the divert window had to be larger the PE before each reject ensured that the box was there and the PE front edge plus a time delay ensured the box was diverted. And the fifo word (words) for the window would be reset, this was required as there were 15 divert stations hence the word shift as it contained the bar code (although in simple form 1-99).

It depends on where the split is, we had exactly the same problem as these were two different PLC's, I'm having to go back a bit and now I remember we sent the shift register on a poll so that the diverter plc received the registers and this did not have to happen very often as the window for the divert was at least 3 shifts so at least 3 seconds if a box was sensed by the divert PE it started a timer for positioning purposes and if any shift register words in that window was the bar code it would divert on the PE + positioning time. This was in the 90's and is still working. As I say this was a large part of the system consisting of a ring conveyor and 15 divert stations (if bar code was not allocated to a lane then it carried on along the ring merged with incoming boxes) before anybody comments on what happens to ones that don't get diverted it was catered for but for this post it does not matter. The other plus on this system was that small slips by the boxes or the belt drive still left a reasonable window to detect the boxes and bar code.

Forgot to add, why not add a couple of digital signals between the PLC's certainly a lot faster than the coms.

parky said:

There is only one real way to track them is with a type of encoder,

Click to expand...

I agree, but the OP said all he has is these two PLCs and the two PEs.



Also, if there is enough of a space between boxes (see Caveats in earlier post), then the boxes+PEs are the encoder, and what's more they are an encoder that also allows for boxes sliding back on forth on the conveyor, which an encoder on the conveyor itself would not. Instead of encoding time (ugh) or conveyor (better) and inferring box position from the encoder, the PEs encode the box positions directly.


What I am saying is that this is not a [single upstream PE + conveyor encoder] system, from which can be indirectly inferred the scan during which a box reaches some downstream position, because there is the second PE that is a direct measure of when a box reaches that downstream position. What you say is true for the former, but the latter is a different animal entirely; in some ways the latter is better, as long as the PLC can somehow "know" the status (okay vs. reject) of the box at the downstream PE.




The [two PLCs with MSG] is an ugly twist (as Peter noted), but OP also said it was reliable; an alternative might be to move the diverter cabling and control to the Packer PLC and shut the other PLC down, but if it ain't broke ...

parky said:

The problem is if there is no boxes for a while there is no shift ...

Click to expand...

Why is that a problem? No boxes means nothing to divert.


A PE2 edge pops the [0kay;1:divert] "First Out" bit out of the FIFO and puts a [0kay] bit in as the "First In" bit of that same FIFO (at a position well upstream of index1); a PE1 edge with a reject box triggers a change of a bit to [1:divert] somewhere in the FIFO (N.B. NOT at the "First IN" of the FIFO, but rather at index1).


The FIFO is functionally the same as the circular queue: with the FIFO approach the FIFO content moves and index2 is static; with the circular approach index2 moves and the queue content is static.

parky said:

Forgot to add, why not add a couple of digital signals between the PLC's certainly a lot faster than the coms.

Click to expand...

The OP said "one of the plcs can't be "downloaded for quite sometime."


We still don't know much about the setup, but I assume that means the downstream PLC code cannot be changed, because the code he is working on seems to be for the upstream PLC.


This is starting to sound like a bunch of artificial constraints; are being sucked into another class exercise?

I agree, If I was asked to do a mod to get something working then they would have to give me access or I walk away.

parky said:

I agree, If I was asked to do a mod to get something working then they would have to give me access or I walk away.

Click to expand...

yup.

Using the FIFO suggested by GaryS and others, but with the boxes as proxy "encoder" elements, my attempt at modeling the OP's process is here:


https://github.com/drbitboy/PLC_reject_tracking


Thanks in advance for any feedback (style, clarity, comments, etc.).


It seems to work, but still seem unnecessarily complex; note the caveats. Also, I don't know the OP's actual setups, and made guesses about interactions with the real world.


The overrides can be used to simulate photoeye inputs (PE1 and PE2). A PE2 rising edge should not occur when the index is zero; of course, in an actual installation there would be logic to handle that case (e.g. coffee cup placed in front of PE2).



The AND(index,63,index) instructions are unnecessary; they are a mental holdover from the equivalent implementation using a circular queue in place of a FIFO.

Here is one you would have to code it in RSL as I do not have my licences installed, it was done in GXWorks for Mitsubishi. You generate a pulse every x ms to take place of an encoder, does not have to be too fast it will depend on the box sizes but the principal is as long as the conveyor is running and assume a reasonable constant speed. The upstream PLC sends a message to the diverter PLC (we can only assume that the message will reach the Diverter within the given window i.e. at some time while the box is sensed by PE01).
I have not used it but assume it may not be needed, if the PLC gave the message within a window that is no more than the time the box covers PE01 then it can be tracked. Assume in the case of the timing I have done that a message has been sent within a window of 600ms of entering the diverter conveyor (as I said I have not used the PE01) then a 1 will be put into the shift register. the box travels along the conveyor for x number of shifts (this would have to be set on site we assume that the conveyor is 10 metres long and we have a shift of 100 at 100mm per shift. providing the box is 600mm long then the window of detection is 600ms and 6 bits at the end of the shift register. it's all about the maths,
message sent to plc so providing the message is received within the window of 6 shifts bits 0 to 5
001000 000000
Bits 95 to 100
| | = window for message | | window for reject

These are then shifted along the shift register when the box gets to PE02 if one of the bits from 95 to 100 is a 1 then start the reject process.
So to sum it up it's a bit shift with windows to allow for a bit of slippage or message timing differences providing a message can be sent reliably within the window.
The size of the window will have to be within the box length (time from reaching a PE to the time it leaves). the number of pulses for the window will depend on the maximum scan time of the PLC (the pulse timer must be larger than the max scan time). alternatively you could use a timed interrupt for the shift.
I have done a system like this but far more complicated it did use a prox & flag on the conveyor drive with over 1000 word shift & 15 divert lanes. to check what shift position each divert window was in I started the conveyor when the box hit the read PE (bar code 1-99) then stopped it at the divert PE and a bit of temporary code gave me the shift register location I did this for every divert and that gave me the window and where it was in the shift register.

parky said:

Here is one...

Click to expand...

Sweet, I hope the OP gets a good grade


I updated mine (here) to include a simulator, driven off random periods for reject/accept regimes, and with bits 13 (~0.8s) and 15 (~3.3s) of the free-running clock triggering PE1 and PE2 events.


Toggling B3:1/15 toggles the simulator.


I run timers, as proxies for the MSGs, to discrete output 0:0/0, so on a MicroLogix 1100 there are clicks, providing some auditory feedback.


I see the strength of the timer-as-encoder approach being that it is much cleaner code, so easier to understand and debug, plus it doesn't need the downstream PE and so eliminates that as a point of failure; the only weaknesses are its brittleness with respect to encoder speed and/or noise in the box motion vs. time relationship, plus the need for tuning the timers' and windows' parameters. I expect any timing noise issues can be eliminated by mechanical means, so both of those are small potatoes.


I see the strength of the boxes-as-encoder approach being that it is independent of conveyor speed and noise up to a point; tuning the diverter timing could be a speed-dependent issue but that is true in any approach; the weakness is that it might fail for slower conveyor speeds as the boxes could be closer together.

Yep if he gets a good grade perhaps he should share it with us lol.
An old colleague of mine rang me yesterday out of the blue for a chat, I was telling him about the problem as he was working with me on the large sortation system we did some years ago. His grandson has a massive Meccano set originally given to my mate in the 50's he suggested that I send him the code as he had an old Q series PLC.
He called me just an hour ago on video chat showing me it working, with his grandson they have built a conveyor using the Meccano, a DC motor/gearbox and a belt made out of plastic damp course (modern equivalent of the old felt type) the sensors are actually micro switches with long wires soldered to the leaf and the boxes are small plastic trays from a storage cabinet filled with sand. The one thing he added was PE01 for registration purposes, however, if the message came outside the window i.e. no box present it latched in a bit and then count the number of boxes on the conveyor and through some maths would set a bit in the last two box windows of the fifo so it would reject both. Not sure how he did this but I assume he used a known portion of the fifo to do it. It seems to work a treat, he is going to change the fifo to a word type and put random generated numbers in to simulate bar code reading. He is re-living the old days I think I have just re-awakened his interest in PLC's. He is on his way to an essential job as he has been pulled out of retirement but when he gets back will try to get him to post a video of it. I get your point about boxes being too close together but any system would probably have to be designed to ensure boxes are separated, as long as there is a gap large enough to read a couple of pulses from encoder/pulse timer then would not be a problem, also boxes too close together would possibly cause problems on the diverter anyway. any well designed system would separate boxes at critical points to allow for other functions for example a metal detector needs separation or it will not work.

I haven't had time to read the replies yet, but thanks for the input everyone.

Some quick back story, in the in house maintenance guy. I can modify some code, but this is out of my skill set. I know I can make it work with timing, but it won't be robust. I've been asked to make some changes because the integrator won't (2 separate companies, 2 separate plcs). A pile of other issues have cropped up over the weekend, so my time goes there before I can read through this.

parky said:

He called me just an hour ago on video chat showing me it working, ...

Click to expand...

Woo hoo, sweet! I am definitely looking forward to that video.


You can tell him my boxes-as-encoder code is on Github; I'd be interested to know if it actually works ;-)


Btw, it seems like the OP has moved on; maybe the assignment was due. Do you think my description of the process (three independent inputs, one output) is consistent with the OP?


https://github.com/drbitboy/PLC_reject_tracking

Instruward: I suggest you use a reasonable fast timer, providing the conveyor speed does not vary, the boxes do not slip by much and of course we don't know what size boxes there are or what gap there is between the boxes. As I mentioned above, the code I produced has been tried by a colleague of mine & his grandson, the Meccano conveyor was as long as his garage this I guess was at least 6 mtrs. so a good test. even on a rickety bit of engineering. He did add the first PE as the trigger window so that the reject signal was synchronised with the window. at the start of the fifo.
The more bits in the shift register the better resolution but providing you had at least 3 then I don't see a problem, I have not tried Drbitboy's code but there is another angle and I trust his skills and that it works.

parky said:

Instruward: I suggest you use a reasonable fast timer, providing the conveyor speed does not vary, the boxes do not slip by much and of course we don't know what size boxes there are or what gap there is between the boxes. As I mentioned above, the code I produced has been tried by a colleague of mine & his grandson, the Meccano conveyor was as long as his garage this I guess was at least 6 mtrs. so a good test. even on a rickety bit of engineering. He did add the first PE as the trigger window so that the reject signal was synchronised with the window. at the start of the fifo.
The more bits in the shift register the better resolution but providing you had at least 3 then I don't see a problem, I have not tried Drbitboy's code but there is another angle and I trust his skills and that it works.

Click to expand...

Ok, I will try the timer... I still need time to read through all the replies. You are right there is no box slip, the sizes vary around 14" length, and the gap is very inconsistent.

I want to come back to this project hopefully today and try some changes, but it maybe a busy day with other things...