Best posts made by ÖrjanE

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 Looks good!

Now, back to the other problem; that an error during simulation may cause physical movement. In 3.2.2 I can't cause the "too small radius"-error any more, but looking at the source code, I realized that I can provoke an error by setting identical start end end points for G2 or G3 with an R parameter.

This code:

G28 ; Home all axes
G21 ; set units to millimeters
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion

G1 Z20.000 F7800.000
G1 F1800.000
G1 X115 Y115
G1 F200.000
G3 X115 Y115 R5
M0 ; Stop print

will cause the message "Error: SetPositions called when DDA ring not empty" as well as "Error: G2/G3: radius is too small to reach endpoint" when run in simulation mode. It also causes a physical movement (some 10mm in the negative X direction).

Hope you can replicate this behaviour.

@dc42 Great!
Thanks for your work in maintaining this software.

@dc42 Forget about the "second symptom" (problem during actual print). I have restarted the duet and fail to repeat the problem. It may be that I misinterpreted what happened when I tested this.

Regarding the move when simulating; it makes sense that it is the last move/moves that remain queued when simulation mode is turned off prematurely. The move does not seem to be random, but consistent with the last move that should have been done (in simulation) before the error occurred.

Hi,
I've been experimenting with printing using arcs (G2/G3) and have stumbled upon what seems like two bugs. I'm running RRF3.2 on a Duet2 Maestro with a normal cartesian printer.

First (possible) error occurs when printing an exact semicircle using the G3 Xnnn Ynnn Rnnn format. In the testcode (attached below) it is expected to print a semicircle from X=121.107 to X=113.893 with a radius of 3.607. Note that 113.893+2*3.607=121.107 so this should be fine. However, the firmware complains "Error: G2/G3: bad combination of parameter values". Increasing the radius to 3.608 makes the error disappear, which makes me think it is a problem with floating point precision.

Second worry is that if i run a simulation (!) there is actual, physical, movements happening when the error is detected. This only seems to happen when the axes are homed. The relevant error message in the console is "Error: SetPositions called when DDA ring not empty". Needless to say, physical movements during simulation (even if it is a failed one) is scary.

This is my stripped down test file:

G28 ; Home all axes
G21 ; set units to millimeters
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion

G1 Z20.000 F7800.000
G1 F1800.000
G1 X121.107 Y128.804 E0.15037
G3 X113.893 Y128.804 R3.607 E0.42650
M0 ; Stop print

If relevant, here is my config.g

code_text; Configuration file for Duet Maestro (firmware version 3)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v3.1.1 on Wed Jun 03 2020 11:09:23 GMT+0200 (centraleuropeisk sommartid)

; General preferences
G90                                            ; send absolute coordinates...
M83                                            ; ...but relative extruder moves
M550 P"Anatidae"                               ; set printer name
M918 P1 E-4 F2000000                           ; configure direct-connect display

; Network
M552 P0.0.0.0 S1                               ; enable network and acquire dynamic address via DHCP
M586 P0 S1                                     ; enable HTTP
M586 P1 S1                                     ; enable FTP
M586 P2 S0                                     ; disable Telnet

; Drives
M569 P0 S0                                     ; physical drive 0 goes backwards
M569 P1 S0                                     ; physical drive 1 goes backwards
M569 P2 S1                                     ; physical drive 2 goes forwards
M569 P3 S0                                     ; physical drive 3 goes backwards (BMG Direct Drive)
M584 X0 Y1 Z2:4 E3                             ; set drive mapping
M350 X16 Y16 Z16 E16 I1                        ; configure microstepping with interpolation
M92 X80.00 Y80.00 Z400.00 E415.00              ; set steps per mm
M566 X{8*60} Y{8*60} Z{1*60} E{5*60}           ; set maximum instantaneous speed changes (mm/min)
M203 X{150*60} Y{150*60} Z{5*60} E{100*60}     ; set maximum speeds (mm/min)
M201 X500.00 Y500.00 Z100.00 E5000.00          ; set accelerations (mm/s^2)
M906 X500 Y500 Z500 E400 I30                   ; set motor currents (mA) and motor idle factor in per cent
M84 S30                                        ; Set idle timeout

; Axis Limits
M208 X-8 Y-10 Z0 S1                            ; set axis minima
M208 X235 Y225 Z260 S0                         ; set axis maxima

; Endstops
M574 X1 S1 P"xstop"                            ; configure active-high endstop for low end on X via pin xstop
M574 Y1 S1 P"ystop"                            ; configure active-high endstop for low end on Y via pin ystop
M574 Z1 S1 P"zstop"                            ; configure active-high endstop for low end on Z via pin zstop

; Z-Probe
M558 P9 C"^zprobe.in" H3 F100 T6000            ; enable Z probe
M950 S0 C"zprobe.mod"                          ; connect to mod pin
G31 X-25 Y-1 Z2.0 P500                         ; offset from nozzle
M557 X25:205 Y25:205 S45                       ; define mesh grid

; Bed leveling
M671 X-28:263 Y0:0 F1.5                        ; Position of the lead screws

; Heaters
M308 S0 P"bedtemp" Y"thermistor" T100000 B4092 A"Bed" ; configure sensor 0 as thermistor on pin bedtemp
M950 H0 C"bedheat" T0                          ; create bed heater output on bedheat and map it to sensor 0
M307 H0 B1 S1.00                               ; enable bang-bang mode for the bed heater and set PWM limit
M140 H0                                        ; map heated bed to heater 0
M143 H0 S120                                   ; set temperature limit for heater 0 to 120C
M308 S1 P"e0temp" Y"thermistor" T100000 B4725 C7.06e-8 A"Nozzle" ; configure sensor 1 as thermistor on pin e0temp
M950 H1 C"e0heat" T1                           ; create nozzle heater output on e0heat and map it to sensor 1
M307 H1 B0 S1.00                               ; disable bang-bang mode for heater  and set PWM limit
M143 H1 S285                                   ; Max nozzle temperature 285C

; Fans
M950 F0 C"fan2" Q500                           ; create fan 0 on pin fan2 and set its frequency
M106 P0 S0 H-1                                 ; set fan 0 value. Thermostatic control is turned off
M950 F1 C"fan1" Q500                           ; create fan 1 on pin fan1 and set its frequency
M106 P1 S1 H1 T45                              ; set fan 1 value. Thermostatic control is turned on

; Tools
M563 P0 D0 H1 F0                               ; define tool 0
G10 P0 X0 Y0 Z0                                ; set tool 0 axis offsets
G10 P0 R0 S0                                   ; set tool 0 active and standby temperatures to 0C

; Custom settings

; Set pressure advance
M572 D0 S0.1

; Set firmware retraction parameters
M207 S1 F1500 Z0   ; 1mm 25mm/s, no lift

; Load the overrides file
M501