Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations cowski on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

Encoder project

Status
Not open for further replies.

jamorenos

Electrical
Dec 8, 2011
11
Hi, I have a project in which we are using a Light Array photoeye to detect leading and trailing edege to size the product (22" to 39") and center it on a conveyor which is 4 ft long. Once the leading edge of the product is detected we capture encoder pulses (AB 845-DZ32BCH-C 200 Pulses por rev, Gearing combination give us around 9 pulses per inch). I am using a 1734-VHSC Point I/O to read the encoder pulses, the VFD to drive the motor is a PowerFlex 40P. The project specs says this conveyors runs 120 ft/min, my problem right now is that at that speed even that the calculation is right the product is off center depending if its a small or big product. One thing I have verified is that if a run the VFD slow and tell it to advance say for instance 108 pulses (1 ft) it does it right, but if I increase the speed to get the 120ft/min then I am off about 6 inches!!!

Any advice?

 
Replies continue below

Recommended for you

Is this the module where you can select filter time constants? If so, make sure that you don't have the 10 ms selected. With 200+ PPS, the 10 ms won't let much through.

Gunnar Englund
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.
 
this sounds much like the project I have in front of me, which I'm about ready to scrap. I have a photo eye detecting leading/trailing edge of from 8 to 52' bundles, an encoder running in contact with the bundles, which are cut / stacked on a 150' conveyor for packaging. Original equipment had utilized the vector encoder within a Powerflex 700, but because of slippage on conveyors, we went to direct contact encoder. We're trying for +/- 1/8" It generally works, but not reliably within our tolerances. Next to a fixed reference.

How is your encoder implemented?
 
Might be the slippage between the belt and package, when you ramp up and down to get the proper placment. Mechanical issue

Also, what type of control are you using on the VFD?
closed loop, V/f, open, etc? Control issue

Maybe VFD control will not get you the accuracy that you need. Could be a better application with a servo drive. Right equipment for this application?
 
Sounds like a classic example of using speed control devices to do the job of positioning, you may be able to get "close" most of the time. However to be accurate all the time you need to close the position loop. If this is not correct, tell us how the position loop is being closed and at what rate.
 
Thanks for all replies, application is open loop, we count pulses and based on that we calculate the position to stop to get it centered, slip is one factor affecting the position, other is the mean of measure sometimes it tells you the right size and sometimes is sligthly deviated down, in other words it tells you the product size is smaller that it is. If someone has face something similar and find a way to to resolve it please reply. thanks for your attentions
 
Ok so far this is what I have done:

- Relocate Light array or curtains (LC) Photo-eyes back about 1/2"
- Deccel time on the VFD (Powerflwx 40P) to 0.0
- Took one link out of the belt conveyor to avoid from travel after Stop commanded
- Slow down the conveyor in which the product is going to stop and the one previous as soon as the leading edge of the product makes the LC did not help
- Slow down both conveyors but instead of doing it until the LC is made, slow down once the head end photo-eye of the previous conveyor is made (to allow the measurement or size of the product is done slowly)
-Veryfied the speeds when running high and low speed and all conveyor match to the speed design

My toughts are to go closed loop system but a colleague thinks we might have some sort of lag time since we are using Point I/O through unmanaged switchs and back to a 1756-EN2T, he want to try a 1756-HSC and directly connect the encoders to the Controllogix Rack instead of the Point I/O, we'll give it a try, still any recommendation is welcome and appreciated.
 
Last couple of things today:

- Connect Channel B and configure for X4 Encoder to have 800 PPR (X1 = 200 PPR) this gives me about 36 Pulses Per Inch
- Created a program to Start the Conveyor to advance 12 inches at 40 ft/min (about 20 Hz VFD frequency)

Result is that is always off for about 5/16" to 3/8" and if I even try to run full speed as is originally supposed to be (120 ft/min) is eve worse when stops is off by 4 inches.

Should that suggest a closed loop?

One other question I have is that I am using a Greater Or Equal instruction to evaluate the current count, say for instance if you are 1 pulse less that the stop point and the next current count you get is 5 pulses more that will make you be 4 pulses off, is any other way to work this around? Just to mention LIM function won't work either

Thanks
 
