For M291, there are currently 4 options:

0. No buttons are displayed (non-blocking)
1. Only "Close" is displayed (non-blocking)
2. Only "OK" is displayed (blocking, send M292 to resume the execution)
3. "OK" and "Cancel" are displayed (blocking, send M292 to resume the execution or M292 P1 to cancel the operation in progress)

Can we get a 5th option that elaborates on #3's "OK" and "cancel" and maybe allows more than 2 buttons? Instead of "OK" and "cancel", allow us to insert our own button text followed by a Gcode or meta command for each instance which would allow the buttons to lead out of the current program into a subprogram. An example of where this would be handy is for machine setup where we have loads of machines in a farm and not all of them are identical. Individual programs stored in the macros to do specific functions would be linked together in a procedural manner by the mechanism of using buttons containing M98commands in a main program. When it comes to regular maintenance in a program called something like maintenanceROUTINE.g, the first prompt would be something like:

MACHINE MAINTENANCE ROUTINES
What components were changed?
[Bed surface] [Hotend] [Feeder] [New Printer Setup]

=>Selecting Bed surface could call G32
=>Selecting Hotend could call my macro to calibrate the heater PID and Z positions
=>Selecting Feeder could call my macro to guide through my measuring and tuning process of how to plug in settings for steps applied/mm
=>Selecting New Printer Setup would behave much like "OK" currently does allowing the current program to continue, guiding the technician through the entire process, ensuring they dont miss a step.

When each step is completed, a prompt for "Finished" to exit the program or "Do more" which would lead back to the start allowing multiple items to be addressed.

Another use: when having the printer start by a subprogram such as printBEGIN.g, you can have M291ask if the printer bed is cleared. Currently, clicking "cancel" stops the subprogram and leads back into the main program, thus, starting the print in a manner that was not intended to run without printBEGIN.g.

@jay_s_uk said in 12864 Display Unresponsive on Preheat Page 3.3b2:

@leckietech Theres a dropdown menu top left in system to switch to the menu/display files

Ah, got it. Thanks, heres a photo for anyone stuck in the future:

@jay_s_uk just found the issue. the connector bringing power to the hotend is slightly melted. I wiggle it and see the graph get corrected. my god, the simple things, huh?

@dc42 YES! M150 finally controls some 2811 LEDs on my Wifi2! Thank you for this!

@phaedrux Ha, it works. Cant wait to apply this at work tomorrow. What I am using it for: we have 4k nest cameras on each rack of 12 printers. In the middle of the night if I need to check on them the room is too dark so Ive got a wifi switch that ill connect a 12v supply to and trigger a micro relay at the duet board closing this contact thus turning on the lights of each printer for any given rack. I wish we could just connect the printers together with CAN BUS and send global messages to do things like this or tell all 60 of my current duet printers to preheat, or send a command over the internet to stop any one print. Ive already got our main supplies wired to a smoke detector to immediately disconnect the power and battery backup at the first sign of smoke. With safety out of the way, now I just need some other features for production. Thanks again for the help!

@bearer I'm confident a static discharge strap would have saved the board in a passive operation as routine as swapping out a bowden tube. But now that I've been here, I will certainly take more care next time and clip a ground cable to my cutters or make sure there is no place for the discharge to arc to. Live and learn!

@fcwilt said in M150 Crashes My Duet3 Mini5:

Is there a reason you want to use M190 to wait rather than just turning off the bed heater with M140?

It's so the print head can use the part fan over the center of the bed to assist in cooling the bed for faster part removal, also, our team tends to remove parts when the bed is too hot causing damage to the print surface or part. This is a good way to prevent these mistakes.

@jadonm did you ever figure it out? Ive got 2 machines on my bench testing the Fysetc 12864 display and Im seeing this issue only within the preheat menu. The text file looks ok and nothing seems out of the ordinary. its doing it on a duet3 mini and a duet 2. Both have the same symptom that can be cleared by resetting the board. Ill probably go in and delete one function at a time to see what is triggering this to happen.

I print tonnes of PETG and something that I realized the hard way early on is like pla and abs, not all petg's are made equally. Some print super nice with basic settings and some need excessive work in my experience. But in all cases, I've never had peeling problems printing on glass or aluminum beds with a piece of Kapton tape. You can usually get pretty high mileage out of it too if you get a quality tape. I definitely do not recommend printing directly on glass. Youll have lifting.. more lifting and all of a sudden like DC42 says, its sticks and sticks too well. I've taken chunks out of glass beds! Youll need to remove it by heating your bed to something high like 115c and destroy your part to get it off the bed without chipping the glass.

And for warping, I don't get any of that printing inside a fully enclosed build chamber where the ambient temp is around 45 with a 85c bed temp.

@fcwilt said in M150 Crashes My Duet3 Mini5:

@leckietech
So you don't use one of the removable bed surface products?

Hey thanks for the suggestion! But we already manufacture our own from 0.012" spring steel cut on our fiber laser and embedded magnets into an aluminum plate we run on our haas. Makes it easy for changing our Kapton tape bed surface but that's about it. If you factor the labor on removing and reinstalling 60 bed plates 3 times a day and heaven forbid the guys touch the surface with their fingers causing the next print to not sick or debris ends up between the print surface and aluminum plate, it just makes sense for us. When the bed reaches 40c, the print is basically 100% released.

