W5100S-EVB-PICO stepgenerator and encoder driver

When will it be available for sale?

in the io-samurai project you find example, in the main.c line #88 (detection & init) and line #172 is the draw process, i not used in the stepper-ninja project because its limiting the refresh speed of the inputs/outputs (~60/sec), but if you are want to use to inputs and outputs for control panel, its probably not a problem. If you want to participate the project please use the test branch.

Probably in the next month second half.

 

started a proper configurator tool in python, early version, if you want to try it clone the test repository.
early sample, most of the functions are not working yet, you can move the components by grab it, make connections by click the pin and click to another pin, and delete the connections using the list in the right side and the "Del conn" button.

Unfortunately, your encoder code is good for MPG, but totally useless for spindle.
You have not taken into account many factors, such as a variable overflow, or a digital signal sampling too quickly.
For example, 2500 P/R encoder at 3000 rpm overflows int32_t after 72 minutes...
At the other side, low resolution encoder can produce velocity as 0,0,3 not 1,1,1...
One encoder dedicated only for spindle is a very good idea.
I know, because I wrote working and widely tested code, only for spindle control.
Read the code at github.com/tuxcnc/SpindleETH
This is for STM32 with hardware encoder support, but this is not important.

i have some questions, please explain to me "low resolution encoder can produce velocity as 0,0,3 not 1,1,1", "digital signal sampling too quickly.", how do you mange the digital signal sampling too quickly problem if you using hardware encoder counter without external hardware? how do you manage data integrity problem of UDP communication, i dont see any code to check the sent and received data is valid. Do you tested my code in real hardware? If so, open an issue in the github page. My project is in development and i want to fix all bugs that come in the future, but i don't react to theories. If you want to participate, fork the project (test branch), make changes you like, test it  and make a pull request.

The issue with the sampling speed has to do with velocity calculations,
mainly at lower speeds or lower resolution encoders:

Imagine you have a 1000 count (250 PPR) encoder turning at 30 RPM (= 0.5 RPS so 500 Hz count rate)
If sampled at LinuxCNCs standard 1 KHz rate, you would get 1 count every other
sample, since the most basic velocity calculations would use the difference in counts to determine
the velocity, the velocity calculation would alternate between 0 RPM (count change of 0) and 60 RPM
(count change of 1). At higher speeds the problem gets better but does not go away, at 90 RPM
with the same encoder/sample rate, you would get alternating counts of 1 and 2 so alternating
velocity calculations of 60 and 120 RPM.

You can of course filter the velocity value since the average value will be correct, but this is not desirable
if the velocity is used for feedback as it lowers the control bandwidth.

The normal way  this is improved is by velocity estimation, which changes the velocity calculation from
delta_counts/sample_time to delta_counts/time_between_counts. This typically requires that the low level
hardware timestamp count changes to allow the time_between_counts to be determined.

Once you have decent velocity estimation, you can do tricks like position interpolation, allowing
use of very low resolution encoders for constant speed spindle synchronized motion like threading.

Thank you PCW, now everything is clear and understandable. I think i solve this purely on the Pico side.

PCW wrote:

The normal way  this is improved is by velocity estimation, which changes the velocity calculation from
delta_counts/sample_time to delta_counts/time_between_counts.

It is true, but not solution for G33.1
In most worst case, the spindle stops, but the component waits for next pulse from encoder...
I have for tests small lathe with servo as spindle engine (velocity mode). It can stops (from 1500 to 0 rpm) at about 100 ms. (This is especially intended for fast G33.1)
In my opinion, the best is use high resolution encoder, and average speed from a 8 or 16 servo_thread periods.
Some cheap chinese encoders has bandwith 100-150 kHz, so in most cases 2500 P/R will be good.
But there is another problem. In my project I use STM32 with hardware quadrature counter, so this uses interrupts only for counter overflows.
Chips with no hardware quadrature counter must use interrupts for every encoders edges, it means hundreds of thousands interrupts per seconds, so it is very bad idea...

Velocity estimation is unrelated to G33.1 as G33.1 only looks at position.

If you do position interpolation, it's only for threading (Constant speed)

Also, as I mentioned, you need hardware timestamp support for velocity estimation.