Remora - Rpi Software Stepping Using External Microcontroller via SPI

Here is the one i have if you read up on GrblHal it was based on Linuxcnc so it should be easy to convert over?
forum.pjrc.com/threads/61622-Teensy-4-1-Based-CNC-Controller

This project is still in Beta. Just relax and wait for more devs to jump in and improve things vs jumping ship.

Just a suggestion, you are free to run around the room and scream if you wish 

Your right, it's a great project, and big thanks to the devs, just in my case I need something better than the 20khz, I just built up a whole control and now need to find something else, like the H3. setting back my ship dates, I'm stuck in a position I can't wait even tho this has great future potential. I was hoping to ship with an SBC all included control system v.s. ext like Mach and acorn(ext PC) VS (internal RPI). Thanks

Is there any specific reason you need to run 1/16 microstep? is there any advantage ? I do fullstep when ever possible and i run 1202/1204/1205 ballscrews, at fullstep a 1204 ballscrew is doing .02mm per step if my math is correct, so even at 1/4 step you still get a better resolution than is realistically achievable. 

scotta explains the steprate limitation on the previous page

2. The Base Thread, which the step generator runs in, runs by default at 40khz. For a step on and off this takes two cycles so the fastest theoretically is 20khz. Below is a trace of both threads. There is some idle cpu time, but how fast do we need to go. On a typical 3D printer setup this is > 200mm sec.

At these higher speeds your setup needs to be done well to avoid following errors. ie stepgen acceleration set appropriately , joint velocity > max velocity so that the joint can actually make up any following error. Marlin and other firmwares don't monitor the actual step generation and just push out pulses. Remora does, so the configuration needs to be such to allow the control loop to do its job.

I think the grblhal thing is more about being inspired by linuxcnc hal implementation for making it easier to port for all the different supported boards , because its firmware has a lot more going on like the kinmatics/interp/planner. I think the 3d printer software klipper is more like what we want for linuxcnc as it seems to operate the same way with an spi link to the pi to offload stepgen to the microcontrollers if my understanding is correct.

mhel wrote:

This is the beginning of my stand alone controller

what resolution is that screen you are using? 1080*640?
Also picked up a SKR 2.0 with the stm32f407, its almost identical to the skr 1.4, except for a few revisions and the stm32. it would appear this is meant to be a replacement for the skr 1.4 probably related to the chip shortage, as board layout, size and mounting holes are all in the same location.

Cncninja wrote:

LPC17XX can do much faster step rates ??? where is the bottleneck. What's the point of 25khz the built-in I/O of the RPI can do that.

Hi, for clarity. Remora uses software step generation using a DDS accumulator, the same logic that the standard LinuxCNC step generator uses. Please don't compare to firmwares that utilise hardware PWM that have no feedback into the control loop. Remora, like the standard Stepgen monitors every step produced (physical lost steps require encoder feedback) and adjusts step frequency to minimise follow error. 

For my 3D printer application 250mm is more than adequate, and as another member said. Do you really need the resolution of 16 micro stepping?

 

Bari wrote:

Can't the LPC17xx handle higher real time thread rates? OH! Maybe not , only 100/120 MHZ ARM core.
www.nxp.com/products/processors-and-micr...ackage:LPC1768FBD100

We should be able to fix this using STM32.

Since Rommel shared his STM32 port I have been tempted to have a crack at this. I've now got a BTT SKR v2 with the STM32F407 on the way. 168Mhz is attractive to start testing speeds but how fast do we really need...