Did you see my 9 Dec 11 10:48 question? What filter time constant do you have?

Gunnar Englund
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.
 
Thanks Skogsgurra, not clearly understand your question about Time contanst filter, there is a filter selection frequency which gives you 50 Hz, 500Hz, 5 kHz, and 50 kHz for CH A and CH B is this what you refer to?
 
Sorry, didn't find your exact module. There are those with a filter time constant and then some where the same thing is expressed as a frequency.

Yes, I mean filter frequency. As shown on page 22 (I think) here
Setting the filter frequency too low makes the module miss pulses as frequency goes up and setting frequency too high will let interference through.

Another thing that you need to consider is pulse duty cycle and phase shift and also base line and amplitude. What do the pulses look like?

Gunnar Englund
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.
 
Check my math, but at 36pulse/inch at 120'/min, your pulses are just over 1ms. Check the scan time on your main routine to see how many pulses could elapse before the next counter read, and what that translates into inches. Add to that in case your module is in an expansion rack for messaging. Add to that the worst case scenario as to when the counter or its contents are considered following a leading/trailing sensor mark.

To tighten it all up, I'd consider putting both your sensor and counter on a COS interrupt. That would allow you to decel your drive, giving you better resolution on subsequent counter reads. I assume your photo sensor has reasonable advancement to allow controllable decel.

This is after you've investigated and removed product slippage due to mechanics.
 
If I understand your application, your sensing leading/trailing edge, calculating mid point, then counting encoder pulses to advance to a 'counted' position. Closed loop isn't going to be much use to you if this is the case.

You MUST remove all slippage of product from the conveyor. Make sure your accel/decel is matched to the inertia of the product.
 
Most high speed applications that require you to advance a precise distance in a repeated motion use servos. Also, the friction on your belt is usually a soft plactic belt that can grip the cases. At least that is what i see used and have been in the material handling business for 15-20 years. Also, case types can not be higher than they are wider, so they dont fall over when you are stopping and starting.
 
controlsdude hit it the nail on the head.

If you want exact product placement, then a servo is the only method that will give the repeatability you need.

He is also dead-on with higher friction belts.

Also, I've substituted the use of chains with lugs instead of belts to help prevent the product and the conveyor from slipping. Just make sure you use a takeaway conveyor that is faster than the lug conveyor or the lugs will dig into the box when they reach the tail pulley.
 
Thank you Dan Stewart,

Please bare with me on this, facts:

-Conveyors belts are already designed for the product we are handling with no servos on it, in other words I have to make it work, mechanical eng is confident on us to make this work (as usual right?).
-There is one thing happening which is weird, I have setup a "watchdog timer" which takes the current measurement every 5 seconds and compare the difference between that and the previous reading to see if reapeatibilly give us the same count diference, and once in a while give me silly numbers for inttance if the difference is 900 eventually you get a difference of let's say 4092, we are using shielded cable and we grounded conveyors, shields and obviously the control panels to avoid this is caused by noise so at the moment I have to find out why this is happening has anyone experienced something like this?

If you see if I don't get a confident count how can I expect to have my control routine try to make the calculations for the positioning? Any advise will be appreciated.

One last question, how can I find out if the 200 PPR (800 PPR using X4 encoder mode) is enough for the 120 ft/min my conveyor is running?
 
If you answer my 16 Dec 11 23:55 question, I will not bother you any more.

Gunnar Englund
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.
 
Thanks Skogsgurra you don't bother me at all as I appreciate all contributions and/or comments answering your question I do not have an scope to check how the pulses looks like since I am new I am trying to get my manager help me borrow an scope from any of our supply vendor to check on this because I am also interested if there is any noise affecting the counts, if I get this figured out I will post it.
 
1. The setting of the filter is something you can read from the documentation.

2. You really need a scope. It is next impossible to find out what is causing this kind of problems without one.

Any scope will do. A simple USB scope, a Rigol, anything will work. And, if your boss thinks it is a good idea to buy a scope - which it is - and is prepared to pay to get the problem solved, then go for Scopix 7204. But be careful with the yellow ones!

This has been going on for almost a month now. What kind of operation is this? Development? Production? Prototyping? In any case, one month without results is totally unacceptable and something needs to be done.

Gunnar Englund
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor