Remora 1.0.0_rc released for testing

wazza77 wrote:

Hi Scotta
The ARCH_MAX.bin file I assume is the SEED ARCH MAX board so I should be able to run this on the STM32F407VET6 Black board? os.mbed.com/users/hudakz/code/STM32F407VET6_Hello/shortlog/
as I use seed arch max profile to program it in mbed. if so this will really make using linuxcnc very accessible as these boards are cheap and available I have 3 on my desk right now I normally use eclipse or now STM cube as my environment. I have a mill running with EtherCAT servo drives.
so this will be tested on my CNC plasma table so a very high rf noise environment so it should be interesting

Hi, yes absolutely correct. I was directly contacted by a user who wanted to use this board for a gantry router. He's currently getting it going and learning LinuxCNC along the way. This board gives full flexibility on IO, so heaps of potential.

Why will you need to change the SD card?

Aaroncnc wrote:

Bari, As far as IO's go each stepper requires a Step and Dir. 

The inputs and out puts are separate from the step gens.
so they are not taken up by step and dir
Remora supports 8 drivers.

16 inputs and 16 outputs.
The only weird thing that takes up an input is the encoder index pulse but i don't think it's a big deal as it's only important on a spindle or rotary axis.  

The pwm does not take up an output and there are 8 pwm channels.

Hi Aaron, thanks for clarifying things for the others. Your work on the config tool means you're totally across the capabilities of Remora. 

Thinking on your comments regarding the encoder index pulse. We could embed this into the bit 0 of the encoder count feedback. We bit shift the count over by 1 and toggle the 0'th bit for the index. Of course we would need to do the reverse on the LinuxCNC side...

Its not broken currently and works well with the expanded inputs.
Not many use cases for taking up 16 inputs unless someone is trying to make a physical keyboard/control panel.

Of the things i am working on the dedicated pins for hardware pwm/QEM for each board needs to be found. I have just not had time. so my tool currently only has the default values for the skr1.4 but once i get the rest of the PID and thermistor support in the hal generator i will work on letting the board selection box pre populate all the correct default pins.

Any luck an an updated PID config example for the axis?

I have reworked my implementation for spindle pid.
No longer using an abs component and also using the limit1 with min of 0 and max of 100. so far its going very well.

Hi Scotta
The seed arch max uses SPI2 for the sd card whereas the black uses SDIO. I tried compiling in MBED studio last night but I had a few issues
but at 3 am I wasn't going to push it any further

wazza77 wrote:

Hi Scotta
The seed arch max uses SPI2 for the sd card whereas the black uses SDIO. I tried compiling in MBED studio last night but I had a few issues
but at 3 am I wasn't going to push it any further

Hi, thanks for the clarification. I'll update things to call it BLACK_F407E as I have set it up to use the SDIO.

Some good news. The initial port to STM32F103 is working. The new code structure definitely makes this very straight forward.

github.com/scottalford75/Remora/tree/develop

Development has been done an an Mks Robin E3 board with an STM32F103RC mcu. The Robin board uses an encoded bin file and for some reason the bootloader is causing some issues with some Mbed calls. So currently the bin file needs to be flashed to the board using an ST-Link. Given the 72Mhz clock of the F103, the code spends about 50% of the time in the base thread when running 4 step generators.

I chose the Mks Robin E3 as the dev board as most of the SKR boards share the SPI used for communications with the SD card. I think I have a work around for this but will need to get a board to test 100%.