An Electronic Leadscrew Controller using a Pi Pico

Thanks! You verified my assumptions.
Still recommend you do all the math and verify everything from start to finish. In other words, don't trust some random guy (me) on the internet - we all make mistakes from time to time. Make sure it will work for you, with your numbers, encoders, motors, etc. The details matter. It's your skin once the motors start turning...
 
I have done the math, including simulations to verify my theory. My only concern was whether or not the projected .03 thousandths error similar to QD as you mentioned would impact the threading (rough finish on the threads). If needed, I could add interpolation to my state machine but that would be non trivial, requiring much more DMA memory. That's the part I was relieved to hear probably won't be an issue for me.
Not sure if you're familiar with the pico PIO, but once I program the DMA and turn the state machine loose, the processor is completely out of the picture. The sweet thing about this approach is it tracks spindle rpm changes instantly!
 
I have done the math, including simulations to verify my theory. My only concern was whether or not the projected .03 thousandths error similar to QD as you mentioned would impact the threading (rough finish on the threads). If needed, I could add interpolation to my state machine but that would be non trivial, requiring much more DMA memory. That's the part I was relieved to hear probably won't be an issue for me.
Not sure if you're familiar with the pico PIO, but once I program the DMA and turn the state machine loose, the processor is completely out of the picture. The sweet thing about this approach is it tracks spindle rpm changes instantly!
Good. There's many that don't do the math, and they often get surprised.

DMA is great when it's working, but often tough to debug. I had a project with it and it took a little while to sort out. One thing to note is DMA uses bus resources, which can impact non DMA things. If DMA is using the bus, then the processor simultaneously can't be using the same bus. It's just something to consider in the overall design.

My dumb as dirt approach automatically tracks spindle speed. I calculate and display spindle RPM based off the spindle encoder. For a more pleasing display I pass the speed through an alpha filter to quiet the least significant digits. Works well and requires simple calculations.
 
I’ve been working most of the morning, refining my simulator, and it’s looking more promising than I originally thought. I had a logic error in my initial code which lead me to believe I’d need very large DMA memory block. right now, for thread sizes from 5 to 40 tpi, I only need a maximum of 171 control bits or 7 32 bit words where each word contains 27 control bits.
need to look at metric next.

The pico is designed to allow up to 4 simultaneous 32 bit bus transfers. Even if that wasn’t the case, my design uses the DMA once every 27 encoder pulses, 5 of the 32 bits will specify the number of control bits in the 32 bit word. That transfer is a step in the PIO state machine code, so it’s recognizable in the state machine code. Each state machine step requires one 133Mhz clock cycle that runs independent and without impacting code running on the two processor cores. It’s really a very well thought design.

I’m probably going to use a third state machine for the tachometer.

As a reminder, once I load DMA memory with control words based on the feed rate, the processor is completely out of the picture. The state machine executes code at 133Mhz rate with no impact on code running on either of the two processor cores.

I made an arbitrary waveform generator by DMA’ing waveform data to the PIO state machine. The processor served a web page for the UI with the onboard WiFi, and you’d never realize the PIO was running! The UI was fast and fluid with the state machine running or halted.
 
Back
Top