The client has determined a steady state acceptable error of 1 mm.
He is asking for a lot even with the best controller and mechanical and hydraulic design. I see this all the time. Some sanity calculations are required.
The best velocity resolution is 0.00025m/0.0005s = 0.5 m/s during the scan time of 0.0005s the actuator position may be 0.5m/s*0.0005s=0.00025m. This is one term in finding the best error that is achievable. This looks fine on paper if everything else worked instantly. Hydraulic valves take time to shift. Fast one can be fully opened in 8 milliseconds but that is assuming they are given a 90% to 100% control step signal. That will not happen if you want to smooth the ramps. A fast servo valve can cause more hydraulic shock than a bang-bang valve because the servo valve can open faster or close faster than a bang-bang valve. Oil also takes time to pressurize so that a force can build up. This takes only milliseconds but your actuator may be a long way over the 1mm error limit.
I'd like to identify what the minimum sample rate I can use for acceptable control would be, thus, mathematically eliminating this as a potential solution. What the aforementioned data means to me is that I can expect at most to see a pulse at max speed of 2800 per second, or .000357 seconds per pulse.
That is slow, in fact it is too slow. From my calculations above you can see it is better to have much finer resolution. It would be best to have feedback counts in 1,000,000 counts/second range. However, there is a practical problem with this. The high resolution feed back devices that are ideal for velocity control may not stand up to the shock. Both factors must be taken into consideration.
Because of the pressure issues you mentioned, missing a pulse is highly undesireable, so my scan time would need to be faster than 357uS at all times.
From what you said above 0.00025(m/c)/7(m/s) = 0.0000357(s/c). You lost a decimal point and you really need to count the number of pulses you get per scan and not the time between pulses. You get about 14 counts per 0.5 millisecond scan. Some times you will get 13 counts, most of the time you will get 14 counts and sometime you will get 15 counts but the difference between 13 and 14 or 15 and 14 is about 7 per% or about 0.5 m/s in velocity error. It may be possible to get down to 0.00025s scans but then the velocity resolution rises to 1 m/s. Decreasing the scan time without increasing the feedback resolution doesn't always get much improvement. Getting good speed control will not be easier with faster scans unless the resolution is better.
Can you validate that I am on the right track here?
I think your concerns about speed are valid. I think the specifications are unrealistic in the real world no matter how good the controller, the valve and machinery is. The attitude of the customer needs to change from I want 1mm resolution to I am willing to pay for the attempt to get 1mm resolution. If not you will be on 'mission impossible' aka project from hell. Sometimes I have been surprised.
If so, I think I can confirm scantimes that are possible with the given controller and determine whether this is a maybe solution, or a not possible solution. Thanks for the input.
Russ
Note, to everyone else. I had sent a PM to Russ with a link to videos that shows how we ensure our scan times are synchronous and deterministic at 0.5 milliseconds
This is also why sweating the code speed details like avoiding divisions and mod operators is important. Processing speed is important. See Alaric's quiz thread.