Tracking object and updating array for each object

Hello

I have to track objects that have barcodes along a conveyor line. Some of them will get pushed, and some will reach the end of the line depending on cameras that inspect them.
The barcode scanner is at the very beginning, and there are 5 cameras that need the barcode to map the results.

I was reading around the forum and saw things like FIFO and UDTs, and so far FIFOs have been okay, but right now it's so there's a FIFO array for the barcodes, then another one for the first camera's results etc..

It would be nice if there could be a way to update the fifo array for each object

for example

FIFO_Array[10] of UDT DataResults

DataResults is an array[6] of the barcode and results together
0 = barcode
1 = camera result 1
2 = camera result 2
etc.

Another thing is, if the first camera's result is bad, then it won't even reach the other cameras
Same thing with the second camera, if the result is bad, then it won't reach the next cameras

I've been thinking of something like a pointer or index for each camera

Any suggestions? Thanks

You need to track the position on the conveyor and the part at each camera
i would use a simple file shift.
not too difficult
the most important thing is to have a good index system a sprocket on the conveyor end roll is a good way

One thing you really need is a pulse from the conveyor to drive the FIFO or what ever.
I suggest that the pulses from the conveyor be at least one pulse for the size of the component you are tracking, more pulses are ok but depending on the length of the conveyor number of components on the conveyor etc. will affect the size of the FIFO array, too many and you could face scan issues. I have done this some years ago although we did not have a bunch of cameras just a bar code scanner at the start of the conveyor and a weigh table so it was a two dimensional array, There were 17 divert stations that would divert down to stackers and one for over weight & one for no read. Fortunately the components in question were plastic boxes and were of a consistent size so there was no need for PE's at each divert station.
Without sync from a pulse tied to the conveyor it could go out of sync.

How many bits in a barcode?


How many bits in a camera result?


Does each camera read the barcode when an object reaches that camera, or does it get the barcode from somewhere else?

TL;DR


This is a different model (approach) than those suggested by parky and GaryS: they are tracking positions on the conveyor i.e. the data move in synch with the conveyor (or at a constant rate), so there will be non-existent objects (I think); I am assuming an object arriving at each station (barcode scanner; camera; push gate) triggers a rising edge. Memory is cheap, so which model you choose is up to you.


Since items are potentially removed, then several FIFOs in series, one for each station, seems a natural way to handle this: if a camera accepts an object that is FFUed from the FIFO upstream of that camera, then that object is FFLed onto the next FIFO downstream; if the camera rejects an object then that object is not FFLed onto the next FIFO. This does require that each camera's push/reject gate is more or less synchronous with that camera, with no possibility of the next object hitting a camera before the previous rejected object is pushed. If that requirement is not guaranteed, then there will need to be a FIFO for each push station as well, where the decision whether to FFL the object onto the next FIFO is made.


You don't mention your PLC brand (UDT suggests A-B, maybe?), but I have not seen any FIFOs that allow you to FFL and FFU UDTs onto and off of a FIFO. However you could FFL one integer value (barcode) onto the first FIFO at the barcode reader, then FFU that value and FFL two values (barcode, cam result 1) onto the next FIFO at cam 1, etc.


Having a single FIFO, or set of parallel single FIFOs for the whole system, would require removing objects along the way i.e. from the middle of the FIFO, which would be messy. Also each intermediate camera would have to keep track of the position of the next object it was going to see, which position would be updated as each new object hit the front of the line, so that would be messy too.


Given that, I suspect a single static array of UDTs treated as a circular buffer, and maintaining pointers into the array for each barcode reader/camera/push station's next object, as you suggest, would be cleaner. A circular buffer is essentially the same as a FIFO, but requires managing the pointers manually. There would be a seventh value in the UDT indicating whether that object had been rejected, so subsequent stations could ignore that UDT/object by incrementing its pointer, which would require loops in case multiple contiguous objects had been pushed.


One advantage to the circular buffer approach is that there are only two or three types of stations: barcode scanner; camera; push. All five camera stations will do the same thing, as will all five push stations, so it might be possible to write the code for each once as a subroutine with the indices supplied as arguments by the calling code. The alternative is to copy-paste the logic for each four times, then correct each bug five (or ten) times. It is also possible for the camera and push stations to use the same subroutine.


Then there are the problems of starting the model with one or more objects already in the system, and resetting the model if the model goes out of step with reality.


It's not the same process, but here is an example of maintaining pointers into a circular buffer, as an alternative to a FIFO.

Thank you GaryS and parky
Unfortunately I don't think I can use a pulse encoder since there's five conveyors and part of the time the object's going to be in the air for the cameras. Plus I'm not familiar with how pulse encoders work at all

drbitboy thank you for the detailed explanation and example! I think I'll try the circular buffer, it seems like it would be a cleaner solution than having a lot of FIFOs running around. I also like the idea of using a subroutine with arguments, but I don't have a lot of experience with that so I might leave that for later.

Thanks everyone

A simple file shift 2 lines and your done
Why a circular buffer you parts are not moving in a circle why recycle the data. o me that could lead to bad data in the buffer / data file always start out with a clean slate and plug the data in as the part pope in.
as for encoder just us a chain sprocket and prox switch
or if you have more than one conveyor are used then a photo eye at the transition point do hand off from one conveyor to another
as a part is removed clear the data
i have done this same process many times

As for a pulse from the conveyor this is just a proximity and a toothed wheel on the drive, depending on the resolution you need it could be just one or two bolts on one of the sprockets there is no need for an encoder as this would give you possibly thousands of pulses per revolution.
Again if separate conveyors then use a photo sensor to detect the edge of the component when it enters the conveyors. There is a possibility that the bar code reader will have a sensor to trigger the read and may be one for each camera but we can only go on information you give us, not sure what you mean by the part is going to be in the air, perhaps elaborate on that or have you invented sky hooks.

GaryS, what do you mean by file shift? I haven't done that at all before
It's be great if I could do it in two lines but I don't know what file shift you're talking about
Like the BSL, FIFO, etc. instructions?

I forgot to mention, I am using Allen Bradley with Rslogix

By in air, I mean a robot will turn the object this way and that for the cameras
The sprocket and proximity switch/ sensor or the photoeye sound good actually, I'll probably look into that

Also with the circular buffer, it won't recycle data, everytime it runs out of arrays it'll just start at the first index to fill in data
The object associated with the first index by that time will be processed completely

r12345 said:

Thanks everyone

Click to expand...

I don't know if the circular buffer model will be simpler than the FIFO/FFL/FFU model, because they are essentially the same thing: with circular buffers the data locations are fixed and the pointers move; with FIFO/FFL/FFU the pointers are fixed and the data locations move; in either case the data move relative to the pointers. The advantage to the FIFO approach is that it handles the pointer/data relative positioning for you.


Another advantage to multiple FIFOs is that the interface between successive FIFOs provides a convenient place, with simple code, to remove an object from the process; for the circular buffer there is no convenient way to do that and the code will instead have to advance pointers over previously rejected/pushed objects' data. In other words, with multiple FIFOs, the basic model is most like the actual process being modeled.



Also, you should not discard the shift register approach; parky and GaryS have a lot of experience with this kind of stuff, and encoders are not that complex. That said, it will be messy if the time (as measured by either the clock or the sprocket teeth) between stations is not constant e.g. if the conveyor keeps moving while a camera takes a variable time to check the lifted object; also if you need to track more than a single bit per object (e.g. barcode), then I don't see how a "file shift on two lines" would work.

I just realized what GaryS was talking about, the bit shift instructions, which would be perfect actually but I'm not sure since I'm dealing with strings and multiple bit values

And yes the time in the air would be variable depending on camera results (if the second camera says bad, it'll skip the other cameras in the air and be dropped off on the conveyor and then pushed, same thing with the third camera.)

r12345 said:

And yes the time in the air would be variable depending on camera results (if the second camera says bad, it'll skip the other cameras in the air and be dropped off on the conveyor and then pushed, same thing with the third camera.)

Click to expand...

Yes, but the BSL model may or may not care about the timing of any object that has been removed, and any item not (yet) removed may have a constant time* from barcode scanning to any point in the process.


For example, say either

1. the conveyor under a camera station keeps moving, but the time for the lift-examine-drop operation at that station is constant. Then as long as the conveyor moves at a constant rate, that simply adds a fixed quantity of time* for that object to arrive to any downstream stations. OR
2. the conveyor under a camera station stops moving during the lift-examine-drop operation. If time* is measured in tooth-counts, then the duration of that operation is zero i.e. a constant and the same as case 1 above. If time* is measured in seconds, then it depends on whether the lift operation is constant time* for that part, but that will affect downstream arrival time of other parts on the same conveyor.

* count of sprocket teeth or seconds

I should've explained in more detail, so here's a summary

There are multiple conveyors, with objects stopping at camera locations and sensor locations
For the first camera, the object lays flat on a conveyor with the camera above it

If the camera says it's bad, the conveyor moves the object to the next conveyor where a pusher will push it onto a side conveyor.

If it's good, it'll move to the next conveyor for the robot to pick it up and twirl it around for three cameras.

The robot then places the object down on a conveyor. If any of the three cameras (with the robot) said it's bad, it gets pushed to a side conveyor.

If they don't say it's bad, it remains on the conveyor for a final camera.

If that final camera says it's bad, it gets pushed onto a side conveyor, and if not, it moves on to the final conveyor in the end.