Firmware 2.02 Release candidate 3 now available

stewwy

Running well. No problems so far, just moved from 0.0 at center back to 0.0 at edge also been playing with extruder mA so I've redone config.g a couple of times. printing well

3DOeste

I was going to post in the other thread, but I just finished a 27hr print with 2.02 RC 2 without issues.

Phaedrux

M600: Filament change pause ¶
This command is supported for compatibility with other firmwares. It behaves like M226 except that if macro file filament-change.g exists in /sys on the SD card, it is run in preference to pause.g.

That's great. I did a filament swap last night and was wanting something exactly like this.

fma

David, what does 'Implemented the object model framework and a few variables' mean? Is it internal dev stuff, or user features?

dc42

@fma said in Firmware 2.02 Release candidate 3 now available:

David, what does 'Implemented the object model framework and a few variables' mean? Is it internal dev stuff, or user features?

The object model will underpin three features planned for forthcoming firmware revisions: conditions and loops in GCode, more flexible/more readable menu description files for the 12864 display on the Duet Maestro, and user-configurable fields in Duet Web Control. Currently it is only used in two places:

The M408 P1 S"filter" command uses it to return values from the object model. It's not fully working because of a bug in the filter parser, however M408 P1 with no filter returns the complete object model. DWC will use a similar mechanism to retrieve values for user-specified fields.
In a G- or M-code command, in place of a numeric parameter it should be possible to use an expression such as [gcodes.speedFactor]. But this isn't useful yet because so few variables are included in the object model, also it's not working because of the same bug in the filter parser.

The next step is to design the object model. Some of the existing module boundaries (gcodes, platform, move etc.) are not right for the object model, so some redesign/refactoring will be needed.

Jacotheron

Working on my CNC no issues detected.

The object model framework seems to be exactly what I sometimes need. Can't wait, and excited that it will be coming (specifically the conditionals and loops).

incogizmo

Tested with Duet Maestro and LCD, no stutter or slowdowns on high detail areas like previously. A decent torture test seems to have been Slic3r Gyroid infill. Awesome work!

dc42

@incogizmo said in Firmware 2.02 Release candidate 3 now available:

Tested with Duet Maestro and LCD, no stutter or slowdowns on high detail areas like previously. A decent torture test seems to have been Slic3r Gyroid infill. Awesome work!

Thanks for confirming that it is fixed.

fma

@dc42 said in Firmware 2.02 Release candidate 3 now available:

The object model will underpin three features planned for forthcoming firmware revisions: conditions and loops in GCode, more flexible/more readable menu description files for the 12864 display on the Duet Maestro, and user-configurable fields in Duet Web Control. Currently it is only used in two places:

The M408 P1 S"filter" command uses it to return values from the object model. It's not fully working because of a bug in the filter parser, however M408 P1 with no filter returns the complete object model. DWC will use a similar mechanism to retrieve values for user-specified fields.

In a G- or M-code command, in place of a numeric parameter it should be possible to use an expression such as [gcodes.speedFactor]. But this isn't useful yet because so few variables are included in the object model, also it's not working because of the same bug in the filter parser.

The next step is to design the object model. Some of the existing module boundaries (gcodes, platform, move etc.) are not right for the object model, so some redesign/refactoring will be needed.

Amazing! The future looks good

kuhnikuehnast

Interesting thing I found about G30:

If you use:

G30 X20 Y20

to probe the bed at a specific point, you always have to calculate the offset of the probe, because the coordinates of the nozzle are used.

Whereas if you use 2:

G30 P0 X20 Y20 H0 Z-99999

the offset of the probe is already calculated and the real probe coordinates are used but not the "actually" coordinates of the nozzle

The H- parameter is still not taken into account when probing. Therefore, I performed a little test:

M561                                                    ; delete any bed transformation
G1 X45.457 Y8.602 Z10 F15000				; go to probing point on floating bed
G30 X45.457 Y8.602 H0 S-1   				; define this point as Z=0

