Track product movement down a belt using an encoder.

[Adreasler]

I have a project where we are using a belt and encoder to track items on a belt. There will be multiple items on the belt at once, and the current plan is to store the location and 'status' (good/bad part) in shift registers.

The PLC is an Unitronics V700, and the EX-I/O module will be replaced with a Snap-On V200-18-E1B, when it arrives.

The theory of operation is as follows:

The product passes a photosensor, which adds an 'item here' flag to a shift register.

When the register indicates a part is under the vision system, the 'item here' flag will send a 'trigger pulse' to the vision system to start the inspection.

Once the vision system has completed the inspection, a 'scan complete' flag and a possible 'reject this part' flag will be added to their respective shift registers.

When the bad part is at the reject station, the 'reject this part' flag, if present, will trigger the reject blowoff.

The problem I am facing right now is how to convert the signals from the encoder (100 pulses per revolution, 2-bit incremental) into an accurate signal to trigger the shift register movement. I was intending to count X 'belt pulses' to be 'one inch' (one shift of the shift registers), however previous tests have shown it difficult to perform math on the MI register that holds the encoder's 'value' and have it stick; the encoder's value gets updated and overwrites the math adjustment.

is it really this difficult to make an "every X pulses" pulse train built in VisiLogic. 

[Ausman]

To me it looks like you need to be using the Store function to do your maths, and be doing this operation for each item.  This will likely mean a "rolling" FIFO number of MIs involved that is big enough to cater for the maximum number of items that might be on the belt at one time.

cheers,

Aus

[Flex727]

To expand on Ausman's comment: there are plenty of vector operations that allow indirect addressing that are available to help solve your problem. I'm pretty sure VisiLogic has all the tools you need to handle this problem solution easily once you figure out the logic.

[Joe Tauser]

This one's not as easy as it sounds.

Don't do math on the encoder register, do math on a buffer you've copied the encoder value to.  What is the actual scaling of the PPR to inches on the belt?

Are the items evenly spaced?  It may be a simple as counting increments of spaces using the start flag as a shifter / block incrementer and tracking the rejected bits in register.

If you have to know the exact location of the item for a the reject station, you'll need to know the distance between the reject station and the "item here" start flag.  I'd load a data table and use it as a two-dimensional shift register that is pushed down every time the start flag is triggered.  Let the encoder value keep incrementing  - if you store it as a long you can snapshot it for a quite a while.

More specific info on the application, please.

Joe T.

[Ausman]

5 hours ago, Joe Tauser said:

do math on a buffer you've copied the encoder value to.

Joe has clarified what I meant...but didn't actually write when I said this:

12 hours ago, Ausman said:

using the Store function to do your maths, and be doing this operation for each item

