Remora - Rpi Software Stepping Using External Microcontroller via SPI

LinuxCNC will only come out of eStop when the SPI comms works, ie the remora-spi component receives a valid response from the board.

This is where using the serial output from the board is handy to ensure the board boots all the way to idle state where it will wait for SPI commands.

scotta thank you so much!

the challenges I face that are left are:

1) homing -> I tried wiring to GND and 3.3v but joint.0.home (maybe it's called different) is never TRUE, I tried using halcmd show pin for that while linuxcnc was running and also live testing the home axis.
[/code][/code]

is j3 the extruder or one of the rotary joints/axis?

jairobbo wrote:

scotta thank you so much!

the challenges I face that are left are:

1) homing -> I tried wiring to GND and 3.3v but joint.0.home (maybe it's called different) is never TRUE, I tried using halcmd show pin for that while linuxcnc was running and also live testing the home axis.

Code:

[code]27  bit   OUT         FALSE  remora.input.00 ==> X-home    27  bit   OUT         FALSE  remora.input.01 ==> Y-home    27  bit   OUT         FALSE  remora.input.02 ==> Z-home    27  bit   OUT         FALSE  remora.input.03 ==> A-home [code]I think it's weird that all my inputs are listed as OUT.... 2) maybe related maybe unrelated: my A axis (joint3) is continuing to have follow joint problems. I thought maybe the motor or the driver went bad, but I swapped both. I tried several stepgen_maxaccel settings and fooled around with other settings as well. Of course I appreciate the help so far and yes it's close to working, I was already very happy to see my XYZ axes moving!!!! :)  

[/code][/code]

Hi, the inputs are "outputs" from the remora-spi component. The way I would approach this is the use halshow to confirm the the inputs are working.

1. ensure you have the inputs in your config.txt file
2. LinuxCNC has come out of eStop so comms are up. You will not see any input state changes unless you are out of eStop
3. Use halshow to monitor your inputs
4. Manually trigger the inputs and that they change state in halshow
5. setup you hal config

Hi,

Not sure if this is the correct place to post, as I'm actually not a Remora user but someone trying to use the source code for a LCNC to TMC5160 communication module.

I downloaded the latest official RPi 5 image and could not get a SPI communication with my TMC5160 drivers. I had to force the "rp1" variable to "true" in the code and then found out that my device-tree doesn't have the "soc" folder the script was looking for, but a "soc@107c000000". It seems like there are 2 different dtb files available, the bcm2712d0-rpi-5-b.dtb and the bcm2712-rpi-5-b.dtb. Can someone explain me the difference?

I also had a look in the new spix driver that hm2 component uses, and it reads /proc/device-tree/compatible to detect the board type. Might it be a bit more robust to dtb files changes?
hm2.spix.c:

// Read the 'compatible' string-list from the device-tree
    buflen = spix_read_file("/proc/device-tree/compatible", buf, sizeof(buf));
    if(buflen < 0) {
        LL_ERR("Failed to read platform identity.\n");
        return buflen;    // negative errno from read_file()
    }

    // Decompose the device-tree buffer into a string-list with the pointers to
    // each string in dtcs. Don't go beyond the buffer's size.
    memset(dtcs, 0, sizeof(dtcs));
    for(i = 0, cptr = buf; i < DTC_MAX && cptr; i++) {
        dtcs = cptr;
        j = strlen(cptr);
        if((cptr - buf) + j + 1 < buflen)
            cptr += j + 1;
        else
            cptr = NULL;
    }

spix_rpi5.c:

for(i = 0; dtcs != NULL; i++) {
        if(!strcmp(dtcs, DTC_RPI_MODEL_5B) || !strcmp(dtcs, DTC_RPI_MODEL_5CM)) {
            break;    // Found our supported board
        }
    }

Thanks for your help.

Thanks for sharing. I did investigate reading the device tree when working on the RP1 driver but took the easy path so as to focus on the DesignWare SPI side of things. Looks like I'll need to rework the board detection. At least the Mesa code will be a great starting point.

