CompactLogix - Shift Register from Fast Conv.to Slower Conv. Losing Bits

[Cydog]

Good Morning ,


I'm developing a Shift Register Program for a conveyor system. I begin the Shift Register on a conveyor that is roughly 128 FPM , and I'm carrying the result to another conveyor that is running slower at 42 FPM . The problem I'm having is , I'm "overrunning" the slower conveyor. Let's say I have 6 bits from my 128 FPM conveyor , and when it flows into my 42 FPM conveyor I only have 2.


Do you folks have any ideas ? I knew I was going to have this problem .


Thanks so much ,

 

[Steve Bailey]

What real world phenomena are you trying to model by the shift register? What do the individual bits in the shift registers represent?

 

[Cydog]

Thanks for responding so quickly. I have a vision system inspecting a part on the 128 FPM conveyor that are single parts. We need to " pennystack " the product on the slower conveyor 42 FPM. These parts on the 42 FPM conveyor . They need to travel to a dump gate that will open.


So if I have 6 failures from the vision system , I need to see all six by the time it gets to the Dump Gate. So my result now is
6 Failures (6- 1's ) on the 128 FPM and Only 2 (2- 1's) on the 42 FPM Conveyor.


Thanks ,

 

[Steve Bailey]

Does "pennystack" mean you are piling one part on top of another on the slower conveyor? That would mean most of the time you have to reject a good part for every bad part.

If the parts aren't stacked, do you really need two shift registers? I expect your problems arise out of using two different signals to shift the bits in the two shift registers.

 

[Cydog]

Yes Sir, they are stacked on top of each other when they hit the conveyor that is running 42 FPM. I'm using the last bit of the shift register on the 128 FPM conveyor , to move the 1 in the next shift register.


So that is the one that is overrunning the 42 FPM.


That is why , I would like to keep track of the failed part during the entire journey to minimize the waste.

 

[parky]

Are both shift registers triggered on the same pulse from the fast conveyor ?

 

[Steve Bailey]

Sounds like you need to count two parts coming off the fast conveyor before shifting the bits in the slower conveyor's shift register. You'll also need two bits to keep track of the status of those two parts. If both parts are good, move a 1 into the shift register. If either part is bad, move a zero.

Unless you're able to reject only the bad part in the stack.

 

[Cydog]

Thanks for joining , Parky.


The fast conveyor ( 128 FPM ) , has 148 products on it. The fast conveyor has a shift register , and at bit (4).19 , I have another shift register that is always running , when the conveyors are running .


When bit (4).19 is a 1 , I trigger bit (0).0 of the shift register for the slower conveyor 42 FPM and that takes it for the rest of the journey , but missing a bits because it is being overrun by the Faster Conveyor 128 FPM.

 

[Cydog]

Steve ,


I see what you mean . The dump gate is really going to need to dump more than one .


What if , I see a 1 in (4).19 , I multiply by 4 , to come up to 4 wafers are bad in that group on the slower conveyor ?


Another question , what type of instruction would I use to put 4 ones in the first group entering the slower 42 FPM , conveyor , such as 1111 instead of 0110 ? Masking ?


Thanks ,

 

[parky]

I had a similar problem so I just used one long shift register running at the faster speed, I then looked at a window to reject the bad part, however, there was a compromise where the slower conveyor was not checked for speed but it worked well and even though the parts were close together on the slower conveyor they were not without a small gap, this allowed me to detect the part and use the window to reject the part. What it meant was the fast conveyor gave a shift pulse every say second, the slow conveyor was about 3 pulses for the same distance. The shift pulse (conveyor prox + toothed wheel) was chosen so that we would get approximately 4 pulses per part on the fast conveyor.

 

[drbitboy]

I am still unsure I understand the problem.


It seems like there is a bit added to the first shift register for each of the 148 products on the 128fpm conveyor.


Then on the 42fpm conveyor the products are "pennystacked," which seems to mean that the products are in groups of several (3? 6?) on the 42fpm.


So every time a group triggers some sensor on the 42fpm, the process needs to look at the oldest group of bits.


Am I close?


This is the confusing part (one of them, anyway):

So if I have 6 failures from the vision system , I need to see all six by the time it gets to the Dump Gate. So my result now is 6 Failures (6- 1's ) on the 128 FPM and Only 2 (2- 1's) on the 42 FPM Conveyor.

I guess the question is, what is triggering each shift register? If they are triggered at different rates (e.g. once per foot, so 128 triggers/minute on the fast and 42 triggers/minute on the slow), then of course bits will be lost.


Another question, related to the grouping question, is whether the Dump Gate can dump one product, or if it must dump an entire group.


Also, if adding bits to the register(s) happens asynchronously from removing and looking at bits, then you need a FIFO, not a shift register (although the latter can be made to look like the former).



As SteveB notes, if the products (bits) are grouped, then do you have to reject a group (of 3? of 4? of N?) if any one of the group is bad?


Perhaps even more fundamental: is the group size fixed?



finally, it may be possible to have only one shift register. After all, at steady state and to first order, there will be one product added for every product that comes off.




The key question is what is driving the shift registers? is it time? An encoder on the conveyor? A part being tested by the vision system?

 

[drbitboy]

I had a similar problem so I just used one long shift register running at the faster speed, I then looked at a window to reject the bad part, however, there was a compromise where the slower conveyor was not checked for speed but it worked well and even though the parts were close together on the slower conveyor they were not without a small gap, this allowed me to detect the part and use the window to reject the part. What it meant was the fast conveyor gave a shift pulse every say second, the slow conveyor was about 3 pulses for the same distance. The shift pulse (conveyor prox + toothed wheel) was chosen so that we would get approximately 4 pulses per part on the fast conveyor.

^This. I think I have an example of parky's algorithm on Github ... yeah, here it is. Go back and read the entire thread for context; ignore my solution and look at .RSS and .PDF with [parky] in the filename.



As long as the speed ratio is reasonably near constant, or at least as long as the time* from [testing by the vision system] to [the Dump Gate needing to make a decisiont] is near constant, the different conveyor speeds are a distraction and can be ignored.


If the process is not consistent, then it needs a FIFO where the statuses can be added and removed asynchornously, not a shift register.



* or number of conveyor pulses

 

[Cydog]

Ok. I see what you mean . The use the 128 FPM Conveyor Shift Register , at that speed , and just stretch it out , all the way to the dump gate , and just grab bits along the way for some visual and Dump Gate .

 

[parky]

Dr: Think we have been here before lol,

 

[drbitboy]

Dr: Think we have been here before lol,

A fellow is invited by a friend to the monthly meeting of local comedians. As part of the entertainment, members get up on stage and tell jokes, but everyone knows all the jokes, so the person on stage only calls out a number, and everyone laughs. The new fellow goes up on stage and says "32" ... silence; then "42" ... silence. As he walks off the stage, dejected, his friend says "It's okay, not everyone knows how to tell a joke."