Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released

Veti

the configurator needs to be updates with a choice for this firmware because of the M669.

dc42

@veti said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

the configurator needs to be updates with a choice for this firmware because of the M669.

Not necessary, because the M669 K codes that RRF 2.02 supports are also supported in RRF 2.03 and they set the appropriate default matrix.

SupraGuy

Thanks! Time to update my boards!

I'm not sure what qualifies as "high levels" for pressure advance, but most likely I'm going to leave the jerk settings to default anyway, so it probably won't matter.

DocTrucker

Thanks for the continuing updates to the 1.x firmware. Will update later this evening.

Phaedrux

Tested it out last night on a 6 hour print. I even tried the Jerk policy of 1 to see if I could tell the difference. I wasn't sure what to look out for, but the print completed successfully at any rate. XY jerk of 700, PA of 0.045.

Alpenprinter

Since updating to 2.03, I think, that there is a new issue.

Within long prints, the display and the web interface twice got unresponsive about in the middle of a print (after around 5h).
But the print was finished correctly. After finishing, the duet display (7´) and the web interface still show the bed and hotend temperature that where used during the print.

The "STOP" button on the display reacts, but failed to connect to the duet board again.

Power on/off fixes the problem.

In the 2.03 RC the fault did not appear.

zerspaner_gerd

@alpenprinter said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

Within long prints, the display and the web interface twice got unresponsive about in the middle of a print (after around 5h).
But the print was finished correctly. After finishing, the duet display (7´) and the web interface still show the bed and hotend temperature that where used during the print.

I also observed that!
At first I thought only of wireless problems but also the PanelDue did not react anymore.
I also had this in 2.03 RC, Final 2.03 I have just installed today.

Alpenprinter

What's the latest firmware version known to run stable?

@zerspaner_gerd said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

@alpenprinter said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

Within long prints, the display and the web interface twice got unresponsive about in the middle of a print (after around 5h).
But the print was finished correctly. After finishing, the duet display (7´) and the web interface still show the bed and hotend temperature that where used during the print.

I also observed that!
At first I thought only of wireless problems but also the PanelDue did not react anymore.
I also had this in 2.03 RC, Final 2.03 I have just installed today.

Phaedrux

@alpenprinter said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

What's the latest firmware version known to run stable?

2.02 was the last stable release.

What version of DWC and PanelDue firmware are you running?

Alpenprinter

@phaedrux said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

@alpenprinter said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

What's the latest firmware version known to run stable?

2.02 was the last stable release.

What version of DWC and PanelDue firmware are you running?

Panel Due 1.20
DWC 2.0.0

Alpenprinter

@phaedrux said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

@alpenprinter said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

What's the latest firmware version known to run stable?

2.02 was the last stable release.

What version of DWC and PanelDue firmware are you running?

I downgraded to 2.02 and all is running fine again. I kept DWC 2.0.0, no problem with this.

Not sure if this is a bug or a feature/limitation, but if using M918 P1 E4 to enable a 12864 display the PanelDue serial port does not get the {"beep_freq":7000,"beep_length":2000} message even if the serial port is set up with M575 P1 B57600 S0. Which seems odd as {"message":"HELLO WORLD"} from M117 Hello World is sent to the PanelDue port even with the 12864 display enabled, removing the 12864 from the config results in the beep messages being sent to the PanelDue port without any other changes made.

(Also M918 P0 is rejected as unkown display, so only way is to reboot. Same behavior in v3 in both cases)

dc42

@bearer said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

Not sure if this is a bug or a feature/limitation, but if using M918 P1 E4 to enable a 12864 display the PanelDue serial port does not get the {"beep_freq":7000,"beep_length":2000} message even if the serial port is set up with M575 P1 B57600 S0. Which seems odd as {"message":"HELLO WORLD"} from M117 Hello World is sent to the PanelDue port even with the 12864 display enabled, removing the 12864 from the config results in the beep messages being sent to the PanelDue port without any other changes made.

That's the way it is written. But I can make both the 12864 and PanelDue bleep in the next build.

(Also M918 P0 is rejected as unkown display, so only way is to reboot. Same behavior in v3 in both cases)

I didn't anticipate any requirement to disable the 12864 display once it has been enabled.

@dc42 said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

I didn't anticipate any requirement to disable the 12864 display once it has been enabled.

I just tried as the g-code wiki listed Pn Directly-connected display type: P0 = none (default) which the firmware rejected, I don't see the need to un-configure it, but maybe the wiki was a bit unclear in that respect.

