New stable firmware bundle 3.2 released

ErwinH78

is there a known problem with the bl touch after the update? my bl touch sometimes doesn't work. sometimes during homing, sometimes during true bed leveling and the z-axis then crashes into the nozzle

Veti

@ErwinH78

that sounds like a bltouch problem with the wiring

ErwinH78

ok i will check thx

Phaedrux

@DaBit said in New stable firmware bundle 3.2 released:

As a side note: may I suggest putting M550 P"Duet3D" / M552 P0.0.0.0 S1 / M586 P0 S1 in the config of the Ethernet-version as-delivered?
That way the board is accessible on the network out of the box using http://duet3d.local on a regular home network setup. Saves all the initial terminal hassle; since DWC is accessible it is easy to do the config upload from there. A bit more userfriendly.

You've got an early production run of the mini. 3.2 final wasn't out yet so they have 3.2beta2. The next run should have 3.2 final I think. As for the M550 out of the box I asked for that too and was told that future SD cards won't actually have a stock config on them at all, instead you'll be directly to the config tool to generate a bespoke config.

I've also asked that the config tool include the required IAP files when you've selected to include the firmware files in your config package. Renaming the IAP file worked in this case because nothing actually changed between the renaming for the mini5. Normally renaming the IAP file won't work because it's not usually the same file at all. For future updates you'll need the SDiap32 file and to go back to older firmware versions you'd need the non-32 version.

chrishamm

@garyd9 said in New stable firmware bundle 3.2 released:

Try the following gcode in a macro using the duet3+SBC on RRF/DSF 3.2 (or 3.1.1):

echo "debug " ^ abs(3)

The same thing works with standalone RRF 3.2 (and RRF 3.1.1.)

Thanks for pointing this out, it looks like DSF interprets the round braces as a comment. You can work-around this problem by putting the whole echo payload into curly braces like

echo {"debug " ^ abs(3)}

I'll fix this in the next build.

garyd9

@chrishamm said in New stable firmware bundle 3.2 released:

@garyd9 said in New stable firmware bundle 3.2 released:

Try the following gcode in a macro using the duet3+SBC on RRF/DSF 3.2 (or 3.1.1):

echo "debug " ^ abs(3)

Thanks for pointing this out, it looks like DSF interprets the round braces as a comment. You can work-around this problem by putting the whole echo payload into curly braces like

echo {"debug " ^ abs(3)}

Thank you. Please be aware that the following gcode also doesn't work (which is similar to your suggestion):

if {abs(move.calibration.final.deviation - move.calibration.initial.deviation)} < 0.005
		break;

(I'll try your suggestion above when I'm near my printer again.)

chrishamm

@garyd9 Thanks, that seems to be a different issue. The workaround for that one looks like this:

if {abs({move.calibration.final.deviation - move.calibration.initial.deviation}) < 0.005}
	break

I'll fix it too.

dc42

@chrishamm said in New stable firmware bundle 3.2 released:

if {abs({move.calibration.final.deviation - move.calibration.initial.deviation}) < 0.005} break

For reference, when everything is working as intended, this form ought to work too when the printer is in FFF mode:

if abs(move.calibration.final.deviation - move.calibration.initial.deviation) < 0.005
	break

This is because round brackets are not treated as enclosing comments in FFF mode. Whereas in CNC mode, if you need to use ( ) in an expression then you must always have { } outside that expression.

garyd9

@chrishamm said in New stable firmware bundle 3.2 released:

if {abs({move.calibration.final.deviation - move.calibration.initial.deviation}) < 0.005}
	break

Thank you. The work-around seems to work.

On a side note, can you tell me where in the DSF source that the conditional gcode function are parsed? My reason for asking is that I grep'd the DSF source tree trying to find the strings for some functions ("atan", "degrees", "radians", etc) but came up with no results. (grep -ri radians *)

Being that 'echo {radians(10)}' actually does work, however, perhaps DSF doesn't actually parse the gcode but instead passes it to RRF?

Thank you
Gary

chrishamm

@garyd9 It only evaluates properties from the DSF object model that have the LinuxProperty attribute. This is done in Model/Expressions.cs and I think I will need to add a fix for round braces to that file. When those expressions have been replaced, the remaining term is sent to RRF for final evaluation.