New firmware 3.01-RC2 available

dc42

That was a misprint, and I've just corrected it.

appjaws

updated the firmware, no problems. one print completed.
thanks @dc42

spllg

fyi: M308 S1 P"temp1" Y"thermistor" B4725 C7.06e-8 seems to be working in rc2

supernovae

Updated on a CoreXY and no problems. Test cube looks great.

arhi

so far so good

Adrian52

@dc42 fan rpm showing up in dwc. Thank you very much.

deckingman

I haven't seen anything in the release notes so I guess the answer is still no, but is M303 heater tuning for remote heaters implemented yet?

dc42

@deckingman said in New firmware 3.01-RC2 available:

I haven't seen anything in the release notes so I guess the answer is still no, but is M303 heater tuning for remote heaters implemented yet?

Not yet, however I now have an implementation plan for it.

arhi

might found a bug:

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

M905 show proper date/time on the board

TurtlePrint

The console is showing Stack Overflow errors when trying to deploy the BLTouch from a macro that that was started from a Trigger and calls another macro. The probe then fails to deploy.

Process:
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.

CheckifHomed.g - Runs fine when run on it's own
CheckifHomed.g - Runs fine when called from "UnloadFilament.g" if UnloadFilament was started from the macro menu
CheckifHomed.g - Runs fine when called from startcode.g
CheckifHomed.g - Runs fine when called directly from trigger7.g

If trigger7.g is moved to the Macro Folder and started manually everything works fine.

config.g Info

M950 J3 C"e1stop"		;Load Buton
M581 T7 P3  	;Runs trigger7.g file when pressed - First step of Unload process

Please let me know if you need any more information.

dc42

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

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.