Hi,
[Running firmware 3.1.1 on a Duet 2 Maestro.]

I have recently discovered simulation mode (M37) to be a very nice way of getting an accurate printing time estimate. When testing this, I have come across what seems like small mismatches between what the documentation says, what the web interface displays, and what actually happens:

The documentation of gcode M37 says that "M37 S0" should end simulation mode and print the time estimate, but it seems like nothing is printed. I can use M37 with no parameters to get the time estimate (in seconds).

When running a print job from the web interface while in simulation mode, the web interface correctly says that it is running a simulation. At the end of the job, however, it states that the time used was 0 (zero). My guess is that the intension was to show the estimated print time.

From what I have understood, the tricky thing to get right when extruding along Bézier curves is the filament extrusion rate. The G5-command, as it is defined in Marlin, gets the total amount of extrusion for the curve, but to calculate the extrusion rate you also need the length of the curve. The problem is that there, apparently, exists no closed formula for the curve length. The length can be estimated numerically by simulating the move, but this is hard to realize in real time; you can not start the move without knowing the entire curve length.

I have not looked into the Marlin source code recently, so I do not know how they solve this.

Answering my own questions after some experimenting. The Maestro handles the DHT22 fine when connected to the CS1 or CS2 pin (as documented for Duet 2).

For the record: the AM2320 Temp/Humid sensor (not AM2302) also works fine, when connected using its "single bus communication" mode, which seems to be backwards compatible with DHT22/AM2302.

/Ö

@dougal1957 Sure, using a low standby temperature as a substitute for turning the heater off will do the trick in most situations. However, I can think of a few corner cases where going to the actual off-state may be preferred:

• If I do not want to overwrite the standby-temp, for example to make it easy to manually switch it on again
• To make it clear in the web interface that the heater is off
• To ensure that the heater does not start even if the temp-sensor says it is below zero.

Note that it is already possible to turn the heater off with "M140 S-274". My suggestion is simply to move this functionality to M144 where it (in my opinion) belongs, since M144 is all about switching the bed heater state.

/Ö

@dc42 Will the firmware generate an error message in these situations, or silently continue? If the latter; would it be possible to add such sanity checks?

@bot I looked briefly into the Marlin source code for G5 and, as expected, they do not solve the problem with extrusion rate. They seem to use the t-parameter (that runs from zero to one along a Bézier curve) to linearly control extrusion. That code is actually marked with a "FIXME" comment. For simple arc-like curves, this may be good enough, but for wilder Bézier curves the extrusion rate will vary considerably along the curve.

Since the slicer does not have to work in real time, and, as you say, often already has the curve represented as line segments, it would be good if the slicer had some way of telling the firmware what the curve length is. One obvious solution would be to have the curve length as an extra parameter to G5.

The documentation for GCode M140 states that the bed heater can be switched off by passing an S-value of "-273 or lower", and even gives an example "M140 S-273". However, this does not work. The source code (src/GCodes/GCodes2.cpp:1731) actually checks if the S-value given is strictly less than -273.0. Therefore, "M140 S-273" will not switch off the bed heater, but e.g. "M140 S-274" will.

In addition, the term "the absolute negative temperature" used in the documentation of M140 is strange. I guess it refers to the absolute zero temperature.

Cheers,
Örjan

@chrishamm Please also note this related wish: https://forum.duet3d.com/topic/26563/allow-m144-to-turn-off-the-bed-heater. Decoupling temperature setting from active-standby-off state changes could make the handling of bed and tool heater states less inconsistent.

Also, using zero to signify "no heat" is perhaps not the best. What would happen to someone building a machine for ice cream extrusion...?

You might use, e.g., -273.15 to signify "no temp set" in the object model, and display it as "None" in DWC, thus avoiding zero as a magic number.

@jay_s_uk Indeed; updating from 3.2 to 3.2.2 fixed the problem. Even when using a clearly too small radius value, the firmware does not throw an error.

Since I can no longer provoke the error in 3.2.2, I do not know if the second problem (movement when an error is triggered during simulation) is also fixed, or simply harder to encounter.

Thanks for the help.

@bot Many of the problems seem to come from how the interface between the slicer and the firmware is defined. The extrusion rate is known by the slicer but it is forced to communicate it to the firmware via the E-parameter which is the total extruded amount instead of the rate. When I think about it, this also applies to G1,2,3 moves; the slicer internally translates rate to amount and the firmware translates back to rate. I guess that for most prints, the extrusion rate stays constant over many (hundreds of) G1 moves, so there would be a potential for saving gcode file size here by only sending the rate number when it changes. Well, changing G1 would probably be too disruptive to be realistic.

