Encoder connected to sim-encoder

Hi all,
I am trying to simulate one of my position feedback with a simulated encoder. I therefore connect a sim-encoder phases pins to an encoder component phases pins. I have noticed that I get a small jitter. The sim-encoder velocity is nice and smooth as it is linked to a pos-cmd then I got a encoder.N.velocity which present a small square (discret) oscillations around the target value. 232 to 238 mm/s for the target speed of 235mm/s.

Is there a way to totally get rid of this jitter on the encoder velocity signal? I guess this is related to all my threads speed compared to the count rate.

In my ini file:
BASE_PERIOD = 100000
SERVO_PERIOD = 100000
TRAJ_PERIOD = 100000
In my hal file:

loadrt threads name1=very-fast-thread period1=50000 fp1=0

And then I put, to simulate a 100 pules encoder with a 200mm circumference encoder wheel :

addf encoder.ipdate-counters very-fast-thread
addf encoder.capture-position servo-thread
setp encoder.0.position-scale 2 #400 counts per revolution of 200mm circumference encoder wheel: 400/200=2

addf sim-encpoder.make-pulses very-fast-thread
addf sim-encoder.update-speed servo-thread
setp sim-encoder.0.ppr 100
setp sim-encoder.0.scale 200

My maximum velocity is about 240mm/s which gives 240/200 * 400 counts / s = 480 counts / s so 1 count takes 1/480 of a second so about 0.002s or 2 ms. So even my slowest thread being actually at 100000ns =0.1ms is 20 times faster than my expected counts rate. So I am surprised to still have a small jitter while I actually have my threads frequency at least 20 times the expected count rated where only 2 is recommended.

Increasing the threads frequencies (ie decreasing their period) to those values did decrease a lot this jitter but I am eventually getting closer and limited by the computer max jitter: Would you think that using a ddt on the encoder raw count then a scale over it (or the other way around) would give a smoother signal?

Many thanks in advance for your thoughts and help.

Nicolas

Hi again,
I tried the ddt over the rawcounts pin and I think I observed something related.

The ddt of the rawcounts is acutally going to jigger a lot from the value 0, when no count has been registered between two time step and the max velocity when the rawcounts is updated from one value to another between two time steps.

It looks that the jigger I got on the encoder velocity pin is actually syncrhonized the same signal where I did the ddt on the rawcounts then scale. So I suspect the encoder velocity to be based on a ddt but there is on top of it a filter or another process which does not put back the velocity value to zero when the rawcounts stay the same between two time steps. This process somehow let the velocity pin fluctuating between two values.

I have not had a look inside the encoder component yet as I am not familiar with C. But definitely worth to have a look as I would like eventually to write my components to.

Nicolas

The encoder component does velocity estimation to get higher resolution than is
possible with straight counts/sample_time DDT. Basically it works by synchronizing
the sample period with the counts so that instead of using counts/sample-time,
(which might be 1,0,0,0,1,0,0,0 if moving slowly etc) it uses counts/time_between_counts.
The time resolution depends on the base thread period.

Mesa and other hardware encoder counters do this also but of course use a
hardware timer to measure the time difference between counts.

Hi,
thank you for your answer. So would it be possible with this velocity method evaluation to get rid of the jitter, small oscillation or is it inherent to the counting method? If we can get rid of it, it there a minimum condition on the thread period regarding the pulse/rate?

I am just trying to get the best velocity signal as I might be ending up using it in a PID loop in position control but using the feedback-deriv input pin so the velocity speed feedback. Therefore I would like to avoid oscillation in my feedback signal but would like to have it as precise as possible as much as I can.
Thank you,

Nicolas

There is always going to be some jitter from 2 sources

1. Time resolution when measuring count-->count times
This is a bigger factor with the software encoder since the
time resolution is limited by the base thread rate

2. Quadrature fidelity
For cases with only 1 count or less per sample, the actual width of
the quadrature pulses and their deviation from perfect 90 degree phasing
cause a direct velocity estimation error.
(this error gets divided by the number of counts per sample so is most apparent at lower speeds)

There are partial workarounds for this error but neither the software
encoder component nor any of the LinuxCNC hardware encoders
that I know of implement these schemes

Hi Andy,

I was just putting a sim-encoder to simulate my future encoder which is going to be connected, just connecting the phase pins between my sim-encoder and encoder components. Although do you think that the fact I am using a sim-encoder is increasing the jitter on my encoder velocity output signal too where the real system, with an encoder system itself will just suffer from the jitter of the encoder?

Thank you,

Nicolas

Hi I tried swapping the order, without any noticeable results.

I will get my encoder quite soon so would be able if the real one plugged on the shaft actually gets a better result.

I am also trying to create a PID position loop based on the encoder information, I am just then wondering if it is a good idea to use the velocity of the encoder as a feedback-deriv of my PID component if I still got jitter onto it.

Thank you,

Nicolas

Any velocity estimation will have jitter but consider how bad jitter is with just dp/dt

( Without any low pass filtering, any dp/dt velocity calculation when the count rate
is lower than 1 count per sample will give a series of 1/dt and 0 velocities! )