BSL vs. ???

hey guys, im trying to implement BSL into a bottle tracking program im writing. while writing im visualizing it in action and before i continue down the wrong path i was wanting to know if there is hope for BSL to work on a continuously running conveyor system with no "stations" or nests, or servo control.

if it helps, what i have is chemical bottling filling line. after the capper the bottle transfers onto the labeler conveyor, gets labeled then transfers onto a 90degree righthand conveyor and then goes on its way. while on the labeler, a cognex checker vision system checks the cap, back and front label. (three seperate units). if cap or labels fail, it is to be rejected via a lane divider that sends it down another conveyor for further inspection. plc is micro 1000. currently using a counter based program that is flawed because the vision systems send their fail output randomly while in their scanning sequence.

the biggest challenge is that this line runs over a dozen different products of different sizes, shapes, and speeds. changing products as often as seven times a week. so tweaking in output overlaps and moving photoeyes etc is not desirable.

i am not asking for anybody to do my work, just a point in the right direction would be appreciated. ANY info you need to help, i will be happ to provide. thanks

Merlin,

Your description of a real line parallels the imaginary RSLogix Bottle Line in the LogixPro Simulator program. The LogixPro Bottle Line program has a lot of the features that you mention. Yes, it does use the BSL as the Exercise 5 solution. But then in Exercise 6 it is shown the the BSR works more efficiently, needing only 2 BSR's to track the same data as 3 BSL's in the earlier exercise, and doing away with the Offset, so that firguring out the bit-shift location of each action station is easier.

It might be helpful to work through that particular exercise. LogixPro is available for download or CD version (about $40 now I think) at http://www.thelearningpit.com/lp/logixpro.html

This statement is key 'currently using a counter based program that is flawed because the vision systems send their fail output randomly while in their scanning sequence.'.

How do you reconcile the result to the bottle?

For example, when I'm tracking things and I'm waiting for a result for an item, its done on one of two ways.

1. The speed and spacing is such, that I can expect the result for the object when only that object is within a positional window.

2. I send an ID for an object when its being monitored and the result is returned with the ID.

i just went on their site and purchased the logixpro cd. anymore advice while i wait.

These might help:
http://www.mrplc.com/kb/index.php?page=index_v2&id=71&c=12

http://forums.mrplc.com/index.php?download=353

http://forums.mrplc.com/index.php?download=350

PeterW wrote:

This statement is key 'currently using a counter based program that is flawed because the vision systems send their fail output randomly while in their scanning sequence.'.

How do you reconcile the result to the bottle?

Click to expand...

Yup. What Peter said.

Merlin, the fail outputs are only "random" in the sense that they occur asynchronously. For conveyor systems that are carrying product past cameras, I've found FIFOs to be more effective than counters. In addition, this might be best programmed as a state machine so that you can keep the Checker results synchronized with the product.

If you run this as a state machine, you might need two FIFOs and three subroutines so that the subs can cycle independently of one another. The FIFOs then tie them together. This is a little complicated, but it allows you to be sure that all product has been inspected and it allows shutting down the line immediately if a component fails.

Something like:

Sub 1 - Load FIFO 1 when bottle goes past conveyor entry sensor
1 - Wait for bottle to go past FO sensor
2 - Load FIFO 1
3 - Return to 1

Now we know to alert Sub 2 that product is coming:

Sub 2 - Determine P/F based on Checkers
1 - If FIFO 1 is not empty, go to next
2 - Verify Checkers are online, not faulted, P/F outputs Off
3 - Wait for bottle to go past Checker Trigger
4 - Unload FIFO 1

Step 5 is a little tricky. Basically, we know we're waiting for pass/fail but we'd also like to make sure the Checkers are ok too. Think about just one Checker. The logic might be:
- Start a timer T1 when we hit the step
- If Checker output is P and .not. F, load FIFO 2 to indicate P
- If Checker output is F and .not. P, load FIFO 2 to indicate F
- If Checker output is P and F, throw a fault and stop
- If T1 is Done, throw a fault and stop- we never got P or F

For three Checkers, the logic runs in parallel. The nice thing is that you can use different values in the FIFO to indicate just what failure occured for later tracking. I usually use a negative number to indicate fail, and you can use -10, -20, -30 to indicate to the SCADA or HMI just what failed. Once all three Checkers have sent a P or F, return to Step 1.

Sub 3 - Set the Diverter
1 - If FIFO 2 is not empty, go to next
2 - Unload FIFO 2
3 - Set the diverter
4 - Wait for bottle to go past downstream-of-the-diverter sensor
5 - Return to 1


That's the basic idea. As usual, error handling will make this a lot more complicated, but this is one way to keep track of the product going down the conveyor and use the Checker results. BTW, I work for a medical device mfgr. so my logic usually includes a lot of stuff that is designed to catch machine errors and faults as much as product problems. However, for conveyors in general I've found that something like this cuts down the debug time and you don't have to worry about the "out of step" that invariably happens with simple counters. Now, if this were a palletized system, or walking beam, or indexer- different story and the BSL would be fine. For a conveyor, not so much.

