Stable firmware 2.01 (Duet 2) and 1.22 (Duet 06/085) released

dc42

@sjason1377, please send M552 from USB to see whether the Duet is connected t the network and confirm its IP address.

mfd

Thanks.

It looks like this is still in the early stages. It states that the "following commands will be supported", is the number command currently support? If so, how is the identifier determined?

What I am currently interested in is the current and active temps for tool0 and bed heaters. Maybe the fraction printed.

dc42

Items that should be able to be displayed and adjusted where applicable are:

0+n Heater n current temperature
100+n Heater n active temperature
200+n Heater n standby temperature
300+n Fan n speed
399 Current print cooling fan speed
400+n Extruder n extrusion factor
500 Speed factor

This is the value of the N parameter in the 'value' command.

The 'image' command doesn't work yet. The 'files' command doesn't work in my fork, but M3D has a build that implements it. I plan to merge their code into my fork before the 2.02 release.

HTH David

kraegar

Just got to upgrade to 2.01, I'd been at 2.01b2. Got a bit of a surprise.

I'd used some old output from the gcode console to configure my current and microstepping. Specifically around the E field and the number of values. It had reported 9, so I set 9.

In 2.01 I discovered the fun way that if you have more than 7 E values configured, weird things happen:

M906
Motor current (mA) - X:1500, Y:1500, Z:1500, E:0:0:1500:1500:1500:0:0, idle factor 60%

(Similar for M203, forgot to copy it before I fixed it)

Lowering the number of fields in my config.g fixed it. Obviously I shouldn't have had that many, but it was being defined based on the number previously reported:

M203
Microstepping - X:16(on), Y:16(on), Z:16(on), E:16(on):16(on):16:16:16:16:16:16:16

Running an extruder with zero current and the incorrect microstepping does some weird stuff!

Edit:
The output at the gcode console was good at explaining what was wrong, so I fixed it quickly once I realized there was an issue:

M906 X1500 Y1500 Z1500 E700:1500:1500:1500:1500:1500:1500:1500:1500 I60
Error: GCodes: Attempt to read a GCode float array that is too long: M906 X1500 Y1500 Z1500 E700:1500:1500:1500:1500:1500:1500:1500:1500 I60

Last edit: I see this was covered in the release notes in whatsnew. I just missed it. This is just a bit of insight on what happens in that case. Carry on!

SputnikOC3d

Neither M561 nor G29 S2 adjusted the user Z coordinate if bed compensation was previously active (G29 S2 did if you ran it twice)

From the release notes and not mentioned in later releases ... Im not sure I understand from this bug fix description, what this means and is doing ... but suspect it may resolve an issue I have been experiencing from day 1 on my cartesian Prusa MK3 style printer and mesh bed leveling and Z height adjusting on Layer 1

I can never really seem to get a stable proper 1st layer height between prints and have to make rather large adjustments [ Z height baby stepping ] between prints and manually dial in Z with baby stepping - every print - even when printing on the same day or within the same hour.

It always seem like the layer height adjustments were being compounded or stacked - even if I ran M561 between. Only way to seem to get a fresh start was a reboot of the machine. And then the baby step dial in after Mesh Bed Comp was run and Dual Z lead screw tilt correction macros were run.

Im currently on 2.0 - wondering if this is a potential fix for my issue[s]