New firmware 3.01-RC2 available

dc42

@TurtlePrint said in New firmware 3.01-RC2 available:

A state change occurs on "e1stop" and trigger7.g is run. It calls "UnloadFilament.g" which then runs "CheckifHomed.g". During the homing operation the BL Touch probe fails to deploy and the bed crashes. The console shows 2 Stack Overflow errors when the probe attempts to deploy.

Looks like you are exceeding the maximum allowed stack depth. Every macro file called (including homing macros and the Z probe deploy/retract macro) uses one level. I can increase it in the next RC.

arhi

@dc42 said in New firmware 3.01-RC2 available:

@arhi said in New firmware 3.01-RC2 available:

might found a bug:

all files uploaded since RC2 have N/A for "last modified" time/date

Strange, it's working for me, I just tested uploading to Duet WiFi and to Duet 3 in standalone mode. Are you using DWC 2.0.7? Which Duet?

Board: Duet Ethernet 1.02 or later
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.01-RC2 (2020-02-18b1) 
Duet Web Control 2.0.7

but looks like when I upload from DWC (upload gcode file button) it works ok but when I curl it to the duet

@echo off

for %%a in (%1) do (
    set filepath=%%~dpa
    set filename=%%~na
    set extension=%%~xa
)   
set if=%filepath%%filename%%extension%

G:\bin\curl-7.50.3-win64-mingw\bin\curl.exe -G --data-urlencode gcode=M30"%filename%%extension%" http://ender5.local.lan/rr_gcode
G:\bin\curl-7.50.3-win64-mingw\bin\curl.exe  --data-binary "@%if%" "http://ender5.local.lan/rr_upload?name=gcodes/%filename%%extension%"

the datetime is not there

dc42

There is an additional parameter to the rr_upload command that specifies the date/time to use for the time stamp.

What was the latest version of RRF for which the time stamp was set when you uploaded files using curl?

EDIT: I just ran the following:

curl.exe --data-binary "@symarchive.bat" "http://192.168.1.126/rr_upload?name=gcodes/symarchive.bat"

and it did set the time stamp on the uploaded file.

Note, you need to have connected to the Duet with DWC before you do the upload using curl, otherwise the date/time will not be set on the Duet. Or you can pass the time stamp as an extra parameter, like this:

C:\Eclipse\Firmware>curl.exe --data-binary "@symarchive.bat" "http://192.168.1.126/rr_upload?name=gcodes/symarchive.bat&time=2013-04-05T11:12:13"

TurtlePrint

@dc42 Is it possible to have the Duet "Emergency Stop" when a Stack overflow occurs?

dc42

@TurtlePrint said in New firmware 3.01-RC2 available:

@dc42 Is it possible to have the Duet "Emergency Stop" when a Stack overflow occurs?

I can quite easily make it abandon the current print job.

arhi

@dc42 said in New firmware 3.01-RC2 available:

There is an additional parameter to the rr_upload command that specifies the date/time to use for the time stamp.

ah, didn't know that

What was the latest version of RRF for which the time stamp was set when you uploaded files using curl?

The update to the RRF and script for s3d came roughly at the same time so I started using CURL when I updated to RC2

Note, you need to have connected to the Duet with DWC before you do

That's the missing link! Thanks, that solved the problem
Apologies for the false alarm.

Will modify the script to send proper time value, thanks for example.

Is there a way to tell DWC to refresh file list using curl?

dc42

@arhi said in New firmware 3.01-RC2 available:

Is there a way to tell DWC to refresh file list using curl?

Not AFAIK, but @chrishamm might know otherwise.

Luke'sLaboratory

Hey - will state.previoustool be persistent through power cycle/M999?
It would be nice if there could be a condition check on homing to make sure that the previous tool is re-docked before attempting a home, to prevent damage to tool (especially from inattentive tinkerers)

dc42

@Luke-sLaboratory said in New firmware 3.01-RC2 available:

Hey - will state.previoustool be persistent through power cycle/M999?
It would be nice if there could be a condition check on homing to make sure that the previous tool is re-docked before attempting a home, to prevent damage to tool (especially from inattentive tinkerers)

The only things that persist across a restart are data stored in config-override.g when you run M500, and the software reset data.

For tool changers I suggest using microswitches to detect when tools are docked, or a microswitch to detect when a tool is loaded.

TC

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

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.