New firmware 3.01-RC2 available

dc42

@TC said in New firmware 3.01-RC2 available:

@dc42 Talking about tool changes... is it possible also to have a nexttool object? That would make it possible to already preheat the next tool to be used.

A facility to read the GCode stream ahead so that tools can be preheated and filament mixes changed in advanced is planned for Duet 3. There probably isn't enough RAM to fit it in Duet 2.

matej1006

I have Duet 2 Wifi and i have same problem with fan rpm showing random number's. So i will try this update to see is will be same or it will dissape. Thanks @dc42.

DaBit

A few questions:

Do we still have a line length limit? Object model fetches such as 'heat.heaters[tools[state.currentTool].heaters[0]].current' burn through characters quite quickly.

How are line numbers counted when I get a syntax error? The line number given by RRF does not match the error location. Should it be file-linenumber, or are things like empty lines and comment lines skipped?

About the maximum stack depth: how deep is it? It is tempting to split code to separate macros, just like you would normally do with functions. This does increase nesting depth though.

I do not really want to bother you guys with this yet since I have to carefully check the hotend heating before complaining, but I see 'maximum excursion' heater faults when I do not expect them, such as soon after programming a lower temperature for an active heater. Did anything change in RC2 regarding heater fault detection?

dc42

@DaBit said in New firmware 3.01-RC2 available:

Do we still have a line length limit? Object model fetches such as 'heat.heaters[tools[state.currentTool].heaters[0]].current' burn through characters quite quickly.

Yes, 160 characters, not counting leading spaces/tabs.

How are line numbers counted when I get a syntax error? The line number given by RRF does not match the error location. Should it be file-linenumber, or are things like empty lines and comment lines skipped?

It should be line number within the file, with 1 being the first line. If you think it doesn't match, please submit a simple example that reproduces the issue. The column number (if given) is generally the number of the character after the item that caused the problem.

About the maximum stack depth: how deep is it? It is tempting to split code to separate macros, just like you would normally do with functions. This does increase nesting depth though.

5 at present, but it will be increased to 7 in the next release or RC.

I do not really want to bother you guys with this yet since I have to carefully check the hotend heating before complaining, but I see 'maximum excursion' heater faults when I do not expect them, such as soon after programming a lower temperature for an active heater. Did anything change in RC2 regarding heater fault detection?

Not intentionally. Again, if you can reproduce a problem, please post a demo file.

DaBit

@dc42 said in New firmware 3.01-RC2 available:

Not intentionally. Again, if you can reproduce a problem, please post a demo file.

With heater 1/tool 0 active and heater 2/tool 1 standby, executing a 'G10 P1 S250 R200' at the console triggers an 'Error: Heating fault on heater 2, temperature excursion exceeded 15.0°C' after a few seconds.

'M109 T1 S200' works. 'G10 P0 S250 R200' works. Machine homed or not does not change the behaviour.

If I execute a T1 so T0 is put in standby and T1 is made active, the behaviour reverses. 'G10 P0 S250 R200' triggers an error, 'G10 P1 S250 R200' works as expected.

For this test I made sure there were no active M570 commands in the config.

Heaters/tools sections of the config.g:

; Heaters
M308 S0 P"bedtemp" Y"thermistor" T100000 B4092         ; configure sensor 0 as thermistor on pin bedtemp
M950 H0 C"bedheat" T0 Q5                               ; create bed heater output on bedheat and map it to sensor 0
M143 H0 S140                                           ; set temperature limit for heater 0 to 140C
M307 H0 A486.1 C2320.7 D16.5 S1.00 V24.0 B0	       ; PID-parameters for heated bed
M308 S1 P"spi.cs1" Y"rtd-max31865"
M950 H1 C"e0heat" T1 Q50                               ; create nozzle heater output on e0heat and map it to sensor 1
M143 H1 S290                                           ; set temperature limit for heater 1 to 290C
M307 H1 A675.5 C232.3 D2.8 S1.00 V23.7 B0
M308 S2 P"e1temp" Y"thermistor" T100000 B4725 C7.06e-8 ; configure sensor 2 as thermistor on pin e1temp
M950 H2 C"e1heat" T2 Q50                               ; create nozzle heater output on e1heat and map it to sensor 2
M143 H2 S290                                           ; set temperature limit for heater 2 to 290C
M307 H2 A650.8 C253.7 D3.6 S1.00 V23.8 B0			   ; PID parameters for heater 1

; Auxiliary temp sensors
M308 S3 P"mcu-temp" Y"mcu-temp" A"mcu-temp"				; MCU temp
M308 S4 P"e0temp" Y"thermistor" A"Chamber" T100000 B4725 C7.06e-8 ; configure sensor 3 (chamber temp) as thermistor on pin e0temp

; Tools
M563 P0 S"Extruder 0" D0 H1 F0                         ; define tool 0
G10 P0 X0 Y0 Z0                                        ; set tool 0 axis offsets
G10 P0 R0 S0                                           ; set initial tool 0 active and standby temperatures to 0C
M563 P1 S"Extruder 1" D1 H2 F0                         ; define tool 1
G10 P1 X19.88 Y0.1 Z0                                   ; set tool 1 axis offsets
G10 P1 R0 S0                                           ; set initial tool 1 active and standby temperatures to 0C
M104 S0 T0					       ; make sure the heater is not 'off'
M104 S0 T1					       ; make sure the heater is not 'off'

