Topics created by davidjryan

@davidjryan I'm sorry but I can't really help with Python scripts. Here the corresponding example: https://github.com/Duet3D/dsf-python/blob/v3.6-dev/examples/custom_m_codes.py Instead of PRE you need to set the interception mode to Executed, then you should be able to inspect the results of executed G/M/T-codes. Of course that plugin needs to run on the SBC itself, you cannot intercept codes remotely without additional infrastructure. Also make sure that your user is part of the dsf group or let it run as root to avoid permission issues while developing.

You can find the source code of the CodeLogger utility here: https://github.com/Duet3D/DuetSoftwareFramework/blob/v3.5-dev/src/CodeLogger/Program.cs See the corresponding wiki -> Third-Party plugins for further details if you want to write a .NET console app.

@davidjryan thanks, we've established that it's specific to SBC mode. We've implemented and tested a fix in RRF, which will be in the next public build. Thanks for reporting this.

@davidjryan thanks, we are looking into this and the other report here:
https://forum.duet3d.com/topic/36866/multiple-motion-system/47

@davidjryan I just implemented a change in DSF to avoid that re-racking problem.

@davidjryan There are also the instructions here: https://github.com/Duet3D/DuetSoftwareFramework/wiki/SBC-Setup-Guide#unstable-package-feed
Though I think they are the same is in the wiki.

Are you on Debian Buster? You should be on Bookworm to run 3.5 or newer. We recommend starting with a new DuetPi image, as trying to upgrade from Buster to Bookworm breaks too much. See https://docs.duet3d.com/en/How_to_guides/SBC_Buster_to_Bookworm

If you're still having problems, and reverting to an older version, you probably need to run the 'Downgrade packages' instructions: https://docs.duet3d.com/en/User_manual/Machine_configuration/DSF_RPi#downgrade-packages or https://github.com/Duet3D/DuetSoftwareFramework/wiki/SBC-Setup-Guide#downgrading-to-stable-packages

Ian

@chrishamm That works, thanks!

@davidjryan thanks, corekkted.

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!

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

@T3P3Tony Thanks, Tony!
I have the longer form implemented and all works well.

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

@davidjryan Thanks for reporting this, it will be fixed in the next version.

@davidjryan this is fixed in RRF 3.5.0-beta.3 which we hope to release later today.