LinuxCNC + Orange Pi (allwincnc)

Cncninja wrote: I see the encoders talked about a lot, this is really only for servo systems right? If im running a stepper or closed-loop servo looped only with the drive then encoder inputs are irrelevant correct? or is the stepper signal feedback through an encoder to verify stepper count?

Encoders are fed back to LCNC to keep track of the position of any joint or axis.

Closed loop steppers where the loop is closed in LCNC.

Servo systems can also tie the encoders back into LCNC to close the loop so that LCNC keeps track of the machine position and speeds.

Spindle synchronization using an encoder on the spindle for things like rigid tapping.

Synchronization of all sorts of mechanisms in LCNC using encoders such as lasers, plasma cutters, inkjet heads, etc etc

MX_Master,
Thank You for update, I've just tested new drivers with generator. I'm using very similar configuration to Yours example (one input pin, simple counter mode, no reset), and HAL Meter.

Position calculation is correct up to about ~300kHz (50% with duty cycle, great), however the velocity is very wrong. Looking at the code I think that I can see the problem, please check my findings:
1. It seems that the line 974 in arisc.c is wrong there. We should update ep.counst only when we perform velocity calculation.
2. Velocity formula should be:
vel = (eh.counts - ep.counts) / scale * 1e9 / no_counts_time;

While results are correct with this method, it gives very poor resolutions at low input frequencies. At 1ms servo period, 1kHz at input gives velocity = 1000 (scale=1), 1.5khz gives 1000 or 2000 (fifty fifty). Proper method would be to calculate period of input encoder signal at low frequencies and frequency at high. Alternatively we can just increase number of counts needed to perform calculation, but this would decrease update rate.

I don't know how important for linuxcnc is velocity signal anyway, I don't have my machine yet. I'm just testing my stepper/spindle driver now, with floating motors.

Actually you should always use period for velocity calculations as even at higher speeds you throw-away velocity resolution if you don't take the period into account.

I was thinking about really high input frequencies. Right now risc loop can see changing pins up too about 300kHz. Using it to calculate period at 200kHz input would result in even worse resolution then now.

What frequency range we get from encoders in real-live is another meter - I have no experience here .

PS.
Thanks MX_Master for explanation about risc firmware! I will try to set up compiler and build Yours driver on my own (mostly for fun now).

mwidlok wrote: I was thinking about really high input frequencies. Right now risc loop can see changing pins up too about 300kHz. Using it to calculate period at 200kHz input would result in even worse resolution then now.

What frequency range we get from encoders in real-live is another meter - I have no experience here .

Yes, it depends on the resolution of the timestamp but the idea is to get velocity from the counts/time_between_counts
(which will be close to 1 ms but calculated from the time of the first count to the time of the last count per period rather than
just the delta time which will have a full count uncertainty)