As for the beep with and without 12864, I'm okay either way, was just surprised that there was a difference between M117 and M300 without any indication of it being by design or not. If supporting efforts like https://forum.duet3d.com/topic/10720/duet3d-monitor-adding-a-big-status-light-to-your-printer is a priority I can see having the protocol as complete as possible even if not used with a PanelDue would be beneficial.

dc42

@bearer said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

I just tried as the g-code wiki listed Pn Directly-connected display type: P0 = none (default) which the firmware rejected, I don't see the need to un-configure it, but maybe the wiki was a bit unclear in that respect.

I have removed the P0 option from the description in the GCode wiki.

As for the beep with and without 12864, I'm okay either way, was just surprised that there was a difference between M117 and M300 without any indication of it being by design or not. If supporting efforts like https://forum.duet3d.com/topic/10720/duet3d-monitor-adding-a-big-status-light-to-your-printer is a priority I can see having the protocol as complete as possible even if not used with a PanelDue would be beneficial.

That's why I changed the code yesterday to send the beep to both displays. This change is already in the RRF3 beta build and it will also be in RRF 2.03.1 when I release that.

Awesome!

Yakandu

Another "maybe" bug.
I have duet 3d wifi on a delta printer, with the new function "M665 L260.0:260.0:260.0" to give the firmware the diagonal rod offsets, if I leave them the same as in the example everything works fine, now, if I change the values after calibrating with the hexagon I get (and thats what I got when I was running Marlin) L267.3:267.1:266.9, a 0.2mm difference between the rod pairs, my printer misses steps while homing (the second bump, but not in the first one) and misses steps while calibrating and printing.
I, then, proceed to experiment, the greater the difference, the more steps it misses.
So I'm now back to the L267.1 (the mean of the tree pairs) until this is fixed, it happens too to others in my printing community.

Here I provide you my homedelta, config override and config in case you want to check them out.

2_1561532460509_homedelta.g 1_1561532460509_config-override.g 0_1561532460509_config.g

dc42

Thanks for your report - I've added it to my list to investigate.

The recommended way to handle scaling errors is not to adjust the rod lengths but to use M579.

kraegar

Two things I've seen so far.

M280 to turn a servo in a macro sometimes doesn't run until the end of the macro, after any other moves etc. Putting M400's before/after fixes it. (It's not every macro that's affected, some run as expected, others don't turn the servo until the end, no rhyme or reason I can spot)

M116 behavior changed slightly, still looking at this. Probably only affects testing, but I'm not sure. Previously if no temp was set I could switch through tools and the M116 did nothing. Now it stalls and waits on something. I tried setting the temp to 30c on each tool. It does bring the temp up to 30c but never proceeds. I may need to set a standby temp for each tool and retest, still looking into it. Commenting out the M116 lets the swaps proceed as normal.

One other thing that may be as intended, but surprised me. I thought having a minima for Z set to -0.1 wouldn't affect anything other than letting me move down "into the bed" past Z=0. I homed X/Y/Z, then did a mesh probe and the mesh showed entirely "under the bed". Changing the minima to Z0 resolved that. It's likely I just misunderstood this functionality, but figured I'd note it. (the documentation seems to indicate this is expected behavior)

dc42

@kraegar said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

M280 to turn a servo in a macro sometimes doesn't run until the end of the macro, after any other moves etc. Putting M400's before/after fixes it. (It's not every macro that's affected, some run as expected, others don't turn the servo until the end, no rhyme or reason I can spot)

Can you construct a macro that reproduces this reliably?

M116 behavior changed slightly, still looking at this. Probably only affects testing, but I'm not sure. Previously if no temp was set I could switch through tools and the M116 did nothing. Now it stalls and waits on something.

There has been no intentional change to M116. Can you reproduce it, preferably in a standalone macro?

One other thing that may be as intended, but surprised me. I thought having a minima for Z set to -0.1 wouldn't affect anything other than letting me move down "into the bed" past Z=0. I homed X/Y/Z, then did a mesh probe and the mesh showed entirely "under the bed". Changing the minima to Z0 resolved that. It's likely I just misunderstood this functionality, but figured I'd note it. (the documentation seems to indicate this is expected behavior)

No, it's not intentional behaviour. The only way that the M208 Zmin setting should affect the Z=0 position is if you use a Zmin homing switch, and after the G1 H1 Z-nnn move in homez.g you don't have a G92 Z command to set the actual Z position.