thanks for all the great advice. when i get home im going to have to go over the FIFO more carefully as i have zero experience with that instruction.

I have run across this problem before when working with Cognex. Basically what i ended up doing with using a combonation bit shift register and a fifo stack. See the orignal thread.

I had an encoder on the line and used that to drive the shift register. each clock of the encoder I would load a 1 if there was a container presant at the inspection point and a 0 if there was not. I know that the eject station is X number of encoder counts down the line.

Whenever I get a result from the cognex system, (It was setup to give an output for inspection complete and bad part. This would also work if you and an output for good and an outut for bad) I would use that output to load a FIFO stack (1 for bad 0 for good).

I watch the bit register at the ejection point, whenever I see a 1, I know there is a container at the eject station. I then unload the fifo stack. If it is a 1, eject the container, if it is a 0, let it pass.

This worked great. It did not matter how delayed the output from the cognex system was as long as it occured before the eject station. I also added some logic so if a container went past the eject station (no output from the vision system) it would eject the container by default. Did not matter how fast or slow the coveyor was running, never got out of sequence, did not matter how many containers were between the inspector and the ejector either.

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

Greg

gosenback, this is sounding like what would work best for me. ive got a pretty good handle on bit shifts, but cannot get a clear picture on how to use FIFO at all. any examples or tips???? thanks to ALL

Yeah, the first time I looked at it was wierd too.

A FIFO is just another "complicated" kind of instruction that has some more stuff around it than a bit or word. The FIFO is designed for just this sort of thing- you "load" it with a number when an event happens, and you "unload" it later when another event happens. The "unload" gives you back the number that was saved at "load," and you can then use that number to make a decision. In this case, we can decide how to set the diverter.

Now, the neat thing about it is that if you "load" a second number before the first one is "unloaded," no problem- it just saves it for you. For an AB, the first number is at Index 0, the second at Index 1, the third at Index 2, and so on. So that's what you have to define for the FIFO- how many numbers (words) it will store. When you "unload" it just takes the oldest number out, and drops all the others down a position.

So for what we're doing, the first FIFO I mentioned is really trivial. I'm only using it because I like state logic and I have to force parallel states to be on scan all the time. For the first FIFO, when a bottle enters the conveyor, I'd write a "1" as the number to the FIFO. It's really just a placeholder. Now, the fact that the FIFO is not empty is a "dot field" in an AB, so we can use the .EM bit to arm the second set of logic.

That's the real one. When that first bottle passes the trigger, we unload the first FIFO and run the steps to load the second one. When all three Checkers have reported, we can load the second FIFO with a number representing P/F. I usually use a positive value for P, and a negative for fail.

Once again, the fact that the second FIFO is not Empty can be used to arm the Diverter logic. In the Diverter logic, the number in the second FIFO is unloaded- well in advance of the bottle actually getting to the diverter- and used to set the position. Note that we don't care where the bottle is; all we care about is that the Checkers completed and the bottle has been correctly checked and is on it's way to the diverter. We can immediately set the diverter position and then just wait for the bottle to go by. All without any more sensors or logic to try and figure out which bottle is really there!

To set up the FIFO, take a look at the SLC500 help file; it's pretty good. Set up your Control Words- R6:0 and R6:1 say- and define a head end for the words in the FIFOs, something like N7:0 and N7:8. You need to have each FIFO big enough so that there is a word for the max number of bottles that will be in the queue. If say 14 bottles can line up between the Checkers and the diverter, then you need 14 words for the FIFO. After that, when you "load" the FIFO you're using a number generated by the Checkers; it can be any integer like N7:22, doesn't have to be "-32." When you unload, same thing- you can unload into any integer like N7:23, then use that value in the logic to set the diverter position.

Play around with it, and post up some code- like anything, it's not bad once you get that first one to work.

alright, this is helping alot. wouldnt you know it, i cant work on it today, but tomorrow im all over it. thanks again everybody. im sure ill be back with updates.

It is a good thing you are using AB for this. AB has built in FIFO functions (FFL and FFU). when I did this app I was using an AD PLC which had no built in FIFO functions (at least it didn't back then). I basically had to build a FIFO system using bit shifts, pointer, and counters. It was a real pain.

big thanks to all who helped! got it figured out last night. once i figured out how to use the fifo instruction it was cake. im using a seperate stack for each parameter being checked. like i was advised earlier. works great, never fails. the only thing that confused me was that on an example i found on mr.plc's website was that when he loaded the fifo he would move the data to another control file, then move back when he unloaded. i didnt do this and it still worked. why did he do this and should i have?

I have no idea. I never had to do that when using AB fifo functions.