I just tested this at the beginning of rt_peripheral_init and it compiles and works on my RPi5 and RPi400 if you include the attached dtcboards.h:

int rt_peripheral_init(void)
{
    FILE *fp;
    int i, j;
    char buf[256];
    ssize_t buflen;
    char *cptr;
    const int DTC_MAX = 8;
    const char *dtcs[DTC_MAX + 1];
    
    // assume were only running on >RPi3
    
    if ((fp = fopen("/proc/device-tree/compatible" , "rb"))){

        // Read the 'compatible' string-list from the device-tree
        buflen = fread(buf, 1, sizeof(buf), fp);
        if(buflen < 0) {
            rtapi_print_msg(RTAPI_MSG_ERR,"Failed to read platform identity.\n");
            return -1;
        }

        // Decompose the device-tree buffer into a string-list with the pointers to
        // each string in dtcs. Don't go beyond the buffer's size.
        memset(dtcs, 0, sizeof(dtcs));
        for(i = 0, cptr = buf; i < DTC_MAX && cptr; i++) {
            dtcs = cptr;
            j = strlen(cptr);
            if((cptr - buf) + j + 1 < buflen)
                cptr += j + 1;
            else
                cptr = NULL;
        }

        for(i = 0; dtcs != NULL; i++) {
            if(        !strcmp(dtcs, DTC_RPI_MODEL_4B)
                ||    !strcmp(dtcs, DTC_RPI_MODEL_4CM)
                ||    !strcmp(dtcs, DTC_RPI_MODEL_400)
                ||    !strcmp(dtcs, DTC_RPI_MODEL_3BP)
                ||    !strcmp(dtcs, DTC_RPI_MODEL_3AP)
                ||    !strcmp(dtcs, DTC_RPI_MODEL_3B)) {
                rtapi_print_msg(RTAPI_MSG_ERR, "Raspberry Pi 3 or 4, using BCM2835 driver\n");
                bcm = true;
                break;    // Found our supported board
            }else if(!strcmp(dtcs, DTC_RPI_MODEL_5B) || !strcmp(dtcs, DTC_RPI_MODEL_5CM)) {
                rtapi_print_msg(RTAPI_MSG_ERR, "Raspberry Pi 5, using rp1 driver\n");
                rp1 = true;
                break;    // Found our supported board
            }else{
                rtapi_print_msg(RTAPI_MSG_ERR, "Error, RPi not detected\n");
                return -1;
            }
        }
        fclose(fp);
    }else{
        rtapi_print_msg(RTAPI_MSG_ERR,"Cannot open '/proc/device-tree/compatible' for read.\n");
    }    
    
    if (bcm == true){
...

scotta wrote:

Thanks for sharing. I did investigate reading the device tree when working on the RP1 driver but took the easy path so as to focus on the DesignWare SPI side of things. Looks like I'll need to rework the board detection. At least the Mesa code will be a great starting point.
 

You actually did an amazing job on the DesignWare SPI and I can't thank you enough for it!

Hi all,First of all I wanted to express my grattitute for the assistance on getting the octopus board to run Remora LinuxCNC.Since I actually want to print cool stuff on the 5 axis modified Ender3 3d printer, I am writing 2 addons for Blender. The first is an indexed slicer that let's the user chop off overhanging parts of the model, so they're printed in a more gravity friendly orientation. The second is a "magic spiral toolpath generator". I love to print miniatures and have this TINtIN buste taht is perfect to test out this strategy. The idea is that the entire model is printed in one spiral motion, while the machine orients itself to pe perpenticular to the path and flush with the mesh direction.To save myself the challenge of writing a toolpath postprocessor I wanted to ask here about if anyone knows if there exists something already to achieve this. I was thinking to bring my blender curve to another app and modify the machine geometry and that finally have that amazing 5 axis gcode :)btw both addons can be found on my github: bbo-gitI'm attaching a small screen shot for your entertainment ;)See you!Jairo

I second this. Big thanks to Scott for figuring out the Pi5 stuff. I was able to get SPI running for my own project (very similar to Remora SPI) in just a few hours, the same day I acquired a Pi5 !