New firmware 3.01-RC2 available

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.

dc42

@zerspaner_gerd said in New firmware 3.01-RC2 available:

For me, two sensor inputs are created?
Where does the numbering start?

The numbering starts at 0. The OM will report "sensors.inputs" up to the highest one you have configured. So when you create sensor 1, it reports inputs 0 and 1, and it reports that sensor 0 is not configured.

dc42

@zerspaner_gerd said in New firmware 3.01-RC2 available:

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

You can do either. I left the S0/S1 parameter options so that you can trigger on both the rising and falling edges of an input.

What happens to the following constellation:
M950 J1 C"!e0stop"				
M581 P1 T0 S1 C0

S1 triggers on an inactive-to-active transition, which for an inverted pin is a high-to-low transition.