It is just a web page so any browser would work, it is not an "app"
You don't need to update the display more than 5 hz in practice. Also, with a single core you wouldn't want to try to do that in addition to monitor the encoder and generate steps.
The tough stuff is:
1. implementing acceleration
2. user interface in hardware that you like and can change and is easy to iterate on when it is on your machine.
I was recently playing around with a single axis stepper for power feeding a mill and I was thinking of also using the same code to run my rotary table. Hardware UI's suck for configuration. I really hate them and you have to sink a ton of time into them. Display code for these MCUs also sucks. Best bet seems to be a really simple hardware UI for operation and doing all the configuration via wifi or bluetooth and a simple web UI using websockets for the display/config. It is worth the learning curve.
Encoder noise is an issue depending on how noisy your spindle motor is. Differential encoders seem like the best choice.
The esp32 has a couple really nice features for this application. 2 cores allows one core to focus on the encoder and motion planning calculations. the 2nd can be used for all the other stuff. It also has a RMT peripheral which does step generation up to 200khz with no additional CPU load. Finally, the wifi allows you to wirelessly flash it and to use a web ui to configure/debug it.
I'd love to figure out a decent way to implement acceleration curves. The issue is that with the spindle running you have a period where an acceleration ramp is needed to get to the right position. This will always be in error until the stepper gets up to speed and is also in sync with the spindle encoder position. The issue is making the out of sync startup time as small as possible. In my setup a close loop stepper seems to be best as it can compensate for the acceleration issues when threading. Plan B is just to tell the thing to jog with the spindle off and when you turn the spindle on it maps it's acceleration to the spindle's acceleration and should be perfectly in sync.
With respect to the naïve implementation, the simple way to do it is.
1. set sync point from encoder.
2. when "engaged" calculate the correct position (using Bresenham line interpolation calculation is good start)
3. if correct_position > current_position then step the right direction.
4. if correct_position < current_position then step the left direction.
5. else do nothing
This slaves the X motor to the spindle and will work at any speed (assuming your encoder can keep up). It also works with the machine stopped.
I'm happy to help you out so feel free to ask me questions here or on github.
Thanks for chiming in. Especially for clearing up my mistaken notion of an app. In the distant past I played around with python-flask to make an interactive web page. It wasn't that bad to implement. I do have to agree the UI is a royal pain, especially if it morphs over time.
I wrote a program to compute and display ambiguity waveforms for radar, and I found the human interface took up a LOT of effort. A lot more effort than learning how to compute 32 million point double precision floating point fast fourier transforms using massive parallel processing. As a tidbit, moving the data to the compute engine took 10 times as long as computing it. (Network bound on a private bonded 2Gb Ethernet.) Learned a lot about super computing bottlenecks on that job.
As you learn more about what is important for the user, the displays and interaction tend to get more complicated. Sometimes so complicated, that basically one has to rip up what was done, simply because it was not flexible enough. If possible, it's far better to design a fuller interface, than to organically grow it. Organically grown code usually is a nightmare, primarily since it wasn't fully thought out. Unfortunately, I don't know much about motor control, nor the application, so I
expect to flounder some on the man-machine interface.
For my radar display, the display was about 6 Hz, give or take. It was about as fast as the cheapo display could manage. The radar ran at 50Hz and detections plus that detected data frame were displayed. For my application, it wasn't quite acceptable, since I wanted to track the flight of the projectile, which should ordinarily consist of multiple detections. But hey, it wasn't bad considering it was running on a low budget M4 processor, and a $3 doppler door sensor front end. Kind of pushed it to the limit and found the limits!
For your implementation, it appears you are reading your DROs on your lathe? Are you directly reading the scales and decoding the position? I can't quite tell what your implementation is. Is there any documentation of what you have done so far? No videos, but some diagrams, or basic written description. I did view one video, which was interesting, but it left me with questions of what all the elements of your system are. Perhaps it was covered in a previous video.
And thanks for your offer of help. Good to know there's someone to ask a question or two.
