@droftarts
I had never heard of such surges occurring at installation sites, so it was unexpected.
I plan to replace all the tool boards I use.
I think the firmware version of the 1LC was 3.4.4.
1LC should not have had 3.4.5.
sorry. I can't confirm it right away because I don't have the equipment at hand.
I think additional surge protection should be added to the AC circuit.
Is a protective component like a varistor necessary on the DC side as well?
We operate a tool change system using duet 3 mini 5+ and 4×1LCs.
The other day, there was a power outage at the factory while the 3D printers were still on. It seems that the printer's breaker was still on when the problem was restored. At this time, I think an opening/closing surge occurred and caused a failure in the board.
What I am currently finding fault with is the following:
・His OUT0 FET of mini5+ broke down.
・12864LCD backlight no longer shines (display side is not broken)
・The temperature sensor (pt1000) of T3 connected with 1LC is broken and the resistance becomes infinite ohms even when measured.
These problems were temporarily resolved by replacing the mini5+ and temperature sensor.
After the repair, when I executed a print job that took about 26 hours, an error like the one shown in the image occurred and the machine stopped in an emergency.
When I searched the forum for similar errors ,it was said that the problem was caused by SSR noise. I use an SSR with a zero cross function, so I had never encountered this error before this failure occurred.
It is unclear whether 1LC was also damaged by the surge.
Does this error occur not due to SSR noise but also due to a failure or heating error in the 1LC itself?
I would like some help as there is not much explanation about this error.
About the device configuration
Main board: duet3 mini5+ firmware: 3.4.5
Distribution board: Yes
Tool board: 1LC × 4
Operates on Raspberry Pi 4
Power supply: 24v & 5v
power environment : Single phase AC 100V 60Hz
Switching power supplies do not have surge absorber varistors.
@dc42 Thank you for the additional information! , I trt it !
Thanks to your support, we have successfully configured the firmware and will soon be able to release our tool change 3D printer!
@OwenD
When I changed it to param.D, it worked! !
{param.B} => {param.D}
G4 P10 ; delay 10ms to debounce
if sensors.filamentMonitors[{param.D}].status="ok"
echo "switch bounce detected - error cancelled"
M99 ; break out if sensor value is zero again (bouncing)
; if we got this far the switch is still showing no filament
M25 ;pause
Now let's continue with the printing test! 
@OwenD
thank you!
I immediately inserted the code and tried it out, and it worked as expected!
There is just one problem, because my 3d printer is a tool change , the [] part of "sensors.filamentMonitors[0]" changes depending on the head used from 0 to 2.
How can I make it compatible? Thank you for your wonderful support.
I am currently using a simple switch type filament sensor for my tool change 3D printer.
Printing is temporarily stopped due to a momentary false detection by the filament sensor, so I found a previous post while searching for a timeout period.
Re: Simple switch Run-Out Sensor too sensitive. Add timeout?
I would like to write a function similar to this in daemo.g, but I don't really know how to write it.
(https://forum.duet3d.com/post/187835)
Can you provide me with a sample daemon.g code like the one written here?
I find this mechanism a little difficult to code.
RRF for Duet 3 Mini 5+ version 3.4.5 (SBC mode)
PS. I am developing a tool change 3D printer in Japan.（https://twitter.com/Senju_3Dprinter)
@dc42 Thank you for teaching me how to write Gcode.
It worked fine and the shutdown was performed!
I'm using M911 to monitor the voltage of the PSU and perform a shutdown when necessary.
M911
My Duet is duet mini 5 + ,DSF Ver3.4.5
I would like to execute the RasPi shutdown command along with this process.
Does anyone know how to get the Raspberry Pi's shutdown to work with this code?
Note: I plan to connect a battery to the Raspberry Pi for short-term UPS purposes using a supercapacitor, allowing it to maintain power for about one minute.
This is the power supply board.
I added [M999 B-1 P"OFF"] that can be used with the DuetPi plug-in in the M991 code generated by RRF Configurator.
DuetPi Management Plugin
M911 S19.8 R22.0 P"M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000 M999 B-1 P"OFF""
However, when I restart the system, I receive an error in config.g.
I also attempted to create a shutdown macro by including "M999 B-1 P"OFF"" as a separate command, but that didn't work either.
If this can be executed, I think that it can shut down automatically and safely.
Can anyone help me?
I read the official emergency stop switch settings and connected the B contact switch, but it didn't work when I pressed it.
Firmware version is 3.4.5.
Mini5+ is V1.02
Duet 3: Connect to any available IO connector, between 3.3V and IO_x.in.
https://docs.duet3d.com/User_manual/Connecting_hardware/IO_E_stop
I wrote code in config.g.
;EMS button
M950 J5 C"0.io5.in"
M581 P5 T2 S1 R0
I attached the B-contact emergency stop switch connector to 3.3V and "0.io5.in", but the trigger did not respond when pressed.
When connecting a general end stop, I think that a switch is connected to GND and "0.io5.in", so I connected the emergency switch this way and it worked.
Is my connection wrong? Or is the description on the site incorrect?
I've tried other common mechanical switches with the 3.3 and "ioXX.in", but they don't respond as well.
Currently, I am building a 3D printer system using the Duet3 Mini5+.
To prevent potential damage to the Raspberry Pi's SD card due to the loss of AC power to the 3D printer, I am considering implementing a read-only mode using the Raspberry Pi's Overlay File System.
If I enable the Raspberry Pi's Overlay FS, I understand that the following will occur:
・G-code and other files will not be saved to the main SD Card 0.
・Modifying .g files or using commands like M500 will result in them being reset when the power is turned off.
Are there any potential issues or problems that may arise with DWC or any other aspects besides the ones mentioned above? For example, could DWC's performance become unstable?
If I want to ensure stable operation of the Raspberry Pi, would it be advisable to increase the memory (RAM) size?
As I intend to provide the printer as a product, I actually consider it safe for firmware configuration files and settings to revert to the factory state when the power is turned off.