Spindle and encoder

I chose 140 because in your previous tests the
spindle did not turn until you go to around 140.
(so its about the value needed for 0 RPM)

You might try lowering the OUTPUT_SCALE somewhat
though that will cause some non-linearity at the top
of the speed range. that is , setting it to say 2500
should get you closer an lower speeds.

If you want to correct the errors more completely you will
probably have to use lincurve.

Thanks. Altering the bias improves the spindle a lot starting at low speeds.

Motor 6100 rpm max * 0.49 pulley ratio = 2989 max spindle speed ini and all spindle outputs

Start bias 0
s160 at 16 rpm

Bias 160
s160 at 156 rpm
s2735 at 2805 rpm
3039 ini all spindle outputs
s2735 at 2735 rpm
s2000 at 1675 rpm

It appears that some middle-range rpms don't match the spindle commands. Can the middle-range rpms be corrected and the entire scale from s160 to s2735 match? I might want to rely on g95 (ipr) entirely to maintain the same chip load if the middle-range rpms aren't matching spindle commands. I probably should make all the ini spindle outputs to 2800, reset the bias to 0 and test the lowest rpm at the spindle command to set bias again because the headstock spindle is rated at 2800 rpm.

I'd be willing to research lincurve if it could advantage making commanded spindle speeds more accurate. I have experienced programming low-level and mostly high-level program languages including C, C++, JavaScript and Python. Is a referable source or LinuxCNC file and readme.txt accessible and where so that I could view the lincurve algorithm? Does it only require initializing the variables for the lincurve and calling the function? Could the lincurve be operable in many increments or multiples of 1 rpm? The idea is the spindle-to-rpm equivalency iterated and operable with constant surface feet.

I located file lincurve.9.gz. I guess only 16 points are only allowed and maybe g96 inoperable but based-off g97 operation. I'd like to use g96. Please inform if more detail and instruction are available and where about lincurve.

As a starting point: Man page for lincurve: linuxcnc.org/docs/stable/html/man/man9/lincurve.9.html

The 10 DAC only measures up to 9.6V when the motor and spindle maximum RPM and maybe okay if the commanded spindles match the RPMs.  Could an already internal calculation volts per revolution have slight error within 0.00100 and from floating and rounding numbers?  Is it possible that every each RPM the same voltage well within five ten-thousandths and is correctable or substitutable?  I'd like to hold-off with the lincurve.  I'm unaware of any other calibration offset for the brush motor except maybe switching the hal file and PWM Generator signals channels to 1.  Then the ini file Spindle 0 and Output Scale set to volts per revolution.  However I don't know if other signals channels have to be to 1 as well and their location.  Is switching the channels to 1 an accessible option and effective?

LinuxCNC_Documentation.pdf
11.4.14 PWMGen
11.4.14.2 Parameters
14.11.2 PWMgen

There is only one PWMgen in a normal 7I96S configuration.
so changing PWMgens doesn't make much sense.

If the output is 9.6V at full scale, that suggests the SPIN+ voltage is only 9.6V
(or perhaps 50 mv more, the 7I96S analog output will get to within about 50mV
of the SPIN+ and  SPIN- terminal voltages)

I'm not sure how valuable it is to worry about the exact spindle speed
as long as it is close. It may also vary significantly under load.

 

My use with the mini CNC lathe equipment doesn't include production presently. Most of my workpieces are somewhat small diameters and probably won't require low surface feet often and can use the same moderately high RPM. Therefore, the commanded spindle not matching the RPMs is probably okay for now. I could probably try to tune it later if possible. An experienced Machinist. Use is light duty or industrial, prototypes, one-offs, hobby and remain current with practice. Included is parametric programming and developing new g-code which interrelates with my previous and future academics. I could probably upgrade to a VFD and different motor in the future with the existing breakout board firmware and LinuxCNC if it's any more accurate commanded RPM.

6100 rpm * 0.49 pulley ratio = 2989
10v / 2989 = 0.003345601 v/rev

9.6v at approx 2989 rpm and maybe divide 9.6 by 2989 instead.

3.25v / 945 rpm = 0.003439153 v/rev

945 rpm would of been expected 3.16159 v.

0.003439153 / 0.003345601 = 1.0279

1 - 0.0279 = 0.0279
360 * 0.0279 = 10 degrees/error.

The already internal calculation volts per revolution could be accurate within a few revolutions most RPMs. I wonder if the commanded spindle could have a formula or solution not comparable to the 10 volt scale. Maybe the 9.6v is part of it. Now's a matter of an spindle that matches rpm visa versa. I suppose lincurve would the substitute meantime.

Just to retrace.

10v / 2989rpm = 0.003345601 v/rev

0.003439153 v rev / 0.00345601 v rev = 1.027962

360 deg * 0.027962 = 10.06656 degrees

360 deg / 10.06656 deg = 35.7519 rev/1 less rev

1400rpm / 2989rpm = 0.4683

10v * 0.4683 = 4.6838v

4.6838v / 1400rpm = 0.00345601 v/rev

1400rpm / 35.7519 rev/1 less rev = 39.15875 rev/short

1400 rpm - 39.15875 rev/short = 1360.84125 rpm

1360.84125 rpm / 2989 max/rpm = 0.45528

0.45528 * 10 = 4.5528v

4.5528v / 1360.84125 rpm = 0.003345601 v/rev

s1400 m3 at 945 rpm. The s1400 with 0.027 deg error/rev would be corrected at 1361 rpm if maintaining 0.003345601 v/rev.  I wonder if the s1400 m3 is taking the input as another number.  Anyhow, volts per rev would require accuracy of millionths or better.  My economy digital multimeter measured the 3.25v only to hundredths accuracy.