To somewhat bring this back to the original topic of this thread, perhaps we should also consider Bézier curves in 3D, not only planar ones. The question about offset then becomes a bit more complicated, but not unsolvable (cross products come to mind).

As you point out, self intersections may occur if offsets are used in tight bends, but I would consider that to be the slicers responsibility to detect (when it matters). We should also note that movement along an offset curve will affect the speed and hence (again) the extrusion. Those things (acceleration, jerk, PA, input shaping) are all under the control of the firmware, so this would hopefully be handled by the existing machinery.

@dc42 Perfect!

Will that also include formatting of time-values as hh:mm:ss?

/Ö

@tecno The sensor itself is working fine. I am actually using the AM2320 which is backwards compatible with the DHT, and I get the correct temperature in the web interface and in the object model. My problem is that I can't get this value to show up on the 12864-display.

@tecno Thanks Bengt.
I added the line

M950 H2 T2

to create a "fake" chamber heater. However, I still only get a zero value displayed on the 12864-display; both with codes N90 and N92 for addressing the chamber "heater".

/Ö

Hi.
I'm trying to configure my 12864-display to show the current chamber temperature, but can't find an N-parameter for the menu system that works. I have tried N90, but this seems to only work for an actively heated chamber, and only displays a zero value.

My chamber temperature sensor is defined like this:

M308 S2 P"0.spi.cs2" Y"dht22" A"Chamber Temp"  ; Chamber temp sensor

(this is a Duet2 Maestro board running RRF 3.4.1)
Do I need to define a (fake) chamber heater to make the N90-code work? Is this even possible?

/Ö

@mikeabuilder Thanks!

I was expecting to find the currently loaded filament in the object model, but fail to find it (perhaps I'm just blind).
If it actually is not present in the object model, then this is a wish for future versions.

Background:
I'm running RRF 3.4 and would like to access the currently loaded filament in order to have a startup script which checks that the filament set in the slicer matches the filament loaded in the machine. I realize that this could be achieved by setting some "magical" global variable in each of the filament config.g-files, but this solution feels unnecessarily fragile.

/Ö

@droftarts Ping!

This error in the documentation of Pressure Advance is still there.

/Ö

@örjane said in Pressure advance example wrong:

@t3p3tony The second example in the page about Pressure Advance (https://docs.duet3d.com/en/User_manual/Tuning/Pressure_advance) is wrong. It is not possible to have more than one S-value in a single M572-command.

My suggested replacement for this section is:

M572 D0 S0.1

The D parameter is the extruder drive number, and the S parameter is the amount of pressure advance you want for that extruder drive. If you have multiple extruders that should all have the same S value, you can specify them by listing their D values, separated by colons:

 M572 D0:1 S0.1

To assign different values to different extruders, you need to use separate M572 commands.

@trobison Setting the temperature to zero is not the same as turning the heater off. You can use the A-parameter of M568 to change the heater state to off:
M568 P0 A0
To turn off the bed, you need: "M140 H0 S-274".

Normally, all these commands should be in stop.g while the End-gcode in the slicer should only contain a single M0.

@dc42 I just tested 3.4rc2+2 and can confirm that, at least for me, it behaves much better controlling the hotend temperature.

I have a regular E3Dv6 hotend and a Maestro card. With 3.4rc2 it did overcompensate substantially for the fan and did not return to the target temperature after a fan burst. It often remained over 4 degrees above target.

With 3.4rc2+2 it seems to compensate perfectly for varying fan speeds. I had a slight overshoot (ca 1.5 degrees) at initial heatup, and a slight undershoot (ca 1.5 degrees) when the fan first started. For the rest of the print, it stayed within +-0.2 degrees of target. I have not yet done a new PID tuning with the new firmware,

/Ö

@t3p3tony The second example in the page about Pressure Advance (https://docs.duet3d.com/en/User_manual/Tuning/Pressure_advance) is wrong. It is not possible to have more than one S-value in a single M572-command.

My suggested replacement for this section is:

M572 D0 S0.1

The D parameter is the extruder drive number, and the S parameter is the amount of pressure advance you want for that extruder drive. If you have multiple extruders that should all have the same S value, you can specify them by listing their D values, separated by colons:

 M572 D0:1 S0.1

To assign different values to different extruders, you need to use separate M572 commands.