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.

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

kraegar

The method for my testing is simply a macro that loops through tool changes, "Test Tools Pickup".

So it loops through each tool in order. I'm not going to cover them all, but here's the summary so far:

The first issue hit is with M280 in tfree0.g (tpost0.g completes with no issue with either M116 or M280, weirdly). If I wrap M400's around the M280, tfree0.g completes fine.
The next issue happens during tpost1.g where it stalls out on the M116 line. I tried setting all of the active & standby temps to 30c before testing, and it still hangs on the M116 on tool 1.

The macros in question are here (quickly cleaned up for readability):
https://www.dropbox.com/sh/oo610lsff1g3n85/AAA6O112JlaB--WkmdfMJla8a?dl=0

Here are screenshots of the difference between M208 Z-0.2 vs. M208 Z0 for Zmin. No other changes. Steps to reproduce:
Home X/Y, Home Z using a microswitch on the X carriage. Run G29.

Z-0.1:
https://i.imgur.com/R7qS1ro.png

Z0:
https://i.imgur.com/eWa53j6.png

kraegar

This post is deleted!

kraegar

Another one. Not sure if it's any gcode, or just this file. 4 tool print. First 3 go fine. 4th tool it picks up, runs the cleaning routing, then goes to print, and the Z height drops to -3.30mm.

Here's the section of gcode:

G1 E24.67887 F2400.00000
G92 E0
G1 Z0.600 F7800.000
G91
G1 Z5 E-2 F1800
G90
T3
G92 E0
G1 E-2.00000 F2400.00000
G92 E0
G1 X150.900 Y99.100 F7800.000
G1 Z0.350
G1 E2.00000 F2400.00000
G1 F1800
G1 X150.900 Y85.900 E2.66248

Since it's setting the working height to 0.350 in the gcode, I can't for the life of me figure why it's diving to -3.30mm. If it were an offset issue, it would display it was at the correct Z of 0.350

Dropping to 2.02 resolved this issue. (Though in 2.02 it's not running T0 to grab that tool at the start of my print, need to figure that out next I guess since I know others are on 2.02)

I can post my offset files and tool change scripts if that helps.

dc42

@kraegar, please post your config.g and tool change files. Did you read the bit in the upgrade notes about tool offsets being applied by default in the tfree and tpost files in 2.03, when they were not in 2.02?

kraegar

Yes, I saw that bit. I'm using the offsetson.g / offsetsoff.g work around, regardless.

It's working fine for the other tools, and I'm not seeing any reason it would cause the active Z height to display as -3.30.

The config files + gcode file are all here, should be everything relevant: https://www.dropbox.com/sh/7z7txheqdhdvcjc/AADQY-h_WdGFe1kDW3i2lrYYa?dl=0

Dropping to 2.02 did fix the odd behavior with tool 3's printing at -3.30mm. (It's not coincidence that's the correct Z height of 0.35 minus the offset for the tool, I just can't see a reason it would happen)

dc42

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

Yes, I saw that bit. I'm using the offsetson.g / offsetsoff.g work around, regardless.

It's working fine for the other tools, and I'm not seeing any reason it would cause the active Z height to display as -3.30.

The config files + gcode file are all here, should be everything relevant: https://www.dropbox.com/sh/7z7txheqdhdvcjc/AADQY-h_WdGFe1kDW3i2lrYYa?dl=0

Dropping to 2.02 did fix the odd behavior with tool 3's printing at -3.30mm. (It's not coincidence that's the correct Z height of 0.35 minus the offset for the tool, I just can't see a reason it would happen)

Firmware 2.04RC1 is available now. I suggest you try that, and if you think there is still a problem, start a new thread.

DocTrucker

Upgrade from 1.22.6 to 1.24 has left the machine invisible on the browser on the .local address but visible on the IP address.

See: https://forum.duet3d.com/topic/11425/upgrade-from-1-22-6-to-1-24-has-goosed-local-addressing/7