AD DL05DR and an encoder

Hello,
I have another question about my part tracking app.
Thats to all those that have been such a help so far.

I am working on an app where I have to track a container between an inspection station and an eject station. I have an encoder hooked up the HSC and I have it working for a single container.

My next step is to add tracking for multible containers. I an stearing away from shift registers because if the last few containers are bad, there will be no inspection behind them that I can use to shift them into ejection position and there may be a variable number of containers between the inspection station and the ejection station.

I was thinking a FIFO stack would work much better but I can find no documentation on how to setup a FIFO with a DL05DR. The Automation Direct sales guy told me on the phone before I bought it that it could do fifo stacks, but I can not seem to find any documentation to help me set one up.

Does anyone have any suggestions? I need to have this done by Sunday evening so any suggestions would be very apriciated. Thanks in advance!

Greg

http://support.automationdirect.com/examples.html

There is a FIFO example there.

I an steering away from shift registers because if the last few containers are bad, there will be no inspection behind them that I can use to shift them into ejection position and there may be a variable number of containers between the inspection station and the ejection station

Click to expand...

Greg,
A variable number of containers is NOT a reason not to use some bit-shift registers. If you have an encoder, and it is referenced to the conveyor that is moving the containers, then the bits only shift when the containers move a known distance, so what is the problem? A bit-shift register, properly implemented, gives a graphical representation of the exact movement of each container on a section of the conveyance, regardless of how many there are.

If the last few containers are bad, then the inspection station should set the "eject" bit for each bad container, and when it arrives at the ejector, the bit-shift register will trigger the ejector. Another reason to USE bit-shift registers.

The only reason I can see NOT to use bit-shift registers is if you have several "things", or parameters, that are inspected, and you will need a bit-shift register for each, and if there are more than 3 or 4, then a FIFO word register may be more practical.

That is a good point. i'll look into that.

What if my encoder is pulsing faster then my scan times, then wouldnt I lose a lot of accuraucy since I would not be able to shift on every pulse?

gosenbach said:

That is a good point. i'll look into that.

What if my encoder is pulsing faster then my scan times, then wouldnt I lose a lot of accuraucy since I would not be able to shift on every pulse?

Click to expand...

Every pulse? It would amaze me if that was ever necessary. Using a 100 ppr encoder would mean moving 100 parts per revolution, a 1024 would mean 1024 parts per revolution. Take the 100 ppr encoder at 1 rpm, that would mean 100 parts a minute...that may work, depending but what if the system runs at 100 rpm? That would be 100 x 100.

Encoders usually pulse faster than scans but high speed counters offer the ability to work with the counts.

I have a 600 ppr encoder on a shaft turning ~175 rpm

My scan time is currently around 2-3 ms so I figure I am getting about 5 pulses per scan.

I have no idea what any of this has to do with the price of beans in China.

Lets see; 600 ppr @ 175 rpm, that would be 105000 counts per minute, divide that by 60 equals 1750 divided by 1000 equals 1.75 times 2 would be 3.5, times 3 would be 5.25.

Ok that is out of the way, why is it relevant?

going back to the idea of using the pulses from my encoder to shift bits in a shift register.

(let me take this oppertunity to say that I am rather inexperienced in the world of plcs)

I am trying to figure out how to track fast moving parts on a conveyor. Lancie1 had the idea of using the encoder pulsed to drive a shift register to track my parts between the inspection station and the ejections station. I am just having trouble wraping my mind around how to accomplish that when I have more than one pulse per scan without loosing pulses and therefor loseing accuraucy.

thoughts? Thanks for the assistance on a Sunday BTW.

Others, like Lancie, can offer more than I can on details. What I can do is offer basic info that may help you "wrap your head around it".

Stupid analogy: You are going to fly to Hawaii on vacation, the flight is at 3 PM but they say be there by 1 PM to check in and for security issues. This has established a time "range" for you to conform too.

The same applies when using an encoder. Using time in hours you have 5 stations, 1 PM, 2 PM, 3PM, 4 PM and time to take out the trash (reject; 5 PM).

To make this simple your 600 ppr encoder could mean 600 counts for 1 PM, 1200 for 2 PM etc.

Basically what you are doing is FIRST establishing what station the part goes too, then count the pulses which tell you how far that part has moved to place it where it needs to be.

When using the counts you do not have to be exact i.e. 1 PM can be 550-650 counts to allow for timing issues.

My apologizes for not being explicit for an AD DL-05, I am not the most experienced there either. What I am fair at is pushing YOU to explain to ME what you want to do; which in turn usually makes YOU figure it out. Everyone once in a while I offer tidbits that can be used to help though.

In general do not worry about scan and counts, as long as you get counts per scan, just concentrate on getting counts that will give you position within the time frame you need them.

Again my apologizes for not offering specifics.

Thanks.