M561                                                    ; delete any bed transformation
G1 X45.457 Y8.602 Z10 F15000				; go to probing point on floating bed
G30 X45.457 Y8.602 H5 S-1   				; define this point as Z=0

M561                                                    ; delete any bed transformation
G30 P0 X20 Y20 H0 Z-99999 S-1			        ; probe point P0

M561                                                    ; delete any bed transformation
G30 P0 X20 Y20 H3 Z-99999 S-1			        ; probe point P0

M561                                                    ; delete any bed transformation
G30 P1 X20 Y20 H3 Z-99999 S-1			        ; probe point P1

This ended up in the results:

20:20:45G32 bed probe heights:, mean nan, deviation from mean nan
20:20:42G32 bed probe heights: 0.004, mean 0.004, deviation from mean 0.000
20:20:39G32 bed probe heights: 0.007, mean 0.007, deviation from mean nan
20:20:36Stopped at height 1.399 mm
20:20:31M98 P"0:/macros/Test H-Factor"
Stopped at height 1.399 mm

So as the H-factor differs every probe, the results are all the same...

greetings kuhni

Adrian52

@dc42 updated to 2.02rc3 and dwc 1.22.4-b1. Prints fine, but at the end of a print, the 'job status' does not seem to finish properly. Previously the 'print another' option would appear, but now I just get greyed out 'pause job' button. Using a Kossel delta. Can select and print another job from the g-code files tab.

Adrian52

@adrian52 previous version dwc seems to work fine with rc3

pro3d

@phaedrux
Did you test M600 yet?

Does it have pause and park feature or does this have to be macros on the side?

/Roy

stewwy

Had a problem with the 1.22.4 web interface:

Uploading a file the first time using the upload&print button was fine.
However if I upload it again with the same filename, having made some slicer settings, and having paused and canceled the original it usually failed the re-upload.

Just retrying with 1.22.3 and it works fine

Phaedrux

@pro3d it will run pause.g by default or filament-swap.g if present. So you have to customize the macro to your needs.

k3lag

@dc42 updated to 2.02rc3 and dwc 1.22.4-b1. Since upgrading whenever I scroll down in DWC it automatically scrolls back up a couple seconds later. Very irritating. I'm using Safari 12.0. This hasn't been a problem with any previous version. It seems to print fine however.

dc42

@k3lag said in Firmware 2.02 Release candidate 3 now available:

@dc42 updated to 2.02rc3 and dwc 1.22.4-b1. Since upgrading whenever I scroll down in DWC it automatically scrolls back up a couple seconds later. Very irritating. I'm using Safari 12.0. This hasn't been a problem with any previous version. It seems to print fine however.

Which version of DWC were you using previously?

Dougal1957

@k3lag I can't reproduce this in Safari 12.0 it appears just fine to me tho I normally use Chrome.

Doug

zerspaner_gerd

@k3lag said in Firmware 2.02 Release candidate 3 now available:

@dc42 updated to 2.02rc3 and dwc 1.22.4-b1. Since upgrading whenever I scroll down in DWC it automatically scrolls back up a couple seconds later. Very irritating. I'm using Safari 12.0. This hasn't been a problem with any previous version. It seems to print fine however.

I have that too (with Chrome).
It depends on the screen size, I noticed.

Here are two pictures see scroll bar
0_1540130916549_Scrollen 100%.jpg
jump back (100%)

0_1540131019863_Scrollen 110%.jpg
scrolling works (110%)

But I already had it with the previous version DWC 1.22.1

k3lag

I was using 1.22 and never noticed a problem. I reverted back to 1.22.3 and it behaved the same as the .4b1. However, I figured out that it is related to 'scaling' the web page. If I use the buttons in my browser to either shrink or enlarge the page the problem occurs. It does not occur if it's not being scaled. It appears others have seen the same thing in other browsers. I don't have this problem with any other web pages that I've noticed.