@chrishamm
Thanks for verifying that that was a legitimate error/concern.
By default, does 3.5-rc.1 have large SPI transmissions right off the get-go but 3.4.6 does not? Perhaps that's why 3.4.6 was connecting but not faulting out like 3.5-rc.1?

After further testing:
For Bullseye (Deb 11), this works:

echo "options spidev bufsiz=8192" | sudo tee /etc/modprobe.d/spidev.conf 

For Bookworm (Deb 12), it does not.

Instead, I had to add:

spidev.bufsiz=8192

to the end of

/boot/cmdline.txt

After a reboot, when I:

cat /sys/module/spidev/parameters/bufsiz

I get 8192 and DWC now connects to the 6HC with 3.5-rc.1 in SBC mode.

I know we are probably an early adopter of Bookworm on the Pi w/Duet SBC so I'll report out anything else I run into. We'll be exercising our system heavily over the next few weeks.

Update: 10-23-2024

After tabling this issue for the past couple of months, we had to revisit it when we performed a major upgrade to our system that caused the issue to come back in full force to the point where our "automatic" workaround (basically, detection of the issue and software reset) wouldn't work anymore.

We replaced a lot of our 24V hardware with new versions of the same devices and went to different, dual 24V power supplies as well.

After the upgrade, we ran into the disconnection issue almost immediately when trying to run the equipment. We would get tens, almost hundreds of TfrRdy pin glitches in matter of seconds and the Pi/Duet would disconnect within 30s. We disconnected one 24V device at a time and ran some tests until we found that a brushed 24V/2A vacuum pump was putting out excessive noise on the 24V wire which was feeding back to the Pi/Duet. We put a capacitor across the pump's terminals and the TfrRdy pin glitches went to 0. We've been running for a couple of days now and we haven't had a single disconnection between the Pi and Duet.

It looks like our problem was excessive noise generated by poor component selection/sourcing. We tested the other pumps and devices on the system and we are seeing varying amounts of noise but none to the extent of that one particular vacuum pump.

I'll mark this one as solved!

@droftarts Thanks for the update.

I tried the M997 S2 F"unstable" method but the update kept hanging while updating duetcontrolserver (around 89%). It did update the boards to 3.6.0-beta2, just not duetcontrolserver so I kept getting incompatible firmware messages. I had to use the "manual" update method to revert back to 3.5.3 and noticed the potential documentation issue. I'm going to run some more tests to see if the M997 issue is repeatable and I'll create a new thread under Beta firmware if it is. This is all on my testbench, so no harm, no foul.

@chrishamm I spoke too soon, again...

