Remora - Rpi Software Stepping Using External Microcontroller via SPI

There is nothing to set, just compiles it with the Blackve profile without any modifications.

made some progress  @ Scott : everything works except PWM if you can help me

Hi folks. I'm attempting to integrate Remora with my CNC minilathe and for the most part it's been trouble free. I'm new to LinuxCNC - so apologies for any obvious mistakes I make.

The setup is an rpi4 alongside STM32F106RCT6 based SKR mini 1.1 running a lightly modified version of develop. The modifications were just to setup SPI for this board (port A -> B, CS -> PA15) on the SKR_MINI_E3 target. The board is flashed by an STLINKV2.

On the pi side I've modified the xyz hal and ini files to suit my setup (2 joints, XZ config) and commented out spindle and other modules to ensure no interference.

I've run through and fixed a whole host of issues including SPI packet errors and configuration problems. Most of the solutions were already in this topic.

The long standing issue crops up enough to make the lathe unusable. You can move the system on either axis and when it stops or nears stopping, it (sometimes) suddenly jumps into motion (step change) and starts slowing down. This can be seen below. The position feedback value changes and the system compensates.



Some interesting observations:

• During the 'tail' end of movement, if you press F2, it will stop and continue the same movement when re-enabled with F2
• This behavior seems to be related to the DDS accumulator overflowing - this is consistent. Slowing movement near the edge of the int32 will cause this issue (when it overflows).
• The issue still occurs if you significantly reduce the DDS step bit (I had it at 10 in both fw and sw). Although it is less consistent, and occurs well within the int32 boundaries.

Has anyone seen or fixed this behavior? I'd appreciate any insight!

-Rafal

gtt38 wrote:

made some progress 

Code:

void loadModules() {     //Stepgen     int joint;     ptrInputs = &txData.inputs;     ptrOutputs = &rxData.outputs;     joint = 0;     printf("\nCreate step generator for Joint %d\n", joint);     ptrJointFreqCmd[joint] = &rxData.jointFreqCmd[joint];     ptrJointFeedback[joint] = &txData.jointFeedback[joint];     ptrJointEnable = &rxData.jointEnable;     Module* joint0 = new Stepgen(PRU_BASEFREQ, joint, "PB_12", "PB_13", "PB_14", STEPBIT, *ptrJointFreqCmd[joint], *ptrJointFeedback[joint], *ptrJointEnable);     baseThread->registerModule(joint0);          //Blink     Module* blinkServo = new Blink("PB_0", PRU_SERVOFREQ, 1);     servoThread->registerModule(blinkServo);     //Input     Module* IN1 = new DigitalPin(*ptrInputs, 0, "PD_12", 0, true, NONE);     servoThread->registerModule(IN1);     // OUTPUTS     Module* OUT1 = new DigitalPin(*ptrOutputs, 1, "PC_3", 0, false, NONE);     servoThread->registerModule(OUT1);     // PWM (not working)     Module* pwm = new PWM(*ptrSetPoint, "PC_4");     servoThread->registerModule(pwm); @ Scott : everything works except PWM if you can help me

Hi, which board are your setting this up on?

The setPoint is an array of floats so you need an array index

Rafal wrote:

Hi folks. I'm attempting to integrate Remora with my CNC minilathe and for the most part it's been trouble free. I'm new to LinuxCNC - so apologies for any obvious mistakes I make.

The setup is an rpi4 alongside STM32F106RCT6 based SKR mini 1.1 running a lightly modified version of develop. The modifications were just to setup SPI for this board (port A -> B, CS -> PA15) on the SKR_MINI_E3 target. The board is flashed by an STLINKV2.

On the pi side I've modified the xyz hal and ini files to suit my setup (2 joints, XZ config) and commented out spindle and other modules to ensure no interference.

I've run through and fixed a whole host of issues including SPI packet errors and configuration problems. Most of the solutions were already in this topic.

The long standing issue crops up enough to make the lathe unusable. You can move the system on either axis and when it stops or nears stopping, it (sometimes) suddenly jumps into motion (step change) and starts slowing down. This can be seen below. The position feedback value changes and the system compensates.

Some interesting observations:

• During the 'tail' end of movement, if you press F2, it will stop and continue the same movement when re-enabled with F2
• This behavior seems to be related to the DDS accumulator overflowing - this is consistent. Slowing movement near the edge of the int32 will cause this issue (when it overflows).
• The issue still occurs if you significantly reduce the DDS step bit (I had it at 10 in both fw and sw). Although it is less consistent, and occurs well within the int32 boundaries.
  
  
  Has anyone seen or fixed this behavior? I'd appreciate any insight!
  
  -Rafal

Hi Rafal. 

It looks like you have really understood the Remora firmware and the Step Generator implementation. And a great pick-up. How did you narrow this down to the DDS accumulator overflow? I'd like to check this out as following error spikes are something I'm looking into and to date have not had a clue where they were coming from. You may have found it!

In the mean time you can increase the pgain to bring the jump back down quickly.

Hi scotta,

I did some more testing and cannot reproduce the error on overflow consistently anymore - although it still does occur. It took a little bit of prodding this morning before it would produce the error again. Perhaps it's marginal and related to the micro coming up to temperature?

I've just placed a printf in Stepgen::makePulses that's slow enough to not trip estop (not pretty, but it gives insight):

 

It could be that the feedback is being modified which causes an error in the LinuxCNC module which in turn compensates and adjusts the freq command. Or the other way around, where the error is generated in LinuxCNC. Perhaps something is overwriting memory - frequencyCommand, DDSaddValue, DDSaccumulator? I'd suspect the micro, but haven't looked at the hal module in any detail.

Thanks for your pgain increase suggestion. I tried it and it does help, although the issue still crops up and is quite large in magnitude (700 steps ~ 1 rotation over a few seconds), so it overshadows any pgain gains.

-Rafal