encoder position-scale vs encoder-scale
jschoch opened this issue · comments
Please correct me if i'm wrong but it doesn't seem like there is any consideration between encoder position-scale and encoder-scale. From my research:
position_scale should be the machine units per encoder pulse. This should be used to calculate "the gearing" of G33/G76/G95 moves and should account for leadscrew pitch, gearing, etc so that G33 can know how far to move.
encoder_scale should be the pulses per full revolution of the spindle. This should be used to calculate RPS.
In generated comp it looks like you are using rio.spindleN.position-scale to calculate the RPS, but this isn't correct if you look at the comment here: https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/components/encoder.c#L135
and the actual calculation here: https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/components/encoder.c#L492
Maybe something like rios.spindle_0_revs_pulses_per_revolution => spindle.0.scale
it is all very very confusing so i'm maybe just confused.... I'm all for more verbose names here since this is not very easy to reason about.
you're absolutely right, at the moment it's confusing me too.
I'm going to test the lathe again tomorrow.
but, please do not mix the old LinuxCNC code with the new riocore code,
there are much difference
notable that the encoder breaks at high speeds. My "scale" is 360 ( 360 CPR encoder, though it should be 1440, but i don't know how to set true quadrature mode). and when the spindle is > 400RPM the RPS value drops to zero.
For some reason there are not any clear docs with clear examples. The forums all have mult and abs and lowpass which makes looking at it make you want to poke your eyes out. side rant but the lack of syntax for "net" is infuriating.
Anyway, i'm guessing there is a cast or compiler thing happening to cause the issue but I haven't looked at it closely yet.
i have commit 2 fixes
*setup scale/offset via setup-gui
*allways write scale/offset to hal if set
"quad_type": 4 is 'true quadrature mode '
EDIT: my mechanical rotary encoder (20ppr) needs 4, but i think my z-encoder needs 2 to reach the right value :(
BTW: this cheap china 'optical' encoder are not optical ! there are absolute magnetic encoder's inside, i don't know how fast they can go
ok, one problem i can see (i try some things with normal encoder):
as you say, we need an average or something like that, there are calls of the convert function without step changes.
wondering if rtapi_get_time(); maybe safe.
http://linuxcnc.org/docs/html/man/man3/rtapi_get_time.3rtapi.html
The note says
Certain versions of the Linux kernel provide a global variable cpu_khz. Computing
deltat = (end_clocks - start_clocks) / cpu_khz:
gives the duration measured in milliseconds. Computing
deltat = (end_clocks - start_clocks) * 1000000 / cpu_khz:
gives the duration measured in nanoseconds for deltas less than about 9 trillion clocks (e.g., 3000 seconds at 3 GHz).
I also wonder if the variability in sending via udp skus the accuracy since the timing isn't really time between pulses but rather time between pulses + UDP overhead.
linuxcnc using this time-source, so it can't be so bad :)
maybe we can test send a time stamp from the fpga in each frame and look if it's better
"The resolution of the returned value may be as good as one nano-second, or as poor as several microseconds. "
i recall reading several places in forums/docs that it wasn't a good idea to use.
apparently the mesa sends timestamps and uses them for corrections.