So, after I RTFM (read the flipping manual, though it's not flipping), I found I was missing:

pip install dsf-python==3.6.0-b2

Soooooooooo... now I am at 3.6-beta4 for all boards, DSF, DWC, python bindings, etc...

Initial testing of our python app shows functionality.

@Falcounet That did it, thanks!
I had performed:
sudo apt install python3-dsf-python
but didn't include the snippet of that in my post. I guess it didn't matter since I had the older version of dsf-python installed. I do install that version via a script when setting up the Pi/Duet "out of the box". I'll update my script to use python3-dsf-python instead.

Thanks again!

@droftarts @rero

Son of a #$@#!

Thanks gents! I'll start playing around with that example.

@dwuk3d @droftarts

Modified test macro:

;M606 S1

M596 P0
M400

M596 P1
M400

M596 P0
G90 G1 X0 A0 F2000
M400

M596 P1
M400
G90 G1 A100 F2000
G90 G1 A0 F2000

M596 P0
G90 G1 X200 F3000
G90 G1 X0 F3000

M596 P1
G90 G1 A100 F2000
G90 G1 A500 F5000
G90 G1 A100 F2000

M596 P0
G90 G1 X200 F3000
G90 G1 X0 F3000
G4 P1000
echo "X stopped"
G90 G1 X200 F3000
G90 G1 X500 F5000
G90 G1 X100 F3000
G90 G1 X500 F5000

M596 P1
G4 P1000
echo "A stopped"
G90 G1 A500 F5000
G90 G1 A100 F3000
G90 G1 A500 F5000
G90 G1 A100 F2000
G90 G1 A500 F5000
G90 G1 A100 F3000

M596 P0
G90 G1 X100 F5000
G90 G1 X500 F5000
G90 G1 X100 F5000
M400

M596 P1
M400

M596 P0
G90 G1 X0 A0 F4000
M400

So, I am playing with the number of move commands and adding in G4 P1000 with echo between the motion systems. I wanted to see if a G4 in one motion system would affect the other motion system and it does not. Again, as expected per the multiple motion system documentation. I am trusting but verifying...

Everything works as desired as long as I don't let either motion system "run dry" of commands. If one motion system runs out of commands, the axis sits and waits until the next M596 Px and gets more to do... totally understandable and expected per the documents.

Also of note, running with or without M606 S1, the functionality seems to be the the same, just no M606 error without the M606 S1.

@dwuk3d

My system is not a printer, so I don't run job files. I have 50+ macro files that perform each part of my process that I call as needed when needed via a custom python GUI running on the Pi. The custom GUI continuously reads the object model and based on the current state of the sensors connected to the Duet 6HC, I execute the required macros to perform an assembly process.

My motion queues are set to 100 steps each. So, I believe with the M606 S1, the queues are "filling", switching between each other, and "filling" with more commands. I do not see any motion stutter or stopping/waiting of one axis over the other. Granted, I only have 3 commands per motion system, then 2 per while switching between them. I'll try to tax them a bit more with more motion commands to see if/when the queues are affected by quantity of commands.

When I run the above macro, line 15 (G90 G1 A100 F2000) starts a second or two before line 20 (G90 G1 X200 F3000) starts. So the two motion systems don't start simultaneously but it's close enough for what I am trying to do (reduce cycle time by running independent processes simultaneously).

Now, if I do this (at line 15 start P1 with 1 move, switch to P0 and start it with some moves, then go back to P1 and add the removed moves (old lines 16 and 17) to it's queue (lines 23 and 24)):

M606 S1

M596 P0
M400

M596 P1
M400

M596 P0
G90 G1 X0 A0 F2000
M400

M596 P1
M400
G90 G1 A100 F2000

M596 P0
G90 G1 X200 F3000
G90 G1 X0 F3000
G90 G1 X200 F3000

M596 P1
G90 G1 A0 F2000
G90 G1 A100 F2000
G90 G1 A500 F5000
G90 G1 A100 F3000

M596 P0
G90 G1 X500 F5000
G90 G1 X100 F3000
M400

M596 P1
M400

M596 P0
G90 G1 X0 A0 F4000
M400

the 2 axes start pretty much simultaneously. So, it's safe to say there will be a lag before the 2nd queue starts when filling up the 1st queue with it's initial moves/commands, which is totally understandable.

I just need clarification on what the M606 error is all about. What "file" is it referring to?

@droftarts

Here is my test code:
testma.g

M606 S1

M596 P0
M400

M596 P1
M400

M596 P0
G90 G1 X0 A0 F2000
M400

M596 P1
M400
G90 G1 A100 F2000
G90 G1 A0 F2000
G90 G1 A100 F2000

M596 P0
G90 G1 X200 F3000
G90 G1 X0 F3000
G90 G1 X200 F3000

M596 P1
G90 G1 A500 F5000
G90 G1 A100 F3000

M596 P0
G90 G1 X500 F5000
G90 G1 X100 F3000
M400

M596 P1
M400

M598

M596 P0
G90 G1 X0 A0 F4000
M400

Everything works as expected but I get:

as soon as I run the macro. The axes perform the motions in the macro but I get the M606 No file is selected error right away and then the green "complete" or "file processed" message.

My start.g and stop.g files exist but are both empty. I thought it was trying to call one of those so I created them but left them blank.

I've read this a couple of times now:
https://docs.duet3d.com/User_manual/RepRapFirmware/Multiple_motion_systems

I still can't figure out what M606 error is all about.

System is 6HC in SBC mode, CNC mode, and I am sending M98 P"testma.g" from the DWC

@droftarts @dwuk3d

Well, holy fork!

I totally missed the addition of the M606 command in the firmware changelogs. I'll give the above suggestions a shot.

As usual, self-inflicted wounds do the most damage...

@dc42 I can confirm 3.6.0-rc2 multiple motion system works with the code adjustments.

@dc42 But as is stands, M400 waits for both motions systems to stop motion and also prevents one from loading up the second motion system with moves to be executed independent of the first motion system. Could M598 be a "wait for all motion systems to stop and then release axes"? Per the description in the documentation, that's what it should do, but it doesn't unless you wrap some M400's around it.

As you suggest, if M400 was a wait just for that motion system and the processor kept reading code to allow moves in the other motions system, that could work. We would just need a list of G/M codes that stop the processor from further reading code to be processed by the second motion system. I.e., a G4 Px does the same thing as M400 if it's in M598 P0 or P1; further processing stops until the wait is over, then it continues.

I hope to get to my testing today.

@dc42 now that worked but it also caused axis X to wait until A finished it's move to 0mm before axis X started it's move to 0mm.

Macro:

M400
M598
M596 P1
G90 G1 A100 F2000

M596 P0
G90 G1 X200 F3000

M400
M598
M596 P1
G90 G1 A0 F2000

M400

M596 P0
G90 G1 X0 F3000

M400
M598
M596 P0
G90 G1 X100 A100 F2000

But........

Following your logic... if I do this, it works as desired:

M598
M596 P0
G90 G1 X0 A0 F2000

M400
M598
M596 P1
G90 G1 A100 F2000

M596 P0
G90 G1 X200 F3000

M400
M596 P1
G90 G1 A0 F2000

M596 P0
G90 G1 X0 F3000

M596 P1
M400

M598
M596 P0
G90 G1 X100 A100 F2000
G90 G1 X0 A0 F4000
M400
M598

So I switch back to P1 after starting P0 on it's move to 0mm and issue M400. Once all axes are stopped, issue M598, then go back to P0 and add axis A back in. In all of the instances where I use multiple motion systems, I know if P0 will finish before P1 or vice-versa, so I can add this workaround to my macros.

I'll upgrade one of my runtime systems to 3.6.0-RC2 in the next day or so to see if the code change will solve the issue.

Will we get back to where M400 waits for both motion systems to stop, and then M598 will release the axes?

My setup:
1 6HC - @ 3.6.0-rc.2 (was 3.5.4)
3 3HC - all @ 3.6.0-rc.2 (was 3.5.4)
System has 13 stepper axes across the 4 boards (X, Y, Z, A, B, C, D, W, a, b, d, e, f)
System is set to CNC mode M453. This is a non-printer application
RPi 4, 4GB in SBC mode

I'm still having trouble getting multiple motion system to work again. Everything is fine in 3.5.4. Ever since 3.6.x, it has stopped working.

It seems the Duet will not release multiple motion axes after moves are complete. The DWC always reports out:
Error: in file macro line 18: G1: Drive A is already used by a different motion system
when trying to move an axis in a new motion system that it wasn't previously attached to.

I've got a test board set up with 2 axes and I'm running a very simple motion test.

config.g

; General preferences
M453                                                        ; set CNC mode
M550 P"A2000-xx"                                            ; set name of controller
G90                                                         ; set absolute coordinates
G4 P1000                                                    ; 1s delay for CAN comms

; Drives
; Motors are wired to Duet A-A, B-B - motor directions are flipped here
M569 P0.0 S0                                                ; physical drive 0.0 goes forward
M569 P0.2 S0                                                ; physical drive 0.1 goes forward

; Set motion system queue parameters
M595 P100 R50 Q0                                            ; set motion system queue 0 to 100 steps
M595 P100 R50 Q1                                            ; set motion system queue 1 to 100 steps

; Set drive mapping
M584 X0.0 R0                                           ; set linear drive mapping for gantry
M584 A0.2 R0                                           ; set linear drive mapping for gantry

; Set microstepping interpolation
M350 X16 A16 I1                 ; configure microstepping with interpolation for linear motors

; Set axes scale values
M92 X250 A250         ; set steps per mm

; Set max speed change values
M566 X400.00 A400.00        ; set maximum instantaneous speed changes (mm/min)

; Set max speeds
M203 X10000.00 A10000.00        ; set maximum speeds (mm/min)

; Set accelerations
M201 X3000.00 A3000.00                 ; set accelerations (mm/s^2)

; Set motor currents and idle factor
M906 X2000 A2000 I5                                   ; set motor currents (mA) and motor idle factor in per cent

; Axis Limits - minimum
M208 X-200 A-200 S1                                       ; set linear axis minimum

; Axis Limits - maximum
M208 X1000 A1000 S0                                   ; set linear axis maximum

Test program:

M400
M598
M596 P1
G90 G1 A100 F2000

M596 P0
G90 G1 X200 F3000

M400
M598
M596 P1
G90 G1 A0 F2000

M596 P0
G90 G1 X0 F3000

M400
M598
M596 P0
G90 G1 X100 A100 F2000

When I run the program, X goes to 100mm and A goes to 200mm, both starting pretty much at the same time but stopping at different times because of the feed rates.

X and A then return to 0mm, again, starting pretty much simultaneously, but stopping at different times because of the feed rates. All expected behavior.

When the system tries to add axis A back to motion system 0 on line 20, I get:

and the program stops so axis X nor axis A move to 100mm.

I didn't see any change in the documentation for coding multiple motion systems, so let me know if I am using the M595, M596, and M598 incorrectly.

I am able to run any desired test pretty quickly on my test board so let me know if there is anything else I can do to help debug the issue.

@chrishamm Do you have a code snippet for this? Either C or python?

How is it that DWC gets the messages when it's my app that sends the G or M code that causes the warning or error?

I send some commands via HTTP Request and some commands via Command Request. My app uses PyQt for the GUI and their threading classes so I can run in somewhat of a multitasking environment.

My HTTP request:

class HTTPPostRequestThread(QRunnable):
    """
    Send commands to Duet
    via HTTP request
    """
    def __init__(self, *args):
        super(HTTPPostRequestThread, self).__init__()
        self.url = args[0]
        self.command = args[1]
        self.log = False
        try:
            self.logger = args[2]
            self.log = True
        except:
            pass

    @pyqtSlot()
    def run(self):
        try:
            if self.log:
                self.logger.info(f'Sending {self.command} to DCS via HTTP')        
            result=requests.post(self.url, self.command)
            print(f'HTTP Result = {result}')
        except:
            if self.log:
                self.logger.info(f'Failed to send {self.command} to DCS via HTTP')        
            pass

My CommandConnection request:

class CommandRequestThread(QRunnable):
    """
    Send commands to Duet
    via TCPIP socket
    """
    def __init__(self, *args):
        super(CommandRequestThread, self).__init__()
        self.command = args[0]
        self.log = False
        try:
            self.logger = args[1]
            self.log = True
        except:
            pass
        
    @pyqtSlot()
    def run(self):
        if self.command!='':
            try:
                if self.log:
                    self.logger.info(f'Sending {self.command} to DCS via socket')        
                self.connect = CommandConnection(debug=False)
                self.connect.connect()
                result = self.connect.perform_simple_code(self.command, async_exec=False)
                print(f'Result = {result}')
                self.connect.close()
            except:
                if self.log:
                    self.logger.info(f'Failed to send {self.command} to DCS via socket')        
                pass
        else:
            self.logger.info(f'Command for DCS socket is blank')

Result values:

2025-02-25 08:56:50.964 - INFO - Sending M98 P"configuration/om_faults_reset.g" to DCS via HTTP
HTTP Result = <Response [200]>
2025-02-25 08:56:51.253 - INFO - Tab button (5) Manual pressed
2025-02-25 08:56:52.967 - INFO - Sending set global.bFaultPresent = true to DCS via HTTP
2025-02-25 08:56:52.986 - ERROR - At Least One Axis Is Not Homed
2025-02-25 08:56:52.991 - INFO - Sending set global.bCycleAbort = true to DCS via HTTP
HTTP Result = <Response [200]>
HTTP Result = <Response [200]>
2025-02-25 08:56:56.188 - INFO - okPushButton button pressed
2025-02-25 08:56:58.885 - INFO - Tab button (2) Stock pressed
2025-02-25 08:57:02.301 - INFO - Tab button (7) Recovery pressed
2025-02-25 08:57:06.287 - INFO - pbNegDir button pressed
2025-02-25 08:57:06.299 - INFO - Sending M98 P"functions/jog_axis.g" X"X" Y-1 Z"Neg" to DCS via socket
Result = 

Here's the same result but with debug turned on for Command Request:

2025-02-25 09:07:52.514 - INFO - pbNegDir button pressed
2025-02-25 09:07:52.547 - INFO - Sending M98 P"functions/jog_axis.g" X"X" Y-1 Z"Neg" to DCS via socket
send: {"mode":"Command","version":12}
recv: {"success":true}
send: {"command":"SimpleCode","Code":"M98 P\"functions/jog_axis.g\" X\"X\" Y-1 Z\"Neg\"","Channel":"SBC","ExecuteAsynchronously":false}
recv: {"result":"","success":true}
Result = 
2025-02-25 09:07:55.234 - INFO - Sending M98 P"configuration/om_faults_reset.g" to DCS via HTTP
HTTP Result = <Response [200]>

The HTTP request in the above example is just setting globals so the [200] is expected as there are no errors.
The Command request shows no result returned (or success in debug mode). The command for this instance was a G90 G1 X-1 when the axis was not homed, so there was an insufficient axes homed error, which the DWC caught, somehow.

DWC:

@rero unfortunately, your assumption is incorrect. I am asking about those messages that are not a part of the object model. I have been capturing the object model for 2 years now with my custom app and I am looking to be able to disable the DWC once I can get the error messages read by my app. I am creating my own "DWC" that is custom to my application (which is not a printer).

The object model messages do not include the "error (RED)" or "warning (YELLOW)" type of messages when there is an overall problem with the system, i.e, any yellow or red message that pops up on the DWC as a banner on the bottom of the DWC webpage or itemized in the Console page/tab as they occur.

From what I can tell, when an error occurs in DSF, the message is "pushed" out there. I need to know where "there" is so I can capture it. I believe the intercept example you and @droftarts sent has me on the right track but I'm still missing a piece of the puzzle.

If I send a non-supported G code from my app, the DWC reports with a yellow warning as an non-supported G command. If I sent a poorly formatted G command, the DWC reports with a red error message with the issue with the command. Neither were sent by DWC yet both were captured as a warning and error by DWC. So something else is at play than just the reading the OM.

Running the intercept example as .PRE or .POST will stop the DWC from reporting those messages. But I can't see within the intercept responses the error message itself unless it is what I mentioned before and there is a lookup table in DWC to textualize the error from the reported code.