Multiple Print Failures
-
Warning: SPI connection has been reset
Warning: Lost connection to Duet (Timeout while waiting for transfer ready pin)
Warning: Lost connection to Duet (SPI connection reset because the number of maximum retries has been exceeded)M122.txt Errors.txt
config.g.txtI've been having a number of print failures with the above errors, but usually after a successful print (the same object), where the print just stops (all motors off) and the heaters are all switched off, but he SBC still shows the active temperatures....
To recover the machine I have to go through a full power recycle.
I've checked all connections, power supplies etc. and all good, so any ideas on what I can check for, before I try enabling diagnostic mode ??
-
@Dr_Ju_Ju It looks like the SPI connection between Duet and Pi is picking up interference causing the link to fail. Do you have the whole machine grounded to the Duet's GND line? If yes, try replacing the ribbon cable.
-
Hi Chris,
Yes everything is fully earth bonded, and I've also replaced the interconnections....
-
@Dr_Ju_Ju Please note that earth (PE) is not ground (GND). Also try to avoid running motor/heater cables over the SPI ribbon cable if possible.
-
no motor cables come anywhere near the SPI connection, or any other cables, apart from the case fans, which come on/off at the start and end, of a print.
All 0v lines are bonded to earth, I don't believe the problem is environmentally connected, as I have multiples printers running concurrently, with no problems
-
@Dr_Ju_Ju Did this printer work OK at some point? If it did, what has changed since then?
-
@gloomyandy
yes it used to work fine, and even now it can still produce some great prints !! but it also wastes filament & time when it just stops at some point during a print -
@Dr_Ju_Ju So what if anything has changed since it was working well? Have you updated anything? Changed any of the printer hardware?
-
@gloomyandy
no hardware changes, & just the normal software updates pre & post the problems ... -
If you have spare hardware can you try swapping the Pi and then the Duet with one that is working?
-
@Dr_Ju_Ju do you really need to run in SBC mode? If you're not using something like pythonDSF I would just ditch the pi and run in standalone mode
-
I don't have a spare Pi @ the mo, but I do have a Rock64 / Rock64Pro spare both running Mate, so will the Duet SBC software run on them ??
I suppose it comes down to what the Voron recommendations were, also I originally tried a Duet2 ethernet (not on this 'Voron' but a previous iteration), in non SBC mode, which was an abject failure, so I was hoping that a Duet3-SBC, would be better....
-
@Dr_Ju_Ju IMO, standalone mode is better. Majority of my machines run as standalone
-
Hi I've a similar problem sometimes in SBC mode - https://forum.duet3d.com/topic/34315/rff-3-5-0-rc1-spi-reset-mid-print
since chris gave me the hint about the interference I was working on that topic to get down to the problem. So I hooked everthing up to a spectrum analyzer and saw that the 8MHz SPI bus is generating a lot of noice and harmonics.
green line is the 6xd in standalone mode, and the pink color is the 6xd in sbc (rock 4c+) with 130mm ribbon cable without ferrit or shielding.
the green line is the 6xd in sbc mode with 30mm ribbon cable.
the following shows in pink the 6xd connected to the rockpi c4+ with 130mm ribbon cable with one ferrit 139 Ohm @ 100MHz on the sbc side.
the following shows the 130mm ribbon cable without a ferrit but aluminium foil as shield.
for reference the rock 4c+ without the duet
so it can be seen from the above, that shielding and ferrit will help to reduce emi and emc - I'm working on that topic, as it is not satisfying for me.
Maybe, you can put a ferrit core around the ribbon cable and make it shorter as a quick measure.
But anyhow, the print should not stop, even if the spi need to do a restart - that should be handled by the software to do a resume - as I can do a manual resume in such case.
-
@timschneider The SPI protocol between Duet and SBC is designed to retry three times in a row on failed transfers. If that count is exceeded, both endpoints reset the connection.
-