Best posts made by davidjryan

@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!

@rkutun

Check:
/etc/xdg/lxsession/LXDE-pi/autostart
~/.config/wayfire.ini
~/.config/labwc/autostart

It all depends on which windowing system you are using, X11, Wayfire, or Labwc

Per the smartypants gurus here:
https://forum.duet3d.com/topic/37316/sbc-rpi4-bookworm-3-5-4-disable-chrome-startup?_=1746822121050

@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 I can verify that the root cause is not reset button press, metallic debris, shorting of J32, condensation, or missing R30. Which leaves us ESD. We do have 24V brushed vacuum pumps on the system connected to out0 through out4. The odd thing is that the issue does not necessarily happen only when any one of the pumps is on. The issue has occurred with pumps being on or off.

So here is what we've tried in the past few weeks:

1. changed out both 3HC boards reporting the reset - no change in frequency from 1 per hour
2. changed out all 3 3HC boards - issue reduced in frequency to 1 per day
3. changed out 6HC board - issue greatly reduced in frequency to less than 1 per week

Now that the stoppages are so infrequent, the heat is off for the time being.

The next thing we are trying will be to get brushless vacuum pumps to replace the brushed units.

I'll table this issue for now and report back when the brushless pumps arrive.

I've gone a few days now and the multiple motion systems is working well. I'll call this one closed.

Thanks for the assist!

@droftarts @rero

Son of a #$@#!

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

@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.

@Leonard03
I don't have an answer for your original issue, but...

If you want to get your config.g to run with M98 without the error after startup, you can use the exists() function to check if the global already exists and use the result to skip defining the globals again.
https://docs.duet3d.com/User_manual/Reference/Gcode_meta_commands

So this,

global MMUmode = true					; enable or disable Multi Material Unit
 
if global.MMUmode = true
	global spoolJoin = false			; enable or disable the SpoolJoin feature of the Multi Material Unit
	global useCutter = true				; enable or disable the CUT feature of the Multi Material Unit
 
	global statusBondtech = 0
	global statusFinda = 0
	global currentSlot = {null, null}		; [0]last loaded slot, [1]last tool temperature
	global loadNext = false
	global pause = false
	global tcBlock = false
	global counter = {0,0,0}			; [0]extruder count, [1]fails, [2]total attempts
	
global errQueue = {null,null}

becomes this,

if !exists(global.MMUmode)
        global MMUmode = true

if global.MMUmode = true
        global spoolJoin = false			; enable or disable the SpoolJoin feature of the Multi Material Unit
        global useCutter = true				; enable or disable the CUT feature of the Multi Material Unit
         
        global statusBondtech = 0
        global statusFinda = 0
        global currentSlot = {null, null}		; [0]last loaded slot, [1]last tool temperature
        global loadNext = false
        global pause = false
        global tcBlock = false
        global counter = {0,0,0}			; [0]extruder count, [1]fails, [2]total attempts
        	
if !exists(global.errQueue)
        global errQueue = {null,null}

Then just change the true to false on line 2 to achieve the mode your desire between reboots.

You only need to check MMUmode because if MMUmode doesn't exist, then none of the globals can exist because MMUmode is used to create all of the other globals.