Duet firmware 2.03beta3 available

Phaedrux

@brunofporto said in Duet firmware 2.03beta3 available:

I need to mannually execute M703 to lad the current filament configuration.

I'm not exactly sure what the intended behaviour is, but as a work around you could try adding M703 to the end of the main config.g, or the end of config-override.g if you use it?

zerspaner_gerd

@dc42 said in Duet firmware 2.03beta3 available:

@zerspaner_gerd said in Duet firmware 2.03beta3 available:

@dc42 said in Duet firmware 2.03beta3 available:

Go to Settings/User Interface and uncheck "Always convert G-codes to uppercase".

Does not make a difference for me!

Earlier today I created a file called m650.g without any problem.

Correct,
If a small "m" is written, the "g" also becomes small

m350 -> small m350.g
M350 -> big M350.G

brunofporto

@phaedrux I think that should do it! The intended behavior is keeping the configurations between turn offs and resets.

Thank you!

dc42

@zerspaner_gerd said in Duet firmware 2.03beta3 available:

@dc42 said in Duet firmware 2.03beta3 available:

@zerspaner_gerd said in Duet firmware 2.03beta3 available:

@dc42 said in Duet firmware 2.03beta3 available:

Go to Settings/User Interface and uncheck "Always convert G-codes to uppercase".

Does not make a difference for me!

Earlier today I created a file called m650.g without any problem.

Correct,
If a small "m" is written, the "g" also becomes small

m350 -> small m350.g
M350 -> big M350.G

Quite so - how strange! It's the same in DWC 1.22.6 and 2.0.0RC6. But after created M654.G, I find I can rename it to M654.g.

dc42

I did some more research. A file such as M650.g is created with the correct name, however it is read back as M650.G. This turned out to be a known bug in the FatFs library, which RRF uses to manage the SD card files. A patch to fix it was released in January, and this (along with 2 other patches) will be included in the next 2.03beta release of RRF.

hestiahuang

@dc42 , I am using 1.03 duet2wifi board, which bin I should flash?

Phaedrux

@hestiahuang if you're not sure which bins to use, you may want to stick to the 2.02 release which lets you upload the whole zip file.

However if you are sure you want to test the beta you'll need the duet 2combined firmware and the duet wifi server and the DWC files from 2.02.

hestiahuang

@phaedrux Many thanks for your reply!!!

Phaedrux

I just ran into some odd behaviour with M291 axis jogging prompts.

I use a macro to level my bed by moving the nozzle around to various points and manually lowering the nozzle to the same height and adjusting the leveling screws until the bed meets the nozzle. This part runs on the PanelDue and it worked fine.

The next part is a macro to find the z probe trigger height. It uses a prompt to manually lower the nozzle to the bed and sets G92 Z0 and then does 10 G30 S-1 tests. In order for the results to show up in the Gcode console in the DWC this macro is run from the DWC and the jog prompts pop up there.

This is where the issue occured. The first time I ran it, it skipped the jogging prompt entirely and executed the G30 S-1 section without me setting Z0. I stopped it and modified the macro to include some M400 commands, and this time it displayed the jogging prompt.

However, this time when trying to lower the nozzle by 1mm the command would get repeated. So even though I clicked once, it would repeat the command several times until the nozzle was ramming into the bed. I had to kill the power.

Reverted to 2.02a and it works as expected.

Macros here:0_1554783758031_0_Auto Bed Level Assist.g 0_1554783793732_0_Auto Probe Trigger Height Assist.g

Denis

@dc42 I started using version 2.03beta3 since its publication. I can not remember if I calibrated the printer with this firmware, if I used raft or babystepping. But today, my printer stopped responding to the babystepping and incorrectly calculated the height when printing on a raft, tearing the part off with a nozzle. A rollback to the stable version fixed this problem. I also want to note that after calibration the nozzle was not positioned at 0, all the time being above the bed

dc42

@denis said in Duet firmware 2.03beta3 available:

@dc42 I started using version 2.03beta3 since its publication. I can not remember if I calibrated the printer with this firmware, if I used raft or babystepping. But today, my printer stopped responding to the babystepping and incorrectly calculated the height when printing on a raft, tearing the part off with a nozzle. A rollback to the stable version fixed this problem. I also want to note that after calibration the nozzle was not positioned at 0, all the time being above the bed

Are you using tool Z offsets and tool change files? One of the changes in 2.03 is that in system macros such as tool change files, tool offsets are taken into account. In 2.02 they were not.

Denis

@dc42 If you mean the G10 command, then no. Just in case published my config . Sorry, comments in the files in Russian https://yadi.sk/d/3ODm-BjOr9FDhg

Denis

@dc42 Oh, I lied. g10 is basically a config, but without offset

Denis

@dc42 I restrict the movement with the command M208 Z0 S1, is it possible that the babystepping does not allow the nozzle to be moved lower,
but nevertheless it is taken into account and prevents to go to the next layer, introducing an error? Because after a small height, the transition to the next layer is carried out without problems

zerspaner_gerd

Can one with this function:

M470 and M471 commands are now implemented (thanks wilriker)

Make a finished printed gcode move to a subfolder?
Or you have to specify directory name and file name every time, even though it is executed from a file!

wilriker

@zerspaner_gerd said in Duet firmware 2.03beta3 available:

Can one with this function:

M470 and M471 commands are now implemented (thanks wilriker)

Make a finished printed gcode move to a subfolder?
Or you have to specify directory name and file name every time, even though it is executed from a file!

It's the latter. They do require source and destination file names.
I have no idea if it would even work to move the file this command is inside. Will test that after my current print is finished. Probably it will move the file but it might be that none of the following commands will be executed after moving.

EDIT: I tested to move the file that was containing the M471 command and it actually continued to execute. Though I have no idea how much of the data was already buffered and if it would have needed to be a lot longer to see any issues.
Still, I don't think it is a good idea to move the currently executing file. It might work or it might fail.