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?
Any advice?





RE: Encoder project
TTFN
FAQ731-376: Eng-Tips.com Forum Policies
Chinese prisoner wins Nobel Peace Prize
RE: Encoder project
Gunnar Englund
www.gke.org
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.
RE: Encoder project
How is your encoder implemented?
RE: Encoder project
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
RE: Encoder project
RE: Encoder project
- 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
- 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
Gunnar Englund
www.gke.org
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.
RE: Encoder project
RE: Encoder project
Yes, I mean filter frequency. As shown on page 22 (I think) here http:/
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
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
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
RE: Encoder project
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
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
Gunnar Englund
www.gke.org
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.
RE: Encoder project
RE: Encoder project
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
RE: Encoder project
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
Gunnar Englund
www.gke.org
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.
RE: Encoder project
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
Everytime your ethernet takes a burp you get that delay. encoder wont work in a continuous task.
RE: Encoder project
RE: Encoder project
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
All i can say as opinions goes,I hope this was a painful memory, then at least you will remember this the next time.