RepRapFirmware 3.01-beta 3 released

dc42

@tekkydave said in RepRapFirmware 3.01-beta 3 released:

Ok, thanks. I don't want to see fans 0-2 so I'll just delete the 3 M950 commands.
Presumably this doesn't apply to fans on the duex.

Yes, only use M950 to create fans you only want to use. Bear in mind that Fan 0 is the default print cooling fan; but in RRF3, Fan 0 can be on the DueX if you wish.

tekkydave

@dc42 said in RepRapFirmware 3.01-beta 3 released:

@tekkydave said in RepRapFirmware 3.01-beta 3 released:

Ok, thanks. I don't want to see fans 0-2 so I'll just delete the 3 M950 commands.
Presumably this doesn't apply to fans on the duex.

Yes, only use M950 to create fans you only want to use. Bear in mind that Fan 0 is the default print cooling fan; but in RRF3, Fan 0 can be on the DueX if you wish.

I have my part cooling fans on the Duet as they are 24V (Vin = 24V). The other fans are all 12V so connected to the Duex. It's handy to have the option of 12 or 24V for fans that the Duex gives.

smoki3

Hi,
I tried the new meta commands the first time but run in some error message:

M98 P"0:/macros/test"
Error: in file macro, line 5 column 5: 'elif' did not follow 'if

The macro is a simple test:

if state.currentTool = 0
	M106 P9 S0.10
elif state.currentTool = 1
	M106 P9 S0.20
elif state.currentTool = 2
	M106 P9 S0.30
elif state.currentTool = 3
	M106 P9 S0.40

In generally it is working to the right command it issued for each tool. But every time I get the error message

dc42

I confirm this issue. It appears that when you have multiple 'elif' parts, if there are multiple 'elif' parts after the 'if' or 'elif' with the true condition, the error message is generated on the second one. So if the condition on line 1 is true, the error is generated on line 5; and if the condition on line 1 is false but the condition on line 3 is true, the error is generated on line 7.

I will fix this in the next beta.

garyd9

@dc42 said in RepRapFirmware 3.01-beta 3 released:

I confirm this issue. It appears that when you have multiple 'elif' parts, if there are multiple 'elif' parts after the 'if' or 'elif' with the true condition, the error message is generated on the second one. So if the condition on line 1 is true, the error is generated on line 5; and if the condition on line 1 is false but the condition on line 3 is true, the error is generated on line 7.

I will fix this in the next beta.

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.

smoki3

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?

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.