Posts made by ÖrjanE

@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.

@dc42 Thanks for the info.

Please note that there are a few edits to the dozuki-pages that have not made it into docs. I have made one correction to the page about pressure advance, but there are other pending edits.

Since the old site was a wiki, it was easy for anyone to fix (or introduce) errors. Is there a plan for how to report errors and/or suggest improvements for the new site?

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.

/Ö

Hi,
I'm running RRF 3.4rc1 on a Duet 2 Maestro and am considering connecting a DHT22 sensor for monitoring the enclosure environment. The documentation does not explicitly mention the Maestro board, only "Duet 2".

• Is the Maestro capable of handling the DHT22?

• If yes, which connectors can be used? E0, E1, X, Y, Z-stop? Only the temp daughterboard connector (CS1/CS2)?

/Ö

@dc42 Perfect. Thanks!

Background: I'm using a Duet 2 Maestro for a normal cartesian printer and just switched to firmware 3.4rc1 where the drivers are now by default starting in SpreadCycle mode. This prompted me to configure the system to perform the necessary tuning sequences for StealthChop2, primarily to make the machine quiet. When doing this, I realized that there are several things that are unclear to me.

Q1: Is it necessary to repeat the tuning sequence when the motors have been idle? My testing seems to indicate that it is sufficient to do the tuning only after the whole system has been powered down. Is that correct?

Q2: The examples I've seen suggest doing the tuning in connection with homing, but this may not work for the extruder motor. It there any reason for not using StealthChop2 for the extruder?

Q3: The tuning sequence seems to be that one should energize the motor (M17), then wait at least 130ms before doing a "normal" move. Is there an upper limit for how long to wait? Specifically, is is possible/advisable to wait until the normal printing starts, possibly several minutes later?

Q4: There does not seem to be any information in the Object Model about the driver mode. It this planned/possible/irrelevant?

My idea is to use conditional g-code to do the tuning sequence only when needed; in the homeall.g for X, Y, and Z, and in the start sequence for E (after the nozzle has been heated). I guess global variables can be used to remember if the tuning has already been done since power-up/reset.

@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.

@phaedrux Thanks. Perhaps we can hope that this feature will eventually come in the majority of slicers.

I noted that this had also been proposed for Klipper, but never implemented.

@phaedrux said in Fan advance:

Cura does for sure. Though it's likely hidden by default.

I rarely use Cura, so it may simply be my inability to navigate the interface, but I do not find this option. Do you know what it is called?

@mintytrebor Yes, asking the slicer to insert the fan speed command earlier in the gcode stream is an alternative. I do not think PrusaSlicer or Cura have this option (yet). Nice to see that SuperSlicer has implemented this.

When the part cooling fan speed is changed during a print, it can take several seconds until the actual RPM is reached since the fan itself has to accelerate/decelerate. When printing a perimeter bridge, for example, this often means that the extra cooling aimed for the bridge actually arrives when the nozzle has long passed the bridge area.

Would it be possible to change the PWM-signal ahead of time, somehow bypassing the movement queue? Ideally, there would be a settable advance time.

A more "scientific" approach might be to have some sort of PID-model for the fan+air plant, but this is probably overkill. Nevertheless, it would still require the M106 gcodes to be processed ahead of the regular movement queue.