I have chamber heaters that can go up to 500c. I have them mapped as chamber heaters using the M141 command. According to the documentation, M141 must come before M143 (which is used to set the max temperature for a heater). However the default max temperature for a chamber heater is something significantly less than 500c. I assume it's 125c, same as for bed heaters.

In any case, when my heaters are above that default (either because they're still cooling down from a print or the print is paused) and I restart the board, I get an instant heater fault on reboot because M141 sets the heater as a chamber heater before M143 sets its max temperature in config.g. This is becoming very frustrating.

Has this order dependency been eliminated in a forthcoming version of RRF?

@whosrdaddy The chamber doesn't get to 500c, just the heaters do. They're ceramic IR emitters with built in thermocouples. They heat whatever they're pointed at without doing much to heat the ambient air. Plus the enclosure is enormous and has a filter that recirculates the air from top to bottom, so things don't get THAT toasty in there. Basically, as long as the emitters are on and hot enough, then the object being printed can't dissipate its heat through the air, it can only do so through the build surface. So its internal temperature tends to stay the same as the bed's temperature. Meanwhile the electronics inside the enclosure aren't getting fried. It's been working great for nylon, ABS, PETG, etc with zero warpage, even with very large prints (the bed is 24" diameter).

@whosrdaddy No, no air blown directly over the print area. The air from the BOFA filter gets blown in through a 90 degree elbow so it gets circulated around the periphery of the enclosure below the heated bed, starting directly under one of the IR emitters.

And no cold air to the heatsink. Ambient air temp rarely gets much higher than about 70c anyways when printing ABS, typically it's more like 40c. This is plenty adequate for cooling the heatsink of the Mosquito Magnum using the stock 25mm fan. I've considered switching to a water cooled Mosquito, but haven't seen a need to yet.

I do however have an external air pump for part cooling, for when I need to do bridging and such. It blows through a tube into a Berd air ring

.

When I have an M80 command in config.g, I get this handy "ATX" toggle on the DWC dashboard for turning the power supply on and off. It's a nice feature.

Is it possible to add other toggles? Perhaps something that turns a GPIO pin on and off? Like for example the "out9" fan pin that I use to control an external 110v outlet mounted on my printer? That would be really handy, too.

Right now it's a "fan" with a minimum speed of 255 so that I get a slider in DWC that turns the outlet on when it's set to anything but 0. This works, but it seems kludgy and I'd really like to have a neat toggle.

It's also super comforting to know that I'M NOT DOING ANYTHING WRONG and there's nothing wrong with my setup that'll bite me later. That was my main concern.

@oliof Yes. If you're feeding 5v to the board from an external source (either from a Pi or through the ext_5v pin), then you no longer need to use the onboard 5v converter. Removing that jumper disables the onboard converter

@cdthomas9 I was able to purchase the components, including the hobs, without the housing. That's still available from a few sellers, though you have to ask them directly about it because they don't list it that way. I bought mine from right here, was sent an invoice from Duet3D that I paid with PayPal, and I had the package within a week or so.

@alankilian Yeah thanks for that 😂 I ended up having to order a parts kit from the UK because Filastruder had JUST run out

@wilriker I don't think -execAsync is implemented in the 5.1 release. I just downloaded the source code for that release and there's no mention of execAsync anywhere. It's only implemented in the current (uncompiled) source code in the repository. Any chance you could push out a more recent release with the current code? It's the last bit I need to get my setup working.

Hah! Too late, I'm already neck-deep in implementing it

@wilriker How do I make it execute the command and exit right away and return success without having to wait for the command to complete? I tried sending my command to background with & but that doesn't appear to work. I'm trying to get it to run a process which continues through the duration of the print, but executing the M code just causes it to hang until the process is complete. I thought it would be execAsync, but that gives me an error on the command line saying that's not a supported flag

Is this still the easiest way to issue commands on the pi in SBC mode? Or has a native way been implemented in RRF in recent releases? Just wanted to check before investing time and effort in something that's obsolete

Incidentally, the fact that it completed auto-calibration but then skipped bed mesh probing seems to imply that it's just skipping gcodes or somehow executing them out of order. It doesn't appear to be specifically an auto-probing issue, that's just where I'm getting hit with most of the symptoms.

@chrishamm Yeah, I totally forgot that I need to flash the firmware file on the board before I downgrade the packages. I did that last time, but downgrading isn't something I do often so I forget obvious steps sometimes.

I re-installed the 3.2 packages and can communicate with the board again. I tried to record a failed auto-calibration, but it completed successfully this time 🤣 Although it DID inexplicably skip the bed mesh probing. Since it successfully started the print (which I've been trying to get going for hours), I decided to let it complete it. Once it's done, I'll do further testing (trying standalone mode, etc).

Here's the bed.g file I've been using for the last few months:

M561 ; clear any bed transform
G28  ; home all towers
; Probe the bed at 6 peripheral and 3 halfway points, and perform 6-factor auto compensation
; Before running this, you should have set up your Z-probe trigger height to suit your build, in the G31 command in config.g.
G30 P0 X0 Y249.9 H0 Z-99999
G30 P1 X216.42 Y124.95 H0 Z-99999
G30 P2 X216.42 Y-124.95 H0 Z-99999
G30 P3 X0 Y-249.9 H0 Z-99999
G30 P4 X-216.42 Y-124.95 H0 Z-99999
G30 P5 X-216.42 Y124.95 H0 Z-99999
G30 P6 X0 Y124.9 H0 Z-99999
G30 P7 X108.17 Y-62.45 H0 Z-99999
G30 P8 X-108.17 Y-62.45 H0 Z-99999
G30 P9 X0 Y0 H0 Z-99999 S6

;G29 S1   ; load current bed mesh compensation map

@jay_s_uk That doesn't appear to have flashed the firmware to the board. All the packages were successfully downgraded, but now the SBC can't communicate with the board anymore, I assume because the SPI protocol is different and the board firmware is still at 3.2. This is kinda what I was worried would happen. How do I downgrade the firmware on the board if I can't communicate with it anymore? Do I need to connect to it directly via USB?

A few months ago, I tried RRF 3.2 beta 2 for testing. I found that it completely broke auto-calibration on my Delta printer. The auto-calibration would routinely skip probe points and fail for no apparent reason. I reported the issue here and was told that it would be fixed in a bug fix update before release. I switched back to RRF 3.1.1 and everything worked as expected.

Fast forward to today, RRF 3.2 is officially released and I started running it. Lo and behold, the issue persists, though to a lesser extent. The auto-calibration routine will still occasionally skip random probing points, except now it always completes the routine, albeit with a ridiculous result at the end due to the missing point(s). When this happens, the printer will also entirely skip mesh bed probing (G29) and go straight to printing. Once in a while, the auto-calibration succeeds, and on those rare instances, the printer performs the mesh bed probing as instructed. When this happens, my prints proceed and complete properly, but it's very rare.

Both G32 and G29 are in my slicer-generated gcode files, so I have no clue why the printer would skip the G29 when G32 skips probing points, since it seems to report that it completed successfully.

In any case, with the release of RRF 3.2, my printer is now practically useless. This is infuriating. And reverting back to 3.1.1 seems non-trivial since the stable repo now contains RRF 3.2 as the most recent version.

I'm running a Duet 3 6HC in SBC mode with a Pi 4 running the latest version of all packages (apt update && apt upgrade). Here's the result of M122:

=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.2 running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956L2-G43S8-6J9D2-3SJ6P-1A0LG
Used output buffers: 1 of 40 (11 max)
=== RTOS ===
Static ram: 149788
Dynamic ram: 63408 of which 64 recycled
Never used RAM 145572, free system stack 128 words
Tasks: Linux(ready,111) HEAT(blocked,296) CanReceiv(blocked,927) CanSender(blocked,350) CanClock(blocked,352) TMC(blocked,19) MAIN(running,265) IDLE(ready,19)
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:53:28 ago, cause: software
Last software reset at 2021-01-05 14:18, reason: User, FilamentSensors spinning, available RAM 145572, slot 0
Software reset code 0x000d HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task Linu Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Aux1 errors 0,0,0
MCU temperature: min 43.2, current 44.3, max 45.5
Supply voltage: min 24.0, current 24.3, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 11.9, current 12.0, max 12.0, under voltage events: 0
Driver 0: position 173106, standstill, reads 47906, writes 24 timeouts 0, SG min/max 0/89
Driver 1: position 173130, standstill, reads 47908, writes 23 timeouts 0, SG min/max 0/391
Driver 2: position 173168, standstill, reads 47908, writes 23 timeouts 0, SG min/max 0/397
Driver 3: position 0, standstill, reads 47908, writes 23 timeouts 0, SG min/max 0/415
Driver 4: position 0, standstill, reads 47920, writes 11 timeouts 0, SG min/max 0/0
Driver 5: position 0, standstill, reads 47920, writes 11 timeouts 0, SG min/max 0/0
Date/time: 2021-01-05 15:12:22
Slowest loop: 195.85ms; fastest: 0.04ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, maxWait 2532605ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 43, completed moves 43, 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 = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = 2 -1 -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.6
Heater 2 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" 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.
=== Filament sensors ===
Extruder 0: pos 218.32, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
=== CAN ===
Messages queued 12831, send timeouts 28872, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 48
=== SBC interface ===
State: 4, failed transfers: 0
Last transfer: 1ms ago
RX/TX seq numbers: 48867/48867
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x2c8a8
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.2.0
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 35.68
Maximum length of RX/TX data transfers: 2756/1364

@whosrdaddy No, no air blown directly over the print area. The air from the BOFA filter gets blown in through a 90 degree elbow so it gets circulated around the periphery of the enclosure below the heated bed, starting directly under one of the IR emitters.

And no cold air to the heatsink. Ambient air temp rarely gets much higher than about 70c anyways when printing ABS, typically it's more like 40c. This is plenty adequate for cooling the heatsink of the Mosquito Magnum using the stock 25mm fan. I've considered switching to a water cooled Mosquito, but haven't seen a need to yet.

I do however have an external air pump for part cooling, for when I need to do bridging and such. It blows through a tube into a Berd air ring

.

@whosrdaddy The chamber doesn't get to 500c, just the heaters do. They're ceramic IR emitters with built in thermocouples. They heat whatever they're pointed at without doing much to heat the ambient air. Plus the enclosure is enormous and has a filter that recirculates the air from top to bottom, so things don't get THAT toasty in there. Basically, as long as the emitters are on and hot enough, then the object being printed can't dissipate its heat through the air, it can only do so through the build surface. So its internal temperature tends to stay the same as the bed's temperature. Meanwhile the electronics inside the enclosure aren't getting fried. It's been working great for nylon, ABS, PETG, etc with zero warpage, even with very large prints (the bed is 24" diameter).

I have chamber heaters that can go up to 500c. I have them mapped as chamber heaters using the M141 command. According to the documentation, M141 must come before M143 (which is used to set the max temperature for a heater). However the default max temperature for a chamber heater is something significantly less than 500c. I assume it's 125c, same as for bed heaters.

In any case, when my heaters are above that default (either because they're still cooling down from a print or the print is paused) and I restart the board, I get an instant heater fault on reboot because M141 sets the heater as a chamber heater before M143 sets its max temperature in config.g. This is becoming very frustrating.

Has this order dependency been eliminated in a forthcoming version of RRF?