Bed preheat (M190) doesn't send updates via USB serial

I have a Duet 0.6 running 1.17e firmware.

I'm finding that if I send an M190 command through the USB serial interface, I don't get temperature updates back until the bed has heated. I get updates during an M104 to heat the nozzle, but nothing for the bed.

This is causing issues for me with Octoprint because it times out and thinks the interface is dead while the bed heats. (Plus I'd kinda like to know if my bed is heating or not.)

Is there a setting somewhere that I can configure to change this?

Is there a particular reason why you're using octoprint? The reason I ask is that the Duet Web Server works very well, and ALWAYS talks nicely to the Duet board (I also have a Duet 0.6).

Apart from that - I have found that sometimes when I send a command over USB I don't get any data back until the previous command has finished.

I agree that the Duet Web Server is nice.

However I have a number of reasons that I'm using Octoprint, including the ability to generate a timelapse video of my prints (useful in case of failure) and previewing the toolpath of the G-code.

But this is a consistent and reproducible issue for me that isn't present with other boards, running other firmwares. It would be nice if it would continue to send periodic temperature updates while the bed is heating.

Unfortunately there is AFAIK no defined specification of what format of message Octoprint expects, or what any other firmwares send. Other hosts apart from Octoprint manage without those messages, although some need a configuration option to be set.

Edited 1 time(s). Last edit at 02/15/2017 04:11PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I don't think this is an Octoprint thing.

I think this is a matter of the standard response to an M105 temperature request ceasing when the M190 command has been sent.
I think it would be a problem in Repetier Host or Pronterface too, if that's where I was using this. I just happen to be using Octoprint.

In the attached picture, you can see a periodic M105 "what's your temperature" request, and the Duet responds fine, because it isn't heating up.


The problem occurs when I've started pre-heating my bed, which incidentally is the time when I MOST would like to watch the progression.

The Duet flat out stops responding until the bed temp is within a reasonable range (i.e. 88 degrees or so if I'm heating to 90). And this can take a long time, depending on the power of the bed heater.

M109 is an instruction to stop processing further requests from the same channel until the nozzle is up to temperature. So the host can't continue to send M105 commands. If a host wants to set temperature and then use M105 commands to monitor it, it uses M104 not M109.

I am aware that some firmwares send status updates periodically while M109 is being executed, but this is not documented. If someone provides a clear specification of what is expected at [reprap.org], I'll implement it.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thanks for being willing. I'll see if I can find anything, since M190 seems to be how Slic3r generates a bed preheat.

For what it's worth, here's how Repetier firmware responds to an M190 request:


It continues updating temperature info while the bed heats.

-----------------------------------------------------------------------
Edit: Upon further reflection, I don't believe it is responding to an M105. If I manually send an M105 request while heating, it doesn't change the rate that Repetier is sending temperature data.
I think it just sends that on a periodic basis regardless.

Once it has heated, Octoprint goes back to sending M105 requests and Repetier responds to them.

Edited 1 time(s). Last edit at 02/16/2017 11:20AM by maso.

Thanks. Any idea what all the figures mean? The /0 and /50 look like they could be target temperatures, but I've no idea what the stuff following the @ signs means.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Here's my interpretation, following the last line on that screengrab:

(note: This printer has 2 extruders, bed, and cooling fan. Nozzle 2 was cooling from having been heated)

T:49.24 /0 B:27.44 /50 B@:255 @:0 T0:20.61 /0 @0:0 T1:49.24 /0 @1:0

T - temperature of active nozzle (in this case nozzle 2)
49.24 degrees / set to 0 degrees (off)

B - temperature of bed
27.44 degress / set to 50 degrees

B@:255 - full power to the heater (warming up)

@:0 - maybe the fan power setting?

T0 - temperature of nozzle number 1
20.61 degrees / set to 0 degrees (off)

@0:0 - nozzle 1 getting no power

T1 - temperature of nozzle number 2
49.24 degrees / set to 0 degrees (off)

@1:0 - nozzle 2 getting no power

@dc42 has included the M190 temperature feedback in firmware 1.18 beta 1.

Thanks again!


SOLVED.

Edited 1 time(s). Last edit at 02/22/2017 06:07PM by maso.