My script has been working fine for 2 years, 10's of thousands of prints, no problems! its just recently become an issue because we added LEDs to all of our printers via the Fysetc 12864 screen, therefore, requiring M150 commands.

@dc42 Thank you, this is what i needed to know to add additional sensors to my printers.

@zapta said in Convert PT100 Daughter Board to PT1000?:

What duet board are you using? Generally speaking, PT1000 doesn't require a daughter board and can connect directly to the duet. You do need to tell the duet though that this is a PT100.

im using Duet 3 mini. I need 2 additional sensors for my build. One for the cooling fan air intake and one on the LDO motor feeder.

@achrn I have a 1mm pitch 300mm long FFC driving my hotend. The wiring path for the sensor has to travel through this.

I was looking at the documentation for the MAX31865 used in the PT100 daughter board. I have long leads on my sensors so i think 100ohm sensors might be problematic for my application and also, I have lots of 1k sensors. Could I change out R1 and R3, and R2 and R4 with the appropriate resistors to compensate for the 1k sensor? I think I could leave the filter caps larger and it should be fine as I dont need super fast readings.

@dc42 thanks for the quick response. The board is using 2209 drivers so I believe the default mode is stealth chop according to Duet documentation as I didnt declare it with M569. I am running 256 steps, what mode would you suggest I run the drivers in to overcome this issue in the future? Spread Cycle, maybe?

Hi guys. On our printer racks, we have Model S batteries in parallel with the output of the power supplies for every 2 racks (24 printers) powering all Duet3 minis. The batteries are "ideal" diode isolated for min working voltage drop while preventing surge charging. We just encountered our first major power outage where we lost power for about 2 hours during full operation. The good news - the majority of the printers survived the event. Bad news is 2 printers heater faulted which is to be expected as the battery voltage became too low to heat the hotend to temperature but more interestingly, 3 other printers had a motor driver short fault once the battery hit around 20 volts. The fault was persistent even when the power was restored bringing the rail voltage back up to the normal 25 volts. Hitting the reset button on the printers did not help but power cycling did. None of the drivers were actually damaged. I suspect this simple inexpensive approach for battery backup of this scale may need a pricy investment in a custom power supply on the battery to give me a stable CV output. Cost aside, I would like to not go that route as adding any additional switching would cut battery runtime even with high efficiencies of 90% or so. Curious of your thoughts on this @dc42
image url)

@phaedrux Thank you!

@phaedrux
M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.2.2 running on Duet 3 Mini5plus WiFi (standalone mode)
Board ID: 1H88H-V196U-D65J0-40KMU-0Z03Z-RQD4F
Used output buffers: 1 of 40 (1 max)
=== RTOS ===
Static ram: 98732
Dynamic ram: 106368 of which 552 recycled
Never used RAM 39564, free system stack 136 words
Tasks: NETWORK(ready,518) HEAT(blocked,362) CanReceiv(blocked,947) CanSender(blocked,372) CanClock(blocked,363) TMC(blocked,123) MAIN(running,634) IDLE(ready,20) AIN(blocked,269)
Owned mutexes: USB(MAIN)
=== Platform ===
Last reset 00:03:21 ago, cause: power up
Last software reset at 2021-09-01 21:06, reason: User, GCodes spinning, available RAM 33744, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Aux1 errors 0,0,0
Supply voltage: min 0.0, current 0.9, max 0.9, under voltage events: 0, over voltage events: 0, power good: no
Driver 0: position 0, ok, SG min/max not available, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0
Driver 1: position 0, ok, SG min/max not available, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0
Driver 2: position 0, ok, SG min/max not available, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0
Driver 3: position 0, ok, SG min/max not available, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0
Driver 4: position 0, ok, SG min/max not available, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0
Driver 5: position 0, ok, SG min/max not available, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0
Driver 6: position 0, ok, SG min/max not available, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0
Date/time: 1970-01-01 00:00:00
Cache data hit count 475358797
Slowest loop: 0.19ms; fastest: 0.12ms
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 0.2MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = -1 -1, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is ready with "M122" in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 0.19ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 0 of 8

• WiFi -
  Network state is disabled
  WiFi module is disabled
  Failed messages: pending 2779096485, notready 2779096485, noresp 2779096485
  Socket states: 0 0 0 0 0 0 0 0
  === CAN ===
  Messages queued 1009, send timeouts 1008, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 16
  ok

M22
SD card 0 may now be removed
ok
M21

Error: M21: Cannot initialise SD card 0: Card is unusable
ok

@phaedrux we are running mostly Duet 3 mini and do have a stockpile of rbp3b+ from our octoprint days. I don't know how confident I am however in code setting something like this up, or do you think I could connect with google drive with linux?

Hi guys, we now have 60 printers and it's becoming quite cumbersome to load files to them all. Almost daily, we have new files to print but also we may print many repeats from years ago. What I would just love is to have all my files stored in one location or a way to push my database to all the printers at once so I can add, delete, or edit the files from one place. Then for my print queue for each printer, I would configure a google sheet to input the file names and output a text file which will call the files in order to print and prompt to start the next file once a print is complete. Anyway, something like this would save us loads of time! Any ideas or is this a fiction fantasy?