RepRapFirmware 3.01-beta 3 released

garyd9

(I feel like I might have read something about this before, but I can't find it..)

Is it known/intentional that uploading "Duet3Firmware_MB6HC.bin" to DWC 2.0.7/System/"Upload System File" on a duet3 (standalone) does not trigger a prompt for updating the firmware?

The firmware loads properly if I send "M997" from the console.

gtj0

@dc42 The commit with the update for the machine coordinates looks like it also has CAN changes but the most recent CANlib doesn't have the support for it. Forget to push up a new CANlib?

nvoking: Cross G++ Compiler
arm-none-eabi-g++ -std=gnu++17 -D__SAME70Q20B__ -DRTOS -DDUET3_V06 -D_XOPEN_SOURCE -I"/usr/src/3d/dc42/workspace/RRFLibraries" -I"/usr/src/3d/dc42/workspace/FreeRTOS" -I"/usr/src/3d/dc42/workspace/CoreNG" -I"/usr/src/3d/dc42/workspace/CANlib" -I"/usr/src/3d/dc42/workspace/CoreNG/cores/arduino" -I"/usr/src/3d/dc42/workspace/CoreNG/libraries/Flash" -I"/usr/src/3d/dc42/workspace/CoreNG/libraries/SharedSpi" -I"/usr/src/3d/dc42/workspace/CoreNG/libraries/Storage" -I"/usr/src/3d/dc42/workspace/CoreNG/libraries/Wire" -I"/usr/src/3d/dc42/workspace/CoreNG/asf" -I"/usr/src/3d/dc42/workspace/CoreNG/asf/common/utils" -I"/usr/src/3d/dc42/workspace/CoreNG/asf/common/services/clock" -I"/usr/src/3d/dc42/workspace/CoreNG/asf/common/services/ioport" -I"/usr/src/3d/dc42/workspace/CoreNG/asf/sam/components/ethernet_phy/ksz8081rna" -I"/usr/src/3d/dc42/workspace/CoreNG/asf/sam/drivers" -I"/usr/src/3d/dc42/workspace/CoreNG/asf/sam/drivers/gmac" -I"/usr/src/3d/dc42/workspace/CoreNG/asf/sam/services/flash_efc" -I"/usr/src/3d/dc42/workspace/CoreNG/asf/sam/utils" -I"/usr/src/3d/dc42/workspace/CoreNG/asf/sam/utils/cmsis/same70/include" -I"/usr/src/3d/dc42/workspace/CoreNG/asf/sam/utils/header_files" -I"/usr/src/3d/dc42/workspace/CoreNG/asf/sam/utils/preprocessor" -I"/usr/src/3d/dc42/workspace/CoreNG/asf/thirdparty/CMSIS/Include" -I"/usr/src/3d/dc42/workspace/CoreNG/variants/same70" -I"/usr/src/3d/dc42/workspace/RepRapFirmware/src" -I"/usr/src/3d/dc42/workspace/RepRapFirmware/src/Networking" -I"/usr/src/3d/dc42/workspace/RepRapFirmware/src/Networking/LwipEthernet" -I"/usr/src/3d/dc42/workspace/RepRapFirmware/src/Networking/LwipEthernet/Lwip/src/include" -I"/usr/src/3d/dc42/workspace/DuetWiFiSocketServer/src/include" -I"/usr/src/3d/dc42/workspace/FreeRTOS/src/include" -I"/usr/src/3d/dc42/workspace/FreeRTOS/src/portable/GCC/ARM_CM7/r0p1" -I"/usr/src/3d/dc42/workspace/RRFLibraries/src" -I"/usr/src/3d/dc42/workspace/CANlib/src" -O2 -Wall -c -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=hard -mno-unaligned-access -ffunction-sections -fdata-sections -fno-threadsafe-statics -fno-rtti -fexceptions -nostdlib -Wundef -Wdouble-promotion -Werror=return-type -fsingle-precision-constant "-Wa,-ahl=EndstopsManager.s" -MMD -MP -MF"src/Endstops/EndstopsManager.d" -MT"src/Endstops/EndstopsManager.o" -o "src/Endstops/EndstopsManager.o" "../src/Endstops/EndstopsManager.cpp"
../src/GCodes/GCodes2.cpp: In member function 'bool GCodes::HandleMcode(GCodeBuffer&, const StringRef&)':
../src/GCodes/GCodes2.cpp:4338:27: error: 'ChangeAddressAndNormalTiming' is not a member of 'CanInterface'
    result = CanInterface::ChangeAddressAndNormalTiming(gb, reply);
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/GCodes/GCodes2.cpp:4342:27: error: 'ChangeFastTiming' is not a member of 'CanInterface'
    result = CanInterface::ChangeFastTiming(gb, reply);
                           ^~~~~~~~~~~~~~~~

dc42

I'm sorry about that, I've committed it now.

dc42

@garyd9 said in RepRapFirmware 3.01-beta 3 released:

(I feel like I might have read something about this before, but I can't find it..)

Is it known/intentional that uploading "Duet3Firmware_MB6HC.bin" to DWC 2.0.7/System/"Upload System File" on a duet3 (standalone) does not trigger a prompt for updating the firmware?

The firmware loads properly if I send "M997" from the console.

It's know but not intentional. I'll ask @chrishamm to fix it in a future DWC release.

gtj0

@dc42 said in RepRapFirmware 3.01-beta 3 released:

I'm sorry about that, I've committed it now.

Still not working. Even with the "Added CanSettings::ClockFrequency" commit, ChangeAddressAndNormalTiming and ChangeFastTiming aren't in CANlib.

dc42

There's a new commit of RepRapFirmware coming soon.

zerspaner_gerd

I always get an error when I want the trigger no. Query.
Has the behavior changed with RF3, or an error?

Danal

Board: Duet 3 MB6HC (MB6HC)
DSF Version: 1.2.4.0
Firmware: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 3.01-beta3 (2020-01-29b1)

Also get the error.

dc42

Thanks for reporting this. I've fixed it in the latest internal builds at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.

zerspaner_gerd

@dc42 Seems to be fixed

With M98 P "config.g" I get the following errors:

Error: M307: Heater 3 not found
Error: M307: Heater 4 not found
Error: M307: Heater 5 not found
Error: M307: Heater 6 not found
Error: M307: Heater 7 not found

Am i missing something?

; Heaters
M308 S0 P"spi.cs1" Y"rtd-max31865"		; configure sensor 0 as thermocouple/PT100 via CS pin spi.cs1
M950 H0 C"bedheat" T0					; create bed heater output on bedheat and map it to sensor 0
M307 H0 B0							; aktiviert den PID-Modus Heizbett
M301 H0 P124.55 I23.46 D165.29			; alter PID-Werte Heizbett von UM
M143 H0 S101						; Set temperature limit for heater 0 to 101C
M140 H0								; map heated bed to heater 0

M308 S1 P"spi.cs2" Y"rtd-max31865"		; configure sensor 1 as thermocouple/PT100 via CS pin spi.cs2
M950 H1 C"e0heat" T1					; create nozzle heater output on e0heat and map it to sensor 1
M143 H1 S265						; Set temperature limit for heater 1 to 265C

M308 S2 P"spi.cs3" Y"rtd-max31865"		; configure sensor 2 as thermocouple/PT100 via CS pin spi.cs3
M950 H2 C"e1heat" T2					; create nozzle heater output on e1heat and map it to sensor 2
M143 H2 S265						; Set temperature limit for heater 2 to 265C

dc42

Those M307 commands for non-existent heaters are probably in config-override.g and were put there by RRF2. You can delete them.

zerspaner_gerd

I am currently looking for the endstop inputs of E0 (e0stop) and E1 (e1stop)
M409 K"sensors.endstops" F"v" shows only three

dc42

@zerspaner_gerd said in RepRapFirmware 3.01-beta 3 released:

I am currently looking for the endstop inputs of E0 (e0stop) and E1 (e1stop)
M409 K"sensors.endstops" F"v" shows only three

The sensors.endstops variable only reports inputs configured as endstops. I need to add a separate section for other inputs.

Possible temporary workaround: create two additional axes e.g. U and V, and hide them using the M584 P parameter. Then you can assign those two endstop inputs to those axes using M574, and then they should be visible in sensors.endstops.

zerspaner_gerd

Thank you

@dc42 said in RepRapFirmware 3.01-beta 3 released:

and hide them using the M584 P parameter.

The axes must be visible so that one can see the end stop.
But I can continue to play with it

dc42

I'll change it in the next build to include endstops for invisible axes.

zerspaner_gerd

Somehow I came across strange things, here are my examples
Trigger 2 is triggered permanently
Trigger 1 is confirmed with a finger

Loop does not work:

G28 X Y
G0 X10 Y200 F1000
M400
M18 X Y
M400 

while sensors.endstops[2].triggered	; == false
	;echo "sensor wakü", sensors.endstops[2].triggered
	; M291 P"TEST1234" R"TEST" S2
	if sensors.endstops[1].triggered
		abort "TEST abort"


echo "ENDE"

The loop works with the following code:

G28 X Y
G0 X10 Y200 F1000
M400
M18 X Y
M400 

while sensors.endstops[2].triggered	; == false
	;echo "sensor wakü", sensors.endstops[2].triggered
	; M291 P"TEST1234" R"TEST" S2
	if sensors.endstops[1].triggered
		abort "TEST abort"
M400

echo "ENDE"

But the abort function does not work, the printing is not canceled
With this code the abort function works

G28 X Y
G0 X10 Y200 F1000
M400
M18 X Y
M400 

while sensors.endstops[2].triggered	; == false
	;echo "sensor wakü", sensors.endstops[2].triggered
	; M291 P"TEST1234" R"TEST" S2
	if sensors.endstops[1].triggered
		break
M400

if sensors.endstops[1].triggered
	abort "TEST abort"

The abort function only seems to work if it is at the very end of the file.
(Also works in a macro as soon as it is at the end of the macro)

Could someone test this on their Duet?

dc42

I have tested this slightly modified version on my Duet WiFi powered delta running 3.01beta3:

G28
G1 Z350 F6000
M400 

while !sensors.endstops[0].triggered	; == false
	;echo "sensor wakü", sensors.endstops[2].triggered
	; M291 P"TEST1234" R"TEST" S2
	if sensors.endstops[1].triggered
		abort "TEST abort"
M400

echo "ENDE"

I invoke it from within a print file, and it works as it should. It homes the printer, goes down, then waits for me to trigger the X endstop. If I am not holding the Y endstop down when i do that, it carries on printing and echoes ENDE. If I am holding down the y endstop at that time, it aborts the print and echoes TEST abort.

zerspaner_gerd

It's different with me, Duet2 Wiffi. This time also called from a print file.
Your mentioned variant does not happen to me, printing is successfully completed. The macro file is only canceled.
abort test abort.jpg

With "abort" at the end of the file, the printing movements are stopped, but the printer status remains "Printing/Processing"
abort if test abort ergebnis_LI.jpg

Sometimes only an emergency stop helps, sometimes I can use "Pause Print" and then "Cancel Print" to escape the "Printing/Processing" status

Signature is up to date (firmware version, etc.)

zerspaner_gerd

The tool status (tools[0].state) appears to no longer be updated to off.
When starting, off is displayed, but once active, off is no longer displayed.
Only with me or can someone reproduce that

dc42

Please check whether you still have these 2 issues using the new binary at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.