×
INTELLIGENT WORK FORUMS
FOR ENGINEERING PROFESSIONALS

Log In

Come Join Us!

Are you an
Engineering professional?
Join Eng-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Eng-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Jobs

Encoder project

Encoder project

Encoder project

(OP)
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?

 

RE: Encoder project

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
www.gke.org
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.

RE: Encoder project

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?

RE: Encoder project

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?

RE: Encoder project

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.
 

RE: Encoder project

(OP)
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

RE: Encoder project

(OP)
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.

RE: Encoder project

(OP)
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

RE: Encoder project

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

Gunnar Englund
www.gke.org
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.

RE: Encoder project

(OP)
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?

RE: Encoder project

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 http://samplecode.rockwellautomation.com/idc/groups/literature/documents/in/1734-in003_-en-e.pdf

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
www.gke.org
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.

RE: Encoder project

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.

RE: Encoder project

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.  

RE: Encoder project

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.

RE: Encoder project

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.

RE: Encoder project

(OP)
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?
 

RE: Encoder project

If you answer my 16 Dec 11 23:55 question, I will not bother you any more.  

Gunnar Englund
www.gke.org
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.

RE: Encoder project

(OP)
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.

RE: Encoder project

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
www.gke.org
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.

RE: Encoder project

(OP)
Thanks again Skogsgurra, I have already check on the filter options, and that's why I am working to get the oscilloscope, with the different options (except for the 50 Hz which basically filter my application frequency rate) is doing what I described in my post of 2 Jan 12 12:17 and agree with you on the time I have been dealing with this and believe me many many things have been excersised not to mention that the controls guru is also looking at this, no success so far

RE: Encoder project

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?

so how is the point io bus configured to bring your stream of pulses from the point io module?  Just because you have a module that can handle the pulses VHSC module, can the point io bus or what comms are you using to bring it back to your plc?  If its a slow update you would get the jump that you describe.  Depending on how many devices on your network you will probably get erratic behavior.  A better design would be to have the encoder input into the local PLC rack, so that you get the speed of the backplane that the PLC is using.  Then you would know that the behavior you are describing is not the  network.


This below depends on if your vfd P can handle the below, otherwise you need plc.

Is the encoder 24vdc rated?  Maybe you can use a dc input card wire the a+- b+- to four inputs on this card.  then put your update time down to .2mSec on the card.  Then put this program in a either a periodic task or a input interrupt task.  If you check the inputs on the card and then put the 1st input to trigger the interrupt task then you will have a 4 input encoder on the local rack.  Hopefully your following what I am saying.  Any way try this to see if the card will do this.  Do a trend to see the encoder pulses this will tell you that you have correct input looking square wave from the encoder.  Dont need a scope i think.

RE: Encoder project

You always need a scope, dude. You are blind without one.

Gunnar Englund
www.gke.org
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.

RE: Encoder project

(OP)
Setup is as folows 1 main PLC rack with 1 1756-EN2T module which will communicate with 16 Point IO (1734-AENT) 12 out of these are with the 1734-VHSC, communication setup is autonegotiate.

At the begining we have periodic tasks but we have now the encoder routines on a continuos loop in the main task, the RPI setup is as follow: 1734-AENT 10ms 1734-VHSC 5 ms.

The encoder is 24 rated model number is given on my first post

RE: Encoder project

that wont work.  Put your encoder in the same rack as your plc.  do the work that I suggested in the 2nd paragraph.  Ethernet will never get your stream back fast enough.  

Everytime your ethernet takes a burp you get that delay.  encoder wont work in a continuous task.

RE: Encoder project

Getting the initial count/resetting the counter at product entry sense is probably more important. Then, at some encoder count you can begin your decel, which naturally gives you higher timewise resolution in encoder reads.

RE: Encoder project

(OP)
Ok back again, after numerous trials here is a summary which I hope help endevours of someone trying to implement positioning without the use of servos.

1. Light arrays as measuring device are not suitable for this kind of applications (do not want to mention model and or manufacturer) as they react incosistently time after time, we send one load 50 trials triggering a timer which counts from when the DLA was blocked until it was clear and then the time elapsed was FIFO, I noticed about 80 msec difference several times, at full speed this was an estimation of about 2.2 inches shorter of the actual size of the product. A different type of photoeye will be used instead with a faster response time.

2. Point I/O with VHSC is slow as they have to communicate to the main rack the fastest it can go was 4 msec on the Ethernet adapter and 4 msec on the VHSC before faulting the network but still this was not enough to have an pulses counts on time and I have to mention that we only have part of the total network setup I would not imagine how slow it can get with all the Point I/O adapters connected. We even tried a ControlNET adapters because we were told it was for time critical applications and it was even slower than the Ethernet, how we figured out there was communication issues? We setup a FIFO which after one second snapshot the encoder pulses then 2.5 sec after snapshot encoder pulses again, the diference between the first and the second snapshot was then FIFO, at full speed there was an incosistency of about 35 to 37 pulses several times once in a while in a randomly manner, these 35 to 37 are about an inch based on the gearing and encoder PPRs.

3. Since VFDs start-stop are going through Point I/O we IOT them right after we command to stop with ONS to not overload communication link by IOT always.

4. The encoders were wired directly to 1756-HSC on the main rack as well as the measuring photoeyes to avoid any communication lag time, this improve by much our initial results, trials todays gave us repeatable results on 2 conv positions of about 3/16 variance or +/- 1/8" of an inch.

So, if you want to do something similar do not go through Point I/O ALWAYS wire directly encoder to the main rack as well as the measuring devices, an ensure that measuring devices are capable and fast for the application. Still this isn't finish yet, we are not looking for accuracy in the position but repeatibility with +/- 1/2" and what we have done has lead us to target those results and we are back in.

Opinions are welcome

RE: Encoder project

As far as the networks go, the only one that can take the speed of an encoder is 12MB profibus.  Its funny the backplane on a siemens 400 processor is slower then this speed of profibus.  Thought this was kind of a neat feature.

All i can say as opinions goes,I hope this was a painful memory, then at least you will remember this the next time.

 

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Eng-Tips Forums free from inappropriate posts.
The Eng-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Eng-Tips forums is a member-only feature.

Click Here to join Eng-Tips and talk with other members!


Resources