So, this one was not finished, lets continue.
How one calculates at what point method should change,
It depends on whether the timer/counter or the encoder is providing the best resolution. Lets say I have a 1 Mhz timer/counter and an encoder that generates 1000 pulses per revolution and my update/sample rate is 1 millisecond. If the shaft is turning 1 rev per second I will see one count every millisecond on the average but due to jitter I will see 0 counts sometimes and 2 counts other times. The difference in the detect speed over one millisecond is huge percentage wise. However, the timer/counter will detect 1000 counts between the encoder pulses on the average but due to jitter there will sometimes be a few more or a few less but if the amount of jitter is only 10 pulses then 10 out of 1000 is a small 1% error. Clearly it is best to use the interval between the encoder pulses to detect the revolutions per second.
If the encoder is revolving at 10 revs per second then we will detect about 10 counts per millisecond with a little jitter. Sometimes we will detect 9 counts and other times 11 counts but most of the time we should see 10 counts. The error is only 10% now but that is still too high.
At 10 revolutions per second the timer/counter will count about 100 counts on the average between the encoder pulses. If the jitter is lower than 10 counts then the error will be less than 10% and it will be better to use the timer. If the jitter is 10 counts or greater it will be better to use the encoder. However, once the rotation rate goes over 1 rev per second then time between encoder pulses start to become shorter than 1 millisecond and the CPU may not be able to handle the interrupts that quickly. Then it is best to use a FPGA ( field programmable gate array ). An FPGA can start the timer/counter right when the first encoder pulse is seen after the millisecond period starts. It then can save the time and the number of pulses. When the millisecond is up the CPU can read how long it took to read 9 pulses. This way the CPU only needs to do the calculation once per millisecond and the number of timer/counter clocks is divided by more pulses so this reduces jitter and error.
would it still be better to also implement ABG filter or similar that approximates position between calculations, could that be done?
[/quote]
Yes, it can be done. I am pretty sure this is how MTS or Balluff update the positions on their rods faster than what the rods can update. I told both companies how to do this a long time ago. They didn't listen at first but I played one off against the other until both listened.
I had a project where the data would come back every 10 ms but I needed the update every 1 ms for the control loop. I worked out this wxMaxima work sheet. I used array math instead of writing out the code like I did in the video.
If I define an matrix A such that the ABG filter is implemented as
x(n+1)=A*x
+K*(y(n+1)-x')
then the elements of A can be defined in terms of Δt. In the wxMaxima I used %delta.
Now initialize a matrix A using Δt and a matrix F using Δt/10. Then A is equal to F raised to the 10 power. The A=F¹⁰. So I can define sub periods shorter than Δt and estimate position, velocities and accelerations between the periods but I can only used the correction term K*(y(n+1)-x') when the position feedback is available. There will be small jumps in the position velocity and acceleration when the correction term is applied but it is much better than not having any idea of what the current state is between the position updates.
http://deltamotion.com/peter/Maxima/ABG.html
I told the MDT rod manufacturers about this trick a long time ago. The SSI MDT rods must look like they are updating synchronously to our controller when internally the updates are asynchronous. The rods must estimate where the magnet is when the motion controller needs the information which is every millisecond or half millisecond. The internal update rate on the rod varies depending on how far the magnet is from the head.
