@KenW, this printer IS line powered (750W 300 x 300)
I am not entirely sure what actually is happening. Before I turn on the heater, I get a nice steady temperature reading. As soon as the heater goes on, temperature jumps around and, for a few seconds, that's all it does. Then the temperature starts to go up and the temperature reading appears to be generally stable (and increasing).

I just had an interesting thought .... with the heater being line powered and the thermistor being glued to the heater, maybe I am seeing interference. This would be more of a problem when cold as the resistance is higher. I do not use a shielded cable for the thermistor and it runs together with the power lines from the bed right to the electronics compartment. It's not even a twisted line.
Funny thing is that all three of my printers are configured that way and they see to be mostly ok (although I had intermittent problems like this in the past)
Interference would explain a lot though ..... I wonder if it would make sense to stick a substantial capacitor across the sensor input pins on the Duet to absorb quick spikes? Any comments on a bandaid such as that?

I am curious though why a spike would trigger the heater error because the error has to persist for a while before a fault is triggered. I seem to recall that the time for error detection can be extended - I will give this a try first since it's just a line in config.g. I am reluctant to do this because it applies to the entire print job and not just the startup phase.
Now that I am thinking about it, maybe since the heater is hard on during startup it causes more interference than a slowly cycling heater?

@nikscha please file an enhancement request at https://github.com/Duet3D/Duet3Expansion/issues.

@dc42 yes I too believe the segmentation isn't ideal but more of a workaround

@KP0005 in those menu files, which field doesn't update unless you force the page to refresh? I didn't see a field that expanded the time to HH:MM:SS.

I created https://github.com/Duet3D/RepRapFirmware/issues/913.

dc42 created this issue in Duet3D/RepRapFirmware closed 12864 'value' menu items using object model expressions don't update #913

@dc42 said in M106 is executed out of order when printing over USB:

My guess is, when printing over serial, movement commands are queued, but control commands are not. This causes them to be executed ahead of the movement by the size of the movement queue.

Correct. I have corrected the documentation.

Thank you very much for updating documentation. Now it matches the behavior I'm observing exactly.

However this raises a follow up question: is there any workaround besides putting a gcode file on the SD card? The inconsistent queueing is detrimental to printing bridges, which in my experience always require high airflow to avoid sagging. This puts print-by-wire at a significant disadvanage.

My setup is pretty rudimentary. I don't have an LCD, there is only one SD slot which is occupied by an SD card holding RepRap configuration, and the only way to connect to the printer is USB. My only option seems to be using M28 and friends, but 1) I'm yet to make this work due to issues in Octoprint (it fails to recognize the success response from RepRap's M21), and 2) the general consensus is that M28 is inherently very slow anyway.

@nikscha See https://docs.duet3d.com/en/User_manual/Reference/Gcodes#custom-gcodes

Ian

@hpiz both duet3 6HC and duet 3 mini 5+ have a VFD header. 6HC next to the erase header , mini close to the middle of the board.

See the wiring diagrams at https://docs.duet3d.com/en/How_to_guides/Wiring_your_Duet_3

and https://docs.duet3d.com/en/User_manual/Machine_configuration/Configuration_CNC#connecting-a-spindle

for more details.

@ThorAK77 best just use bossa and go directly to 3.4.6 https://docs.duet3d.com/en/User_manual/RepRapFirmware/Updating_firmware#all-other-duet-boards

@JRDM I guess you can use conditionals in the macro or start/stop the second stream from within the first stream. But I haven't tried it.
There is this article Duet3 Wiki that might help you.

@oliof last time I looked, Marlin used fixed width fonts, although that might have changed by now. RRF uses proportionally spaced fonts.

@Herve_Smith I don't have an answer to your problem - not experiencing it myself but here is a hack that might work. Personally, I don't use M codes to wait for heaters for a number of reasons which have no bearing on your problem but instead use this format

while sensors.analog[1].lastReading < someNumber G4 S5

So maybe you could cobble together a hack whereby you set your temperature to be say 5 deg above what you really want, then use that while loop to wait for the actual desired temperature (i,e 5 degrees less tha what you've just asked for) and when it reaches it, set the temperature to your desired temperature and continue. e.g.

M568 P0 R205 S205 while sensors.analog[1].lastReading <200 G4 S5 M568 P0 R200 S200.

Or something along those lines

@OwenD

I have opened a FR on github for this: https://github.com/Duet3D/RepRapFirmware/issues/891

T3P3 created this issue in Duet3D/RepRapFirmware open [FeatureRequest]: Timeout on M291return default value #891

@gloomyandy Maybe I'm wrong? I was under the impression, all Cortex M0+ MCUs are dual core...

I already have this working. It saves babystep value on pause, cancel, print end and loads it at print start.

G32 and G29 resets it to 0.

It's also possible to continously monitor it with daemon.g in case of event of power loss.

@marvineer You don't really need to test for each one, just test for one of them and groupe then creation/setting together...

if !exists(global.global1) global global1 = {1, 2, 3} global global2 = {3, 4, 5} global global3 = "whatever" else set global.global1 = {1, 2, 3} set global.global2 = {3, 4, 5} set global.global3 = "whatever"

Also if these globals are in effect constants (so nothing anywhere else changes the value), then there is no need to set the value if the global(s) already exist.