I am working on my own farm management tool where i extract data from the printer by interpreting the JSON data from rr_model.
What I want to do is display the thumbnail in a webbrowser. I can see the gcode filename, the size and offset of the thumbnail but i can't extrapolate the actual image datastream. The only way i can get it is by sending M36.1 command in the console of the WDC. But that I can't see from my webpage.
How can I get the thumbnail adres or data?
@chrishamm Wow that would be amazing! Can you give anymore info? Maybe screenshots? What platform is it?
When do you expect it to be released?
Or even better, do you need a real life tester? As said, I have 60 machines doing full time production.
I have over 60 Duet 3 powered machines running. They work amazing but uploading gcode files to them is a pain. For each printer I need to go to it's address, go to jobs, select the job and upload. This is a pain in the **** to do that every day or sometimes multiple times a day. Is there a command i can give to push a gcode file to the printer?
Preferably through a web page or something. That way I can select a file, tick all the printers that I want to sent it to and hit go.
Is that possible?
@gloomyandy
I understand but as you said it is not that simple. The way of work, the machines, firmware and even the gcode has not changed. As far as I know no changes were made to the network as well.
At this point I now have a total of 6 machines that had this. All in one morning.
Ok printer 4 just had the same issue. 
Here's the deal. We run a lot of printers. All run 3.4 firmware and have been running perfectly for months.
Suddenly, starting today, I already had 3 printers that were happily printing and suddenly stopped dead in the water.
They all generate a Software cause for the reset with error code 0x4112: Last software reset at 2022-06-08 09:04, reason: StackOverflow
Here is the full M122 for one of the machines:
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.0 (2022-03-15 18:57:24) running on Duet 3 MB6HC v1.01 or later (standalone mode)
Board ID: 08DJM-9P63L-DJ3T0-6J9FD-3S46P-9V1V8
Used output buffers: 1 of 40 (22 max)
=== RTOS ===
Static ram: 151000
Dynamic ram: 96488 of which 92 recycled
Never used RAM 103092, free system stack 200 words
Tasks: NETWORK(ready,25.8%,251) ETHERNET(notifyWait,0.1%,6) HEAT(notifyWait,0.0%,321) Move(notifyWait,0.0%,352) CanReceiv(notifyWait,0.0%,772) CanSender(notifyWait,0.0%,374) CanClock(delaying,0.0%,339) TMC(notifyWait,7.9%,92) MAIN(running,66.2%,925) IDLE(ready,0.0%,30), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:16:45 ago, cause: software
Last software reset at 2022-06-08 09:04, reason: StackOverflow, none spinning, available RAM 99160, slot 1
Software reset code 0x4112 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0043c80e BFAR 0x00000000 SP 0x2045ffbc Task ETHE Freestk 63981 bad marker
Stack: 204217ac 204217e0 00484c39 00000000 2041f388 00000000 004842a9 204217fc 20424cac 00000000 00f00000 e000e000 c0000000 00000000 004843c5 00484154 21000000 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 127
MCU temperature: min 33.9, current 34.1, max 43.3
Supply voltage: min 23.5, current 23.6, max 23.7, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.2, max 12.2, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, mspos 790, reads 34575, writes 14 timeouts 0
Driver 1: standstill, SG min 0, mspos 642, reads 34575, writes 14 timeouts 0
Driver 2: standstill, SG min 0, mspos 854, reads 34575, writes 14 timeouts 0
Driver 3: standstill, SG min 0, mspos 578, reads 34575, writes 14 timeouts 0
Driver 4: standstill, SG min 0, mspos 322, reads 34575, writes 14 timeouts 0
Driver 5: standstill, SG min 0, mspos 394, reads 34576, writes 14 timeouts 0
Date/time: 2022-06-08 09:21:04
Slowest loop: 4.36ms; fastest: 0.05ms
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 3.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 0, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 1 is on, I-accum = 0.0
=== 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 idle 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
=== CAN ===
Messages queued 9060, received 12081, lost 0, boc 0
Longest wait 2ms for reply type 6053, peak Tx sync delay 170, free buffers 50 (min 49), ts 5026/5025/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 4.63ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
HTTP sessions: 2 of 8
- Ethernet -
State: active
Error counts: 0 0 0 0 0
Socket states: 5 2 2 2 2 0 0 0
What is happening with my printers?!?
Just a side-note: this is in a production environment. I had a job that was running for far in the 90hours when this happened. So please help me diagnose this issue before I lose more printers and days of work...
@dc42 Looking forward to it! Thank you all for the help.
@dc42 Any estimation when it will be released? 
I am building a large farm of printers. To keep track of all that is being printed I have made a simple but effective Farm Monitor. It is basicly a webpage that polls every printer for their JSON info. It filteres and extracts the info it needs and displays it on the webpage.
Here is a screenshot of the first few printers to give you an idea:
Basicly, printers that are happily printing are not interesting so they are greyed out. When the print is nearly finished the background gets brighter until it is white when finished. Different shades and colors for Pause, Errors etc.
Values that are not normal are displayed red.
So far so good.
But, I want to add a quality control (QC) option to the printers with a feedback to the Farm Monitor.
Is there a way to ask on the PanelDue for QC input via M291 for instance and feed the outcome to a JSON variable? That way I can read that variable from the duet and mark the part not only as finished but also as QC passed. It then can report to the database that the print is indeed acceptable and a new file will be pushed to the printer.
Sidequestion: Is it possible to change the answers from M291 from OK/Cancel to Yes/No for instance?
I need a fairly large quantity of Pi's for a lot of machines i'm building. But the delivery time is insane. It is now scheduled for 11-2022.
Is there an alternative that works with the Duet 3?
One that comes to mind is the Orange Pi PC2. But there are many SBC's out there. Has anyone tried anything yet?
Well i need the machine to work so I ripped the toolboard out of my home printer and just layed a lot of wires. Problem fixed.
But now, I wanted to use the toolboard as an upgrade to my work printers. Totally different design. But similar 6HC mainboard and a new 1LC toolboard. This time a v1.2. Guess what? Same issue!
Start great and suddenly it goes into overdrive.
I made a cross post in this topic (https://forum.duet3d.com/topic/26697/toolboard-1lc-heater-falut-mid-print/7?_=1641814629460) where someone has at least part of the symptoms I have. Here is what I had this morning:
Had a 88 hour print and it failed midway. Temp sensor says 2000 degrees but the printer doesn't go into error mode, it just continues.
I then stopped the print, decoupled the thermistor and connected a brand new one. Temp still at 2000.
Reset just the board with the 2 buttons, no effect. Reset the board with M999 B121, no effect. Unplugged the power from the toolboard, no effect.
Only after pressing the reset button on the 6HC it came back online and with the original temperature sensor...
All run the same firmware, 3.4.0beta7.
That was this morning. I then did a restart of the print and the result is above. Again 2000 degrees, printer goes into overdrive and print failes. But printer still keeps on moving...
@fotomas I pressed the reset button on the mainboard.
Ok, I have the exact same issue. I had it before but it coinsided with another error and eventually i ripped the toolboard of the printer (see https://forum.duet3d.com/topic/25908/extruder-motor-suddenly-getting-extremely-hot).
But now I have a completely different printer and a different toolboard but it still happened.
Had a 88 hour print and it failed midway. Temp sensor says 2000 degrees but the printer doesn't go into error mode, it just continues.
I then stopped the print, decoupled the thermistor and connected a brand new one. Temp still at 2000.
Reset just the board with the 2 buttons, no effect. Reset the board with M999 B121, no effect. Unplugged the power from the toolboard, no effect.
Only after a reset of the 6HC it came back online and with the original temperature sensor...
All run the same firmware, 3.4.0beta7.
@hackinistrator
You dir sir are my hero of the day. Turned the bed heater off after the first layer et voila:
So i checked the config with the other printers. It is not completely the same (others are Duet 2 with RRF2) but i missed 1 tiny thing.
This line: M307 H0 B1 S1.00
The B1 had to be a B0... 
Problem solved, case closed. I thank you all for your time and input!
Ok so new update.
Swapped the Sherpa extruder for a brand new orbiter, changed the steps/mm etc accordingly.
No change.
Tried 3rd roll of filament that came from another printer that printed fine with it.
No change.
Unrolled a couple of meters of filament to eliminate the spoolholder.
No change.
It is something that changes based on a certain amount of extruded filament but it is not the extruder...
M584 X0.4 Y0.5 Z0.0:0.1:0.2:0.3 E1.0 ; set drive mapping
M350 X256 Y256 Z64 E32 I0 ; configure microstepping without interpolation
M92 X800.00 Y800.00 Z12820.00 E1402.00 ; set steps per mm
M566 X900.00 Y900.00 Z150.00 E900.00 ; set maximum instantaneous speed changes (mm/min)
M203 X30000 Y30000 Z300 E12000 ; set maximum speeds (mm/min)
M201 X2000 Y2000 Z150 E1500 ; set accelerations (mm/s^2)
M906 X2000 Y2000 Z2000 E500 I50 ; set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout
;Hotend 1
M308 S1 P"1.temp0" Y"thermistor" T100000 B4725 C7.06e-8 ; configure sensor 1 as thermistor on pin 1.temp0
M950 H1 C"1.out0" T1 ; create nozzle heater output on 1.out0 and map it to sensor 1
M307 H1 B0 S1.00 ; disable bang-bang mode for heater and set PWM limit
M143 H1 S280 ; set temperature limit for heater 1 to 280C
@oliof Direct. Phaetus dragon with bondtech cht nozzle and sherpa extruder with ldo motor.
Ok here's what I think now. It must be extruder related somehow. It isn't the Z-axis or it would not change depending on layer height or even object size as it does now.
It is definitly something driven or mechanical since it is way to consistent to be something like material unevenness.
The main indicator is that the pattern size increased by object size or vice versa. The smaller the object, the larger the gaps become. Bigger object, so more material extruded, is lower interval. It almost looks like it is overextruding every X meters of filament.
Ok the plot thickens. I printed a simple square, no infill, just 3 perimeters @ 150mm/s with 0.15mm layer height.
The only difference is the size, 100x100, 200x200 & 400x400.
Here is the result (forget the writings):
I'm lost...
@oliof Good idea but the spool holder is the same as before it had issues.
Also, it is not bearing based but it is also guided all the way so there is no yank, the tension is fairly steady throughout.
@rjenkinsgb As far as i can see they are matching the outside.