W5100S-EVB-PICO stepgenerator and encoder driver

More
17 Jul 2025 00:56 #331920 by COFHAL
When will it be available for sale?

Please Log in or Create an account to join the conversation.

  • atrex77
  • atrex77's Avatar Topic Author
  • Offline
  • Senior Member
  • Senior Member
More
17 Jul 2025 06:04 #331925 by atrex77
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
  • atrex77's Avatar Topic Author
  • Offline
  • Senior Member
  • Senior Member
More
17 Jul 2025 06:13 #331926 by atrex77
Probably in the next month second half.

Please Log in or Create an account to join the conversation.

  • atrex77
  • atrex77's Avatar Topic Author
  • Offline
  • Senior Member
  • Senior Member
More
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.
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.

More
31 Jul 2025 17:08 #332606 by tuxcnc
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.
The following user(s) said Thank You: atrex77

Please Log in or Create an account to join the conversation.

  • atrex77
  • atrex77's Avatar Topic Author
  • Offline
  • Senior Member
  • Senior Member
More
01 Aug 2025 11:34 #332623 by atrex77
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.

More
01 Aug 2025 21:16 - 01 Aug 2025 21:19 #332645 by PCW
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.
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
  • atrex77's Avatar Topic Author
  • Offline
  • Senior Member
  • Senior Member
More
01 Aug 2025 22:02 #332648 by atrex77
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.

More
02 Aug 2025 00:10 #332650 by tuxcnc

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...

Please Log in or Create an account to join the conversation.

More
02 Aug 2025 00:24 #332651 by PCW
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.

Please Log in or Create an account to join the conversation.

Moderators: PCWjmelson
Time to create page: 0.092 seconds
Powered by Kunena Forum