Encoder project

[jamorenos]

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?

 

[jamorenos]

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

 

[controlsdude]

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.

 

[Skogsgurra]

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

Gunnar Englund

http://www.gke.org

--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.

 

[jamorenos]

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

 

[controlsdude]

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.

 

[automatic2]

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.

 

[jamorenos]

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

 

[controlsdude]

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.