High resolution linear encoder & 7i77

Hello,

I've got some questions regarding LCNC capability to compensate ballswcrew error.

But first quick view on my hardware:
Ballscrew 5mm pitch (sorry metric here) dual nuts to prevent backlash.
Rotary encoder (Heidenhain ERN 180, 5000 pts) will goes directly to the drive (Etel DSB2P) and will be configured in speed mode (+-10V)
Linear encoder (Lida 28 0.2 mm period) to 7i77. Low resolution, I need to interpolate; 12 bits max, so it will give me 48 nm of resolution.
Thermal compensation will come, but after.

At max speed 0.125 m/s (Limit set to 1500 rpm) gives me 2.6 MHz TTL output.

For the moment I've just finished mecanical welding, but I got most of the electrical hardware.

So; If i'm going to run on 12bits, I will need a pretty fast computer, and a good one; i'm planning to run the servo loop at 6 KHz to match my drive position loop frequency; and increase 7i77 multiplexing speed. It seems possible (manual say so) and I will shorten cable.
Computer and 7i77 will be in aluminium box to avoid electrical noise.

Time for questions:

1°) What will be the maximum lenght of the cable to get; let's say; 3-4 MHz count rate ? Is 25 cm (10") short enough ? less ?

2°) I've got access to laser interferometer to calibrate my ballscrew, I know LinuxCNC does that, can i input on the file many point as i want ? Interpolation between thoses points is linear or tangent ?

3°) Does the system can use all of this linear resolution ? (I think it will be usefull for the servo loop, buy maybe it's too much).

Many thanks.

See comp in the axis section of the ini.

linuxcnc.org/docs/html/config/ini_config.html#sub:AXIS-section

JT

3-4 Mhz is possible with the standard (6 foot) cable and a bit of skew adjustment.
also if you only need 3 axis of encoders you can run them non muxed and get
~8 MHz count rate

MrFouFou wrote: So; If i'm going to run on 12bits, I will need a pretty fast computer, and a good one; i'm planning to run the servo loop at 6 KHz to match my drive position loop frequency; and increase 7i77 multiplexing speed.

I don't think that increasing the servo thread frequency increases the multiplexing speed. I believe that the multiplexing is between the FPGA card and the adapter card.

If you have to back-off from the 6kHz servo frequency I don't actually think it will matter much.

BigJohnT wrote: See comp in the axis section of the ini.

linuxcnc.org/docs/html/config/ini_config.html#sub:AXIS-section

JT

Thanks for that, so it's 256 value per axis, but interpolation between thoses points are linear or tangent ? (just for my knowledge)

PCW wrote: 3-4 Mhz is possible with the standard (6 foot) cable and a bit of skew adjustment.
also if you only need 3 axis of encoders you can run them non muxed and get
~8 MHz count rate

Unfortunately I will run a 4th axis later (with a 72000pts TTL encoder)

andypugh wrote: I don't think that increasing the servo thread frequency increases the multiplexing speed. I believe that the multiplexing is between the FPGA card and the adapter card.

If you have to back-off from the 6kHz servo frequency I don't actually think it will matter much.

I understand the same, I would like to use 6kHz servo thread because in speed reference mode, my drive update the analog input at 6kHz.

There really no major advantage to running a velocity mode drive via a position mode PID loop in linuxCNC
at higher that 1-2 KHz in most cases (assuming the velocity mode of the drive works well)

Where it might matter is when you have extreme acceleration
(so the chord errors caused by say 1 KHz velocity step intervals are significant)

It also may matter with high acceleration coupled with high accuracy.
(Note that high accel and high accuracy dont tend to get along because of the elastic nature of the hardware)

The fact that the drive samples the analog input at 6 KHz is not really important
(well only important in that you may have up to a 166 usec delay from a linuxCNC PID update
to when the drive notices)

In fact because of this it may in fact be a bad idea to run linuxcncs servo thread
at the same rate as the drives sample frequency since it will cause a low frequency beat
modulation of the command-response delay since the frequencies will not match exactly.
A more randomized beat pattern may well work better