How much resolution is enough for velocity control using an incremental encoder?

I did miss the 40K counts but who makes a 10K PPR encoder all the ones I have seen are 6K PPR or 24K counts max and they are hard to find
As for the HSC's the have been around for abut 30 years, one of the input words is real time frequency that you can set the update time for as low as 10 ms but for better accuracy you should set them close to the PLC read update time interval. most IO update are set at 100 ms default
A simple math function will convert to whatever you rate you need.
I have done it many times
As for the outputs on the HSC modules they can be configured to be controlled by the PLC and updated on the normal update scan or you can configure them to be controlled by the HSC module computer, you set them to turn ON and OFF based on the internal counts of the counter you want depending on how you setup the HSC module.
If the module is controlling the output the PLC can only look at their state at the normal IO scan
It is possible to have an output turn on and back off between the IO scan and the PLC will never be aware of it. I set them up all the time to control a feed solenoid based on a flow meter counts since they work outside of the scan time the are much more accurate and repeatable then what you could get through the PLC and IO scan.
It's been a while but I think with a single counter active the input pulse rate is 100 mhz I would have to look it up. It all in the manual

As for the 18 Bit absolute encoder they have been out their for many years and I think the 24 Bit and 32 Bit encoders are are more available and I am sure that their is a 64 Bit absolute encoder out their most of those also have a pulse output that you can use to monitor rate or speed if needed. If the encoder is mounter directly on the motor it works better but has a limited number of motor revolutions.
but all the absolute encoder have a built in design problem and that's slippage on contact wheels, that slippage changes with environmental change a temperature change can cause a measuring wheel diameter change in the measuring wheel, moisture in the air can cause slippage, dirt n the contact surface can change the travel distance. All of this should be considered when designing the system.
And them you have the problem with the cables the constant movement will cause the cable to break down. I had a client that always changed the cable at least every 2 years and they still had the problems I listed above
The best way to measure position and rate is with a good laser measuring system I did a crane system the travel was over 1,000 ft and we were accurate to about .10 in
and no maintenance issues. With the new ones you get a digital position back to the PLC scaled and ready for you to use.
Use an encoder for short distance measuring and speed feedback to have good stable speed control.
I have seen laser systems that will read distance to within a foot at at the horizon

This little project would be interesting to do but not difficult just put the right hardware together

Do let up know how you make out on this

@ASF there are no concerns about fieldbus polling in the mix, just PLC scan time. The PLC is an M580 with the FAST task running every 10 ms. The counter is an EHC0800 on the local rack running with the FAST task. The EHC0800 can do up to 10kHz.


Obviously more is better, but I need to make an assessment of what we have to justify making a change.


@Peter I'm trying to adapt a hydraulic winch to allow predictable joystick control under load. Currently the operator is needing to pull back on the joystick to compensate for the weight of the load, as if you just release a brake on a hydraulic motor, the fluid will slip past the pump and slowly cause the load to lower to the ground. So when we release the brake, we'd like to be near zero speed, and if the operator pulls back slightly, the load should rise at a low speed. This winch does a lot for us in a very complicated system, and if I told you everything it does it would ID our customers which is not cool, but just know that the rest of the system is not really in question here. I would just like to hear opinions on encoder resolution for PID control of slow velocities. If I can identify exactly how slow it will be practical to turn the winch with a given encoder, we can make informed decisions.

If you want an answer you must provide more information like how fast, how slow, the mass, how much travel per revolution. This should have been provided on the first post.


I have already provided the basics. 1 count per 1 millisecond is 1000 counts per second resolution. The circumference of the winch is not known do calculate how much each count represents.

I wonder if your customer is the same one that did this project raising the sections of the new bay bridge years ago. They used our controllers for that.

https://deltamotion.com/peter/Pictures/NewBayBridge01.png
This project moved very slow. The controller was updating every millisecond.



Yes, I am familiar with the problems of motor leakage. When the controller is active, the controller will maintain position even though there is leakage. I believe the new bay bridge project used a ratchet system so the winches wouldn't slip should the controllers lose power.

back.


You might consider using pressure sensors on the A and B port across the motor. This way torque/load can be measured and gains and offsets adjusted accordingly.



@Garys, the 24+ bit encoders are multi turn encoders. The extra bits allow one to keep track of turns which is good for measuring long distances but usually there are only 13 bits 8192 counts per revolution.

Thanks Peter, I was hoping to avoid divulging all the details, partly because I imagined there might be some formulas I could take away from this conversation to run through the calculation myself. We'll make one example, but we have machines of different sizes and I'd like to be able to reuse what we discuss here. That's mainly why I was discussing in terms of revolutions and not linear lengths.



In one example we have a 1 metric ton load carried by a winch 3 metres in circumference. The winch is capable of spinning up to 6 m/s. I'm trying to be able to discuss how slow is slow enough, but I imagine 0.1 m/s is a reasonable number. I'm choosing between keeping a 1000ppr encoder and upgrading to 4000ppr. Obviously 4000ppr is 4 times better for slow speeds, but how do I really determine how slow that lets me go?



