Topics created by davidjryan

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

changed out both 3HC boards reporting the reset - no change in frequency from 1 per hour changed out all 3 3HC boards - issue reduced in frequency to 1 per day 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.

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

When we started this project 2 years ago, we put everything into the /sys folder because of the M98 info. I just wanted to make sure we weren't missing out on any fun by not having them in the /macros folder. We do not need them to show up in the DWC so I'll leave my files where they are.

Thanks, gents!

@droftarts thanks - I've been wrestling with M598's a lot over the last few days - trying to get parallel tool changing working (not actually parallel printing).

I am flipping between two motion systems - trying to kick off a process on the other motion system just before the current motion system finishes.

I'm getting close to getting it working - but I've at the moment I've more or less given up on using M598's. - as when you keep alternating between using them on different motion systems (a) sometimes they work fine, (b) sometimes they wait for around 20 seconds for no apparent reason. (c) Sometimes they hang and finally (d) sometimes they seem to just finish even though the other motion system is working on stuff.

I tried using axes machinePosition to tell what the opposite gantry was up to - but that doesn't seem reliable either.

So I have settled on using global variables to flag when the other motion system is parked - so when it is safe to proceed.

Seems to be working ok so far.

@chrishamm

I've created a function to subscribe to the OM. It sees some of the error messages but not all of them.

From the DWC Dashboard:

When I try to overtravel an axis, the message comes through to my app and the DWC console. If I try to set a global variable that doesn't exist, the message does not come through to my app but it does show up in the DWC console. If I try to run a macro that doesn't exist with M98, the message does not come through to my app but it does show up in the DWC console.

The terminal screen on the right shows just the 'message' portion of the OM patch once I receive the full OM on the first call, I didn't want to dump the whole patch on each patch iteration, just when a new message shows up.

The DWC console "sees" everything, my app only saw the target position error.

9c0bcc0d-ec44-403a-9c8b-bcbc783ffaed-image.png

Does the source of the command call to the DSF matter (my app or DWC) in determining where the message goes?

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