I meant "Use the store function to copy the encoder value at the moment the item is captured, and then do the maths."   (Sometimes my brain doesn't fully transpose all my thoughts into keyboard tapping!)

15 hours ago, Adreasler said:

"every X pulses" pulse train built in VisiLogic. 

And on this question, you can do it by having a count with the +1 triggered by the "every X pulses" count on the encoder being reset.  ie if the encoder count has reached 100, it is reset, and as part of this reset your "user count" has 1 added to it.  In this case a 100 to 1 ratio. 

cheers,

Aus

[Adreasler]

On 5/8/2018 at 12:11 AM, Joe Tauser said:

This one's not as easy as it sounds.

Don't do math on the encoder register, do math on a buffer you've copied the encoder value to.  What is the actual scaling of the PPR to inches on the belt?

Are the items evenly spaced?  It may be a simple as counting increments of spaces using the start flag as a shifter / block incrementer and tracking the rejected bits in register.

If you have to know the exact location of the item for a the reject station, you'll need to know the distance between the reject station and the "item here" start flag.  I'd load a data table and use it as a two-dimensional shift register that is pushed down every time the start flag is triggered.  Let the encoder value keep incrementing  - if you store it as a long you can snapshot it for a quite a while.

More specific info on the application, please.

Joe T.

The items are NOT evenly spaced, these are small (38mm) beverage caps passing under a vision system for inspection, I was planning on using a shift register to track the 'reject flags' as the caps move down the belt, using a Double Word variable for the register, I can get the position to the closest half-inch, which should be sufficient for caps that are about an inch and a half across.

As far as 'letting it keep incrementing' and snapshoting the value, this is for a production line, running three shifts 5-7 days a week.  Sooner or later (most likely sooner) the encoder's High Speed Counter will roll over, and that will leave some elements 'past the end of time,' so to speak, their count value will never come up, and, if bad, they will not be ejected.  I should point out that I have asked how many bad parts per 100 we are allowed to sent out; zero. Then I asked how many per 1,000; zero, how many per 10,000; zero.  With this as the goal I am to work towards, I need to insure that even the POTENTIAL for an identified pad part to continue down the 'pass' line is eliminated.

[Ausman]

Somewhere in the process it wouldn't be too hard to reset the count without upsetting things too much.  However......

Perhaps the best solution is to not use the belt encoder at all.  Instead do a rolling actual count of how many caps are on the belt from the first sensing point, and physically add a sensor at the reject blowoff which ties in to how many items are "active" at that time and whether they are good or bad.  Depending on the max quantity at one time you can likely use shift registers for this quite easily.  Would be more accurate anyway, as it is item triggered, not theoretical location.

cheers,

Aus

[kratmel]

I also tried to implement a similar system. However, it was slightly different.
The presence sensor of an object in the camera zone has activated the recognition process.
Then the camera signaled - the correct object or not.
If we have a signal about an incorrect object - the PLC at that moment recorded how many impulses need to be calculate to the point when it is necessary to remove it from the flow.
At this point there was a mechanism of throwing object away. That is, the PLC does not do anything until it receives a signal that you want to remove the object. The other part of the algorithm (shift register for bad object) worked like yours. 

[Ausman]

On 5/12/2018 at 4:30 AM, Adreasler said:

even the POTENTIAL for an identified pad part to continue down the 'pass' line is eliminated.

And an addition to my comments about "reset the count without upsetting things":  during the reset simply discard all the items that are on the belt at the reset.  Get a human to look at them if this tiny loss is not allowed, or else they are simply going back in the granulator. 

And your comment appears to still be based on using the raw encoder count, without my "reset the HS count and trigger a sub-count +1 addition" as your X pulses train.

In all of this, I still think the likes of Kratmel's or my idea the best.  But if you are still focussed on using the belt encoder, another way is to have each item's first sense initiate it's own count and at the same time reset the raw input count.  You would then work the camera inspection on the correct number span being present that covers the way the caps fall around the belt.   This wouldn't be too hard....the max qty on the belt at any time dictates how many "sub counts" needed that simply roll around in a FIFO way.   That way you wouldn't have any issues with overflows etc at all.

There are many ways of doing what you want, and I don't consider any of them too complex.  You could even do it all again on another smaller belt that accepts the first one's output in a far more uniform pattern, given the importance of no errors.

cheers,

Aus

 

[DaveE]

Good Morning

I did this (and do this) using a data table and a sensor at both ends

After the camera is triggered, store a bit in row 0 of a data table to "say" either " good read-0" or "bad read-1" and then increment the row in the data table, so the next trigger comes into the next row.

Then at the reject end I read row 0 and if that bit is true I set the reject, if false I unset the reject (just to be safe)

at the end of all that I delete row 0 and decrement the row

works like a charm and no encoder needed.

also, major benefit is that you change product sizes, it doesnt matter, as you are counting products. Also you can put the reject where you like, who cares, its only numbers.

(Hint, if you go this way, make sure that you use plenty of rows when you set up the data table, when I started, I set the table for 30 rows, and needed 40 products before the reject eye.. oops)

 

[CWAVE]

Here's some code I use all the time for this purpose, it handles rollover with no issues.

To explain:

MB45 - motor running / belt moving. You should make this a time delay off to allow for when the belt stops. or just remove it from the second rung to allow for  belt decel.

MI27 - High speed counter input wired to encoder.

In your case you will need to have 2 MI's per product on the belt in a shift register or data table. These will equate to MI58 and MI38 in the image.

MI58 - The position of the HSC the last time the line was executed.

MI35 - The position of the product on the belt.

MI59 - temporary calculation store.

It works simply by adding the position offset between the last time it was executed and the current belt value. As long as you use MI's for everything, the rollover doesn't bother it. I've used this counting at about 1kHz.

If you set MI35 to 0 when a new product is sensed, and shift the registers, it will accurately track each product up to 327 revs at 100ppr. You can init MI35 to -32768 if you need to double the scope.

 

[Adreasler]

Thank you all for your help.

I have been able to get the encoder to run the shift register in one direction, which turns out to be all I need, since I needed to change by plan and use ranges in the MB bank for the shift register, and the vector commands only allow 'shift left.'