dc42

@DaBit said in New firmware 3.01-RC2 available:

@dc42 said in New firmware 3.01-RC2 available:

Not intentionally. Again, if you can reproduce a problem, please post a demo file.

With heater 1/tool 0 active and heater 2/tool 1 standby, executing a 'G10 P1 S250 R200' at the console triggers an 'Error: Heating fault on heater 2, temperature excursion exceeded 15.0°C' after a few seconds.
'M109 T1 S200' works. 'G10 P0 S250 R200' works. Machine homed or not does not change the behaviour.
If I execute a T1 so T0 is put in standby and T1 is made active, the behaviour reverses. 'G10 P0 S250 R200' triggers an error, 'G10 P1 S250 R200' works as expected.

I confirm this was an unintended change in 3.01-RC2. Please can you check that the new binary at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0 corrects it. This binary also has the maximum stack depth increased to 7.

DaBit

I can confirm that the issue is resolved.
Thanks for the exceptionally quick response, once again!

I will check the error line numbers later, with this firmware.

dc42

@DaBit said in New firmware 3.01-RC2 available:

I can confirm that the issue is resolved.
Thanks for the exceptionally quick response, once again!

I will check the error line numbers later, with this firmware.

I haven't changed the line numbering in this build, so I expect the issue is unchanged. Please supply a test file to reproduce it.

smoki3

Is it actually possible to define more than one probe?

I tried M558 K1 for G38.x and M585 but it always responds only for my Zprobe

dc42

@smoki3 said in New firmware 3.01-RC2 available:

Is it actually possible to define more than one probe?

I tried M558 K1 for G38.x and M585 but it always responds only for my Zprobe

Currently it's possible to define more than one probe but not to switch between them.

smoki3

@dc42 I don't understand?

; Z-Probe

M558 K0 P5 C"^!zprobe.in" H3 F180 T25000	   	; Z probe connected to Z endstop input
G31 K0 X0 Y0 Z0.17 P500          	               	; Set Z probe offset + naher ran - weiter weg

; Tool Probe
M558 K1 P5 C"!e0stop" H5 F120 T3000  		  	; Tool probe connected to Z endstop input
G31 K1 X0 Y0 Z0 P500          	               	; Set Z probe offset + naher ran - weiter weg

I defined this one. If I report the probe status with G31 K0 or K1 it always only responds for K0. If I try to use it K1 in G38.2 P1 or in M585 P1 it only react when K0 is trigged and not for K1

dc42

@smoki3 said in New firmware 3.01-RC2 available:

If I report the probe status with G31 K0 or K1 it always only responds for K0.

I see the problem, which is that there is only one Z probe input filter. So only one Z probe can be type 1,2,3 or 5. Defining two type 8 Z probes works for me. I will add a note to the M558 description.

jay_s_uk

Running 3.01-RC2 on the expansion board, for me at least, results in none of the motor drivers working.
I have had to roll back to 3.0-RC2 to get them to work and to be able to print.

matej1006

Hello @dc42 why my fan rpm on duet web is wrong.it's show number between 25000 and 32000 on my noctua fan which has 100% open PWM 1700RPM.
i upgrade my DUET2 Wifi with: Duet2CombinedIAP and Duet2CombinedFirmware

Please help

dc42

@matej1006 said in New firmware 3.01-RC2 available:

Hello @dc42 why my fan rpm on duet web is wrong.it's show number between 25000 and 32000 on my noctua fan which has 100% open PWM 1700RPM.
i upgrade my DUET2 Wifi with: Duet2CombinedIAP and Duet2CombinedFirmware

Is it a 4-wire fan, and have you connected it as recommended for 4-wire fans? Was it giving the correct RPM before you upgraded the firmware?

If so then my guess is that the tacho input is picking up noise from the PWM input, or from stepper motor cables in the same wiring bundle.

matej1006

@dc42 Yes i have noctua 4 wire pwm i have blue wire to fan7 on duex and tacho with 1n4148 connected to pb6 on duex
and previus version also didn't work same problem random number between 25000 and 30000
and now after i send home posittion then show's that strange nubmer for PWM before that is around 1700 RPM

zerspaner_gerd

For me, two sensor inputs are created?

Where does the numbering start?
An example on Gcode Wiki shows J1, so I thought it started at one.

Shouldn't "M581 T3 S0" make a change?
There is only one message

zerspaner_gerd

Would have another question
Should you invert the pin on M950 or with M581 S1?

What happens to the following constellation:

M950 J1 C"!e0stop"				
M581 P1 T0 S1 C0

sdavi

@dc42 I came across a minor issue in 3.01RC2 (tested on DuetWifi). The gcode line numbers do not reset each time M32 is run, so a gcode file that contains conditional gcode errors will display the incorrect line number if it's not the first one run since reset.

dc42

@sdavi said in New firmware 3.01-RC2 available:

@dc42 I came across a minor issue in 3.01RC2 (tested on DuetWifi). The gcode line numbers do not reset each time M32 is run, so a gcode file that contains conditional gcode errors will display the incorrect line number if it's not the first one run since reset.

Thanks for reporting that, I'll fix it in RC3.