New stable firmware bundle 3.2 released

garyd9

@bearer said in New stable firmware bundle 3.2 released:

@garyd9 said in New stable firmware bundle 3.2 released:

conditional gcode functions

which ones are you finding not working, i think the majority has been working for a while at least

None of them appear to be implemented. I've only tried "abs", "min", and "max" in my own gcode (and then had to rewrite some stuff to not use them), but then I searched the DSF code for other function names (via github's search) and found nothing. From an earlier post I made, I specifically searched for the strings "atan2", "acos", and "radians" with no results.

Here's the other thread I mentioned: https://forum.duet3d.com/topic/20852/conditional-gcode-with-dsf-3-2-error-works-standalone/4

(Note that I used the search facility built into github which is lacking to begin with.)

garyd9

Grepping the actual source (cd DuetSoftwareFramework/src, grep -ri token *) shows the same (non-)results as github searching. I also checked for some other function names via grep with no hits:

radians
sqrt
atan
degrees
floor

That said, it's possible they are implemented, but somehow without actually including the strings that are implemented. Of course, if they ARE implemented, then it's a bug that they don't actually work.

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.)

I do think it's important to point out that I'm not exactly complaining that they aren't implemented. I'm only asking when feature parity will be reached (or if it's even being attempted.)

Over the past week or so, I've been trying to migrate to "try out" using the SBC, but it's been a series of disappointments finding that things that work fine with standalone don't with the SBC (and those things aren't documented to be non-functional.)

Before I started, I asked on the forum what limitations I might run into and was pointed to a document here: https://duet3d.dozuki.com/Wiki/Duet_3_firmware_configuration_limitations

That was a good generic answer, but if you check the document, it's not only out of date, it doesn't mentioned any differences between running RRF and running RRF+DSF.

I'd submit new wiki pages describing the differences to future people who might embark on the same journey as I am, but doing that requires factual information. For example: It would be useful to mention if feature parity between DSF and RRF is planned or not. That brings me back to the my question of: "Will DSF ever reach feature parity with RRF?"

DaBit

Small bug, or user error?

Renaming the Duet3_SDiap32_Minip5plus.bin file to Duet3_SDiap_Minip5plus.bin works.

Veti

user error. that file should have been on the original sd card.

that file is required for the next firmware update

DaBit

Before powering the (Mini 5+) board the first time I took out the SD card, inserted it into the PC, renamed the original sys/ directory to sys.original/, copied it's contents into a fresh sys/ and then copied an RRF-configurator generated set into sys/ over the existing files.

There is no Duet3_SDiap_Mini5plus.bin file in the original sys/ ...

Firmware upgrade was done by uploading Duet2and3Firmware-3.2.zip. This initially failed on the missing file, so I renamed the Duet3_SDiap32_Mini5plus.bin and entered M997 S0 manually to perform the upgrade.

This works, I am running 3.2 (2021-01-05) now.

Veti

that look like the content for the duet 2 not the mini 5+

DaBit

The contents are coming from the 8GB Sandisk Edge SD-card that was inserted in the board when it arrived. As-delivered the firmware was RRF 3.2-beta (2?), same for DWC; that was a 3.2 beta too.

Maybe someone swapped cards or images, although the default contents of config.g mention Duet 3 Mini 5+. There is no image on the card for use with a Pi either, but I am not sure if it should have been on it with the Mini 5+.

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.

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.