W5100S-EVB-PICO stepgenerator and encoder driver
- COFHAL
- Offline
- Platinum Member
-
Less
More
- Posts: 387
- Thank you received: 43
17 Jul 2025 00:56 #331920
by COFHAL
Replied by COFHAL on topic W5100S-EVB-PICO stepgenerator and encoder driver
When will it be available for sale?
Please Log in or Create an account to join the conversation.
- atrex77
-
Topic Author
- Offline
- Senior Member
-
Less
More
- Posts: 46
- Thank you received: 24
17 Jul 2025 06:04 #331925
by atrex77
Replied by atrex77 on topic W5100S-EVB-PICO stepgenerator and encoder driver
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.
Please Log in or Create an account to join the conversation.
- atrex77
-
Topic Author
- Offline
- Senior Member
-
Less
More
- Posts: 46
- Thank you received: 24
17 Jul 2025 06:13 #331926
by atrex77
Replied by atrex77 on topic W5100S-EVB-PICO stepgenerator and encoder driver
Probably in the next month second half.
Please Log in or Create an account to join the conversation.
- atrex77
-
Topic Author
- Offline
- Senior Member
-
Less
More
- Posts: 46
- Thank you received: 24
29 Jul 2025 19:21 - 29 Jul 2025 19:25 #332529
by atrex77
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.
Replied by atrex77 on topic W5100S-EVB-PICO stepgenerator and encoder driver
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.
git clone -b test https://github.com/atrex66/stepper-ninja.git
sudo apt install python3-pygame
cd stepper-ninja/configurations/configurator
python3 configurator.py
Attachments:
Last edit: 29 Jul 2025 19:25 by atrex77.
Please Log in or Create an account to join the conversation.
- tuxcnc
- Offline
- Premium Member
-
Less
More
- Posts: 131
- Thank you received: 10
31 Jul 2025 17:08 #332606
by tuxcnc
Replied by tuxcnc on topic W5100S-EVB-PICO stepgenerator and encoder driver
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.
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.
The following user(s) said Thank You: atrex77
Please Log in or Create an account to join the conversation.
- atrex77
-
Topic Author
- Offline
- Senior Member
-
Less
More
- Posts: 46
- Thank you received: 24
01 Aug 2025 11:34 #332623
by atrex77
Replied by atrex77 on topic W5100S-EVB-PICO stepgenerator and encoder driver
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.
Please Log in or Create an account to join the conversation.
- PCW
-
- Offline
- Moderator
-
Less
More
- Posts: 19100
- Thank you received: 5274
01 Aug 2025 21:16 - 01 Aug 2025 21:19 #332645
by PCW
Replied by PCW on topic W5100S-EVB-PICO stepgenerator and encoder driver
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.
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.
Last edit: 01 Aug 2025 21:19 by PCW.
The following user(s) said Thank You: atrex77
Please Log in or Create an account to join the conversation.
- atrex77
-
Topic Author
- Offline
- Senior Member
-
Less
More
- Posts: 46
- Thank you received: 24
01 Aug 2025 22:02 #332648
by atrex77
Replied by atrex77 on topic W5100S-EVB-PICO stepgenerator and encoder driver
Thank you PCW, now everything is clear and understandable. I think i solve this purely on the Pico side.
Please Log in or Create an account to join the conversation.
- tuxcnc
- Offline
- Premium Member
-
Less
More
- Posts: 131
- Thank you received: 10
02 Aug 2025 00:10 #332650
by tuxcnc
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...
Replied by tuxcnc on topic W5100S-EVB-PICO stepgenerator and encoder driver
It is true, but not solution for G33.1The 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.
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...
Please Log in or Create an account to join the conversation.
- PCW
-
- Offline
- Moderator
-
Less
More
- Posts: 19100
- Thank you received: 5274
02 Aug 2025 00:24 #332651
by PCW
Replied by PCW on topic W5100S-EVB-PICO stepgenerator and encoder driver
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.
If you do position interpolation, it's only for threading (Constant speed)
Also, as I mentioned, you need hardware timestamp support for velocity estimation.
Please Log in or Create an account to join the conversation.
Moderators: PCW, jmelson
Time to create page: 0.092 seconds