I'll let you know what I come up with.. I am working on somthing right now that I just hope will not be too bulky. If I can not get my current idea working in the next hour or so, i'll try to figure out how to use a shift register on this thing and make an attempt from a different direction.

RSDoran is exactly right. The number of pulses per PLCscan is not usually important, unless your conveyor is running at extremely high speed. I have never seen one that fast in the real world. Idealy, set your encoder so that it produces 1 pulse for some physical length of travel of the conveyance. 1 pulse per inch of travel has worked well for me in the past. If the encoder cannot be set that high, then set it at the closest possible range, and take care of the rest within the PLC program, using a high-speed counter to count the pulses, and a math funciton to convert a certain number of pulses in the equivalent physical travel of the conveyor.

If your encoder pulse = 1 inch of travel, then your bit-shift registers will be able to track every 1"-increment of travel of your parts conveyor, and locate each part at all times within a 1" errror. Normally a 1" increment is overkill, as most parts or packages are much longer than 1 inch.

ok, I have my program tracking my parts via a shift register which shifts ever 10 encoder pulses.

Is there a way to insert a bit into an active shift register?

Here is the scenario:

The part comes down the line (high speed, 800 ppm) and trips the sensor that initiates a bit into the shift register. Then I get an inspection result which I would like to insert into the shift register at the appropriate spot.

The reason is that my inspection can take anywhere from .02 seconds to .15 seconds and since my conveyor is running ~210 feet a minute and the part is fairly small, it is enough time to cause the ejector to miss the part. So if I initiate the shift register with the part present sensor, I'll always be right on but I would need a way to change the bit in the stack if the part is bad.

Or is that the wrong approach?

Greg,

You are getting there.

Here is one way to do it: You have one bit shift register that tracks the part by inserting a "1" everywhere there is a part. Call this the Part Tracker Bit Shift Register. Now at the inspection station, you can insert a "0" into the positions that need to be rejected. When the "0"s get near the ejector, then use the 0 value of the bit to trigger the ejector. Usually you need to trigger the ejector some distance before the part arrives at the ejector, to allow for the lag time of the ejector. Disadvantages: If there is no part in any particular position (bit = 0), the ejector gets triggered when it does not need to be triggered.

Second option, and the one most commonly used: Use the first bit-shift register to track the part, and additional bit-shift registers to track other parameters, for example, the second bit-shift register tracks only "Parts to be Ejected". Now you say, "What!, you mean I need more than one bit-shift register?" Think about it, they are cheap! You could use the initial sensor trigger for the Part Tracker BSR, but the second one gets triggered by the inspection station result. If you use a Bit-Shift Left (SHFL in DirectSoft), there will be a constant "offset" between the two. This offset can be added to the "Parts to Be Ejected" position to make it equal to the "Part Tracker" position. Or instead, you can use a Bit Shift Right (SHFR) and eliminate the "offset". The Bit Shift Right essentially shifts in reverse, so that the trigger point can be a variable position, with the end point (ejection trigger point) always the "0" bit position.

Then, when the "part to be ejected" arrives near the ejector, you look in the Ejector Bit-Shift Register, and if there is a "1", you then also look in the Part Tracker BSR, and if it has a "1" in the same equivalent position, you can say, "Hey, there is a part here, and it needs to be ejected. Trigger the ejector." If there is no part in the Parts Tracker, then no action is performed. In this fashion you add as many separate Bit Shift Registers as you need to take care of all parameters of the part that need to be tracked, such as size, color, and so on.

The way you figure out where to eject the part is to measure how far your conveyor travels for each bit-shift, then measure how far it is between your initial bit-shift sensor and the ejector, and then figure out how much lead time you need between ejector triggering and actual ejector performance.

You use the Bit Shift Register exactly as a graphical indication of where each part is. The position (length) from the trigger point can always be calculated and anticipated.

I'll give the 2 SR method a try. I'll let you know how it goes!

Lancie1 said:

Greg,

You could use the initial sensor trigger for the Part Tracker BSR, but the second one gets triggered by the inspection station result. If you use a Bit-Shift Left (SHFL in DirectSoft), there will be a constant "offset" between the two. This offset can be added to the "Parts to Be Ejected" position to make it equal to the "Part Tracker" position.

Click to expand...

Could you explane this a little further? Initially I was thinking that I could have the first SR clocked by the encoder with the part present sensor loading in bits for every part. then have the second SR clocked by the part present sensor so every bit there is an actual part and then set bits for the bad parts. but that puts me in a position of where if I do not always have the same number of parts between the inspector and the ejector, I will be off. In that case, I think I would want to be using a fifo stack insted of the second SR.

I think i am missing somthing with the SHFL... Is that to make my second SR always the same length as my first SR with the bad parts in the same position as the part in the first SR?

how would I make that work? (this is the first time I have done a lot of this stuff, thanks so much for the advice, it has been a big help so far)