RepRapFirmware 3.01-beta 3 released

Danal

@smoki3 said in RepRapFirmware 3.01-beta 3 released:

One more question:
When is the state.currentTool updated?

After the tpre.g or after the tpost.g?
Normally it should after the tpre.g, right?

Based on when tool offsets are active (or not) in the various macros, the machine appears to consider the tool NOT mounted in pre, and to consider it mounted in post. I would expect that state.currentTool would follow.

Of course, @dc42 can give the definitive answer...

dc42

@Danal said in RepRapFirmware 3.01-beta 3 released:

Based on when tool offsets are active (or not) in the various macros, the machine appears to consider the tool NOT mounted in pre, and to consider it mounted in post. I would expect that state.currentTool would follow.

That's the intention. It should be set to n-1 just after executing tfree and to the new tool number just before executing tpost.

smoki3

@dc42 said in RepRapFirmware 3.01-beta 3 released:

@Danal said in RepRapFirmware 3.01-beta 3 released:

Based on when tool offsets are active (or not) in the various macros, the machine appears to consider the tool NOT mounted in pre, and to consider it mounted in post. I would expect that state.currentTool would follow.

That's the intention. It should be set to n-1 just after executing tfree and to the new tool number just before executing tpost.

Yeah tried it today... Working fine

kraegar

Been printing steadily and haven't seen any issues to report yet. Still tinkering with conditional gcode

dc42

@garyd9 said in RepRapFirmware 3.01-beta 3 released:

Based on the description, that must have been a challange to track down. So much so, that I'm looking forward to the github commit to see the before/after code.

This is now fixed, source code committed, and new binaries put on Dropbox.

Ntrack

Running latest beta (3+1) on duet wifi I get an error

G28 U
Error: in file macro, line 11 column 5: 'else' did not follow 'if'
Error: Homing failed

homeU.g file

if sensors.endstops[4].triggered 
	if state.status == "Busy"
		M291 P" Idle MMU loaded. Selector homing not allowed.Please unload MMU manually." S2

if sensors.endstops[4].triggered 
	if state.status == "Processing" 
		M25
		M291 P"printing  MMU loaded. Selector homing not allowed.Please unload MMU manually." S2	

else
	M913 U50              		 ; reduce motor current to 50% to prevent bad noises
	M915 U S5 F0			; set stall parameters
	G91                   		 ; use relative positioning
	G1 H1 U5 F2000            	  ; move out 5mm
	G1 H1 U-100 F1000       	     ; move carriage to home
	G90                 		   ; back to absolute positioning
	M400               		     ; make sure everything has stopped before we reset the motor currents
	M913 U100       		    ; motor currents back to normal

Was working on beta2.

gtj0

@dc42 Apparently you and @chrishamm aren't on speaking terms because the DSF doesn't get the current axis coordinates with the latest 3.01betas.

dc42

@Ntrack said in RepRapFirmware 3.01-beta 3 released:

Running latest beta (3+1) on duet wifi I get an error
G28 U
Error: in file macro, line 11 column 5: 'else' did not follow 'if'
Error: Homing failed

Please try the new binary at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.

dc42

@gtj0 said in RepRapFirmware 3.01-beta 3 released:

@dc42 Apparently you and @chrishamm aren't on speaking terms because the DSF doesn't get the current axis coordinates with the latest 3.01betas.

Which DSF version are you using?

Does M408 S2 report the correct coordinates?

Ntrack

@dc42 said in RepRapFirmware 3.01-beta 3 released:

@Ntrack said in RepRapFirmware 3.01-beta 3 released:

Running latest beta (3+1) on duet wifi I get an error
G28 U
Error: in file macro, line 11 column 5: 'else' did not follow 'if'
Error: Homing failed

Please try the new binary at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.

Just reinstalled the latest firmware for duet wifi .Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.01-beta3+1 (2020-01-30b1) . The issue is still present .

dc42

@Ntrack said in RepRapFirmware 3.01-beta 3 released:

Just reinstalled the latest firmware for duet wifi .Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.01-beta3+1 (2020-01-30b1) . The issue is still present .

Thanks, I will look into it.

gtj0

@dc42 said in RepRapFirmware 3.01-beta 3 released:

@gtj0 said in RepRapFirmware 3.01-beta 3 released:

@dc42 Apparently you and @chrishamm aren't on speaking terms because the DSF doesn't get the current axis coordinates with the latest 3.01betas.

Which DSF version are you using?

1.2.4.0 which is also the last commit pushed to github

Does M408 S2 report the correct coordinates?

It depends...
The toolhead is in the printable area (not at an endstop or home)

"xyz":[-130.000,-125.000,0.000],"machine":[0.000,0.000,0.000],

xys is correct but the machine coordinates are always 0.

From the DSF...
move.axes.drives[0].machinePosition always shows 0.000 but...
move.drives[0].position is correct at -130.
I have no idea what the difference between move.axes.drives and move.drives is.

dc42

Thanks, it looks like machinePosition is not being updated. I will investigate it.

dc42

@dc42 said in RepRapFirmware 3.01-beta 3 released:

@Ntrack said in RepRapFirmware 3.01-beta 3 released:

Just reinstalled the latest firmware for duet wifi .Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.01-beta3+1 (2020-01-30b1) . The issue is still present .

Thanks, I will look into it.

I'm sorry, I can't reproduce that. I don't have an MMU, so I had to modify your file to try to cover all possibilities. Can you produce the same error using a similar file that doesn't refer to any object model variables?

PS - please also check whether the same issue occurs on the 3.01-beta3+1 (2020-01-31b2) build, now in the same location.

dc42

@dc42 said in RepRapFirmware 3.01-beta 3 released:

Thanks, it looks like machinePosition is not being updated. I will investigate it.

Fixed in latest build on dropbox, 3.01-beta3+1 (2020-01-31b2) .

Ntrack

@dc42 It seems to be fixed now on 3.01-beta3+1 (2020-01-31b2) . Thank you.

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.