Continuous Shifting

Hi,

This may not be new to you, I am still trying to understand the concept of continuous shifting/tracking.

I happened to see an ABB flexpicker robot demo. Was impressive, the concept of various parts coming on a conveyor [I saw an encoder on the belt, tracking the belt movement]and the robot picks the correct ones to fill up.

There was a camera mounted about 2 meters back on the conveyor which snaps the images of the parts coming in and the down the conveyor, the robot picks it while it is still moving on the conveyor and place it in a regular fashion.

I am familiar with shift registers working on an event change, but not on encoders. Can anybody please explain what is the concept of this shifting being tracked. I found a link of the flex picker on Youtube.


http://www.youtube.com/watch?v=U3lz6TXTr88


Thank You
Best Regards
____________

I am familiar with shift registers working on an event change, but not on encoders.

Click to expand...

Consider each pulse from the encoder as an "event".

More info is needed for the best answer but....

bernie_carlton said:

Consider each pulse from the encoder as an "event".

Click to expand...

??????? That is a lot of events.

I use a circular queue. Usually the object goes into the queue at a the same location. I store the current encoder count in the queue. Other events will happen at fixed number of counts down stream. Now now you want till the encoder has increased by that number of counts and then activate the event.

Inspiration.
http://www.youtube.com/watch?v=wg8YYuLLoM0&feature=related

I have an example using our controller with code. I was thinking in terms of patching knots in veneer. I have only one X and one Y axis that go from defect to defect patching them.
http://www.deltamotion.com/peter/Videos/XYSynch.mov.ff.mp4
If you want to see the program
http://www.deltamotion.com/peter/Videos/XYSynch.zip

Notice that I used a task just to simulate a video system adding points to the queue at relatively random intervals.

chavak said:

I am familiar with shift registers working on an event change, but not on encoders. Can anybody please explain what is the concept of this shifting being tracked.

Click to expand...

As Bernie Carlton states "Consider each pulse from the encoder as an "event".

The primary difference to consider between an standard input and an encoder input when applied to shift register tracking is whether the hardware is capable of supporting the much higher frequency of an encoder.

In many PLC's this is achieved using a High Speed counter input [from the encoder] with a comparison/lookup table to trigger various events at specific positions [number of encoder counts].
The encoder input is usually an interrupt type input to ensure pulses are accurately captured.

If you are planning on using and encoder for tracking then selection of the hardware is VERY important.

Noooooooooooooooooooooooooooooooooooooooo!!!!

BITS N BYTES said:

As Bernie Carlton states "Consider each pulse from the encoder as an "event".

Click to expand...

So what happens if each pulse comes too quickly before you process the previous pulse. Our controller can scan at 4K Hz and that is MUCH faster than a PLC can scan yet PLCs routinely handle of pulse rates of 20K hz or 5 times faster than we can scan let a lone PLCs. Unless you have a very slow encoder and not using if to synchronize to as in the ABB or my example, you shouldn't even consider a pulse as an event. Wrong wrong wrong.

In many PLC's this is achieved using a High Speed counter input [from the encoder] with a comparison/lookup table to trigger various events at specific positions [number of encoder counts].

Click to expand...

Yes, Yes, Yes.

The encoder input is usually an interrupt type input to ensure pulses are accurately captured.

Click to expand...

The encoder doesn't really generate interrupts. It is good if the counter can generate interrupts after it counts down to 0 or up to a count. In this case each pulse is not an event. This technique is good. What is still necessary is a queue of events. After the last event is fired the PLC must search through the queue to find the next event that will fire and load the counter accordingly. This is a very advanced technique though.

If you are planning on using and encoder for tracking then selection of the hardware is VERY important.

Click to expand...

Yes, a lot depends on the application. Motion applications are much more demanding and require higher resolution encoders. If the conveyor is very slow and the positions are that critical you may be able to say each pulse is an event but this technique will not work in all situations. Also, if you do say each pulse is an event the what do you do each event or pulse? Scan everything in an interrupt? That isn't good. It is better to queue the events so you know what will be done next and not need to waste time. Also, if you know what even is going to happen next then you know how many pulses you have to wait so there no need in treating each pulse as an event.

Wow, this tracking malarky is beginning to sound tricky and complex.

It's sometimes hard to disassociate a simple question from what you yourself are involved with.

I've been involved with tracking objects for quite some years now and seen many ways of doing the same thing, some good some not so good. There's more than one way to skin a cat as they say, whats perfect for one application maybe overkill for another and insufficient for others.

Most of the tracking I've been doing has required spacing of around 60mS per increment and I have seen encoders used and simple proximity switches picking up on manufactured cams, both adequate and does the job.

In most tracking I've done I wouldn't exactly call each pulse an event, the event is usually once the tracking determines an object is at a decision point.

The most common method I've seen and in my opinion the most cumbersome involves moving whole tables per pulse, some include all data belonging to the object as well (yuk). Others include moving ID's which point to data. Some the ID's are static, some use FIFO's and some rotate.

As long as it does the job. The faster the object moves and/or the more accurate it needs to be by the way of increment (inches or fractions of an inch) will determine the complexity required.

The Tracking that I have done is dependent on the application

for a cartoner the tracking is "Per machine index" so once each product the tracking increments

for tracking loose product on a conveyor I prefer to do like Peter a FIFO queue

ie when the product is detected capture the current encoder position and then use that to track its location on the conveyor - I prefer to do all of my maths when I detect the product so I calculate the "Reject" position and then wait until the encoder position is there and perform the "Reject" action

The benefits of a FIFO mean that you can be tracking none up to many products all at the same time.