So between the counting module and the encoder we already know the upper limit for how much resolution we can tolerate. Now given some detail about what a winch would look like, how do you judge how slow is practical for a given encoder, or vice versa? Everyone agrees more resolution is better, but at what point do you say it's "good enough" and just use the encoder you have, rather than upgrading? The benefit of not upgrading is that you get to reuse common parts.


How exactly would you make use of the pressure sensors? I've used them for certain applications but do you have an example of one where it enhances low speed closed-loop control?

If I understand good your winch is spinning at max speed of 2 rotations per second. With encoder that has resolution 4000 PPR you need 8KHz capable input, so it seems that you don't have problem.

Peter, any thoughts on my previous post?

A few things that may help you understand
You never stated what HSC card you are using so we have to generalize
The HSC cards all have independent processors to count the input pulses
Some cards have an input frequency of 100mhz
But they have to reliably count the 4 edges of the 2 input channels the count rate must be higher than 400mhz. in fact most count the pulses many times to insure they don’t miss an edge.
Most of those processors are running at maybe at 100Ps that 10 -12 power
The counts are placed in a common memory with shared access from both the PLC IO scanner and the HSC Processor
Depending on how you configured the HSC you may have 1 to 4 input words read by the PLC I-O scanner
You would also have inputs for A A, B B, Z Z they will have at least a Reset input and maybe others
These are all edge triggered inputs the HSC processor reads these inputs and updates the counters and the HSC outputs if they are configured to control them. All of this happens completely independent of the PLC processing.
I keep seeing people referring to the PLC scan times the PLC scan time has nothing to do with the HSC scan time I have to say it again they are completely separate.
If the HSC outputs are configured to be controlled by the HSC then the HSC processor turns them ON and OFF based on the counter accumulated pulse counts as programmed.

I noticed that you want to use an encoder with a cable and winch system.
That not a good idea about the best repeatability would be about .25 in at best. There are just too many variables with a cable winch system The weight of the load will cause the cable to stretch different amounts. Old cable verses new cable will stretch different amounts. The way the cable wraps up on the drum can cause a large difference in the final position. There are other variables to consider as well.
I would look at other methods to measure the position such as a Laser or other measuring system .
If you have to consider the weight of the load when measuring then you will never get good repeatability.

Gary, as I said above: The counter is an EHC0800 on the local rack running with the FAST task. The EHC0800 can do up to 10kHz.


Based on your numbers, are you saying that I need a 32kHz counter to use a 4000ppr encoder at 2 revs/sec? Or what is the significance of discussing the internal frequency?



I understand that the PLC scan time is irrelevant to high speed counting. You don't have to repeat yourself, I was never trying to get the two to align. My main question has to do with low speeds, where the PLC scan time is significant because it is running the PID, and if the pulses take much longer to reach an edge than the PID changes the output, I think we need to make special considerations for control at that speed.


Does anyone have any comments on that, or should we end this thread?

Just a few thoughts
The EHC800 is a poor choice for what you are trying to do
It does not except a quadrature input, it is strictly an UP Down Counter
And a rather slow one at that. It is designed to count switch closures in fact the manual has a section on how to setup the debounce for a switch.
When trying to regulate the travel speed at slow speeds the more counts per rev the better provided that you can also accurately count them at the highest travel speed.
From earlier post you want to maintain a constant stopping point by controlling the travel speed at slow speed. Without seeing the complete system it’s really hard to help you, having the right hardware is also important. If I remember this is a hydraulic motor if so, you will need a servo valve to control the flow to the motor ( Motor Speed) with any control system.
And as I stated before there are some inherent problems with using a cable and winch system that you will need to consider. I am still not sure if you want to have the PLC control both the speed and final position or if the operator is to control the final stopping position

As for the count input frequency 10KHZ would be at the very limit for the the motor speed but if you were to go over then you would lose counts
For this application you really should chose a counter card that can receive a quadrature input from an encoder that will also give you a rate value input

I agree, a faster input card would be ideal. If we can get some kind of concrete figures or even a rule of thumb, I could justify pushing for an upgrade, but it seems like this conversation only speaks to generalities.


I know from previous applications that the EHC0800 works in dual phase quadrature for incremental encoders. I won't bore you with reading the manual, but just know that the datasheet is incomplete in that fact.


Do you know of any counting modules for this platform that would give both a count and rate as output simultaneously? That would be another appealing factor.

According to the manual that HSC has a frequency mode that should work for you
Page 70
it updates the input to the PLC every 1sec
it updates the count register every 10 ms
for what you are doing that should work for you
also to help you out Dual phase is not quadrature it doesn't have the inputs necessary
In A and In B are just dual counter or they can be used for 2 separate counters

Thanks for being patient with me, Gary. Have a look at page 89 and 90 for quadrature. Is that where your 4x frequency number comes in, if you choose a Quadrature 4X setting then you can't use as high a resolution encoder?



https://download.schneider-electric...=EIO0000000318.12.pdf&p_Doc_Ref=EIO0000000318


My understanding is that frequency mode is not appropriate because it takes only 1 input and therefore cannot measure velocity, but only speed.