Duet firmware 2.03beta3 available

[dc42]

@davea said in Duet firmware 2.03beta3 available:

I have partially solved the issue by changing the bed.g file to use S6 instead of S9 for the last G30.

1. Have you tried S8? I can't rule out the possibility that the adjustment to the homed carriage heights after auto calibration doesn't correctly take account of changes to the rod lengths.

2. What happens if you run a second auto calibration - is the Z0 height still wrong?

[brunofporto]

Just to organize things! I wrongly posted at the beta2 thread but the issue is happening with beta3:

When using G29 it is using nozzle reference and not the probe. And the height map shows as it was measuring the bed as the nozzle where the probe.

I do not have any tool offsets and the probe offset is correctly defined.

I'll copy the config.g line here later.

I did not have this issue with 2.02RC6 that was using before.

[DaveA]

@dc42 Just tried S8. No obvious difference from S6. Nozzle may be slightly different depending upon the drag of the feeler. Change to S9 and the nozzle gives a pretty good whack into the bed. Needed to move up by .35mm to regain clearance. Back to S8 and things seem OK again.

Tried to do back to back S9 and the first time it hit the bed. Second time I'm left about 1mm above the bed. Seems not consistent.

[brunofporto]

ps.2: Just found the issue.... The G31 command for the probe had a comment without the ";" so it did not read that line.... Sorry.. MY fault.

Did some tests and for sure after upgrading from 2.02RC6 to 2.03beta3 it puts the nozzle and not the z-probe when using G32 (that I use to align both leadscrews) and G29.

config.g and bed.g attached.

[0_1553976980746_config.zip](Uploading 100%)

ps.: Downgraded to the latest stable (2.02) and have the same issue!

[zerspaner_gerd]

Is that a security measure that only large M650.G filename extension can be created?

[dc42]

@brunofporto said in Duet firmware 2.03beta3 available:

ps.2: Just found the issue.... The G31 command for the probe had a comment without the ";" so it did not read that line.... Sorry.. MY fault.

Did some tests and for sure after upgrading from 2.02RC6 to 2.03beta3 it puts the nozzle and not the z-probe when using G32 (that I use to align both leadscrews) and G29.

config.g and bed.g attached.

[0_1553976980746_config.zip](Uploading 100%)

ps.: Downgraded to the latest stable (2.02) and have the same issue!

Your upload failed. Please try again. Meanwhile, check that your G31 command is later in config.g than your M558 command, and that you don'r have G31 commands in config-override.g.

[dc42]

@zerspaner_gerd said in Duet firmware 2.03beta3 available:

Is that a security measure that only large M650.G filename extension can be created?

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

[zerspaner_gerd]

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

[Iamturbo1978]

I've ran a few 8-12 hour prints with my coreXY printer. No issues to report at this time. Now to try a 20+ hour print. Thank you for the continued support.

[dc42]

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

[brunofporto]

@dc42 The problem is already solved and was my mistake - nothing related to the beta that is running smoothly since. Thank you!

The problem was that after the command I have a comment and when I updated the Z calibration of my z-probe I deleted the " ; " in front of the comment. The firmware smartly ignored that line and that leads to the issue.

Would be nice if the firmware warned me about ignored lines

Also, another thing is bothering me. I do use the filaments management and inside the config.g of each filament I have only three parameters: pressure advance, firmware retraction and filament monitor parameters. IT loads the config.g correctly when I load the filament using DWC but if the printer is restarted or turned off and on again these configurations are not applied (eg. pressure advance is zero after a reset). Even when M703 is present at the tool config file. I need to mannually execute M703 to lad the current filament configuration.

[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