New stable firmware bundle 3.2 released
-
@Tapetenhobel not really a v3.2 problem, or is it?
I think you are looking for the new API when running in "SBC mode" with DuetSoftwareFramework:
https://github.com/Duet3D/DuetSoftwareFramework#get-machinestatus -
@amjm22 How are you updating? If using the SBC you should be using sudo apt update/upgrade method.
-
@Phaedrux - sudo apt update/upgrade. I did that, I'm still on Duet Web Control 3.1.1
Thanks for your reply
-
@amjm22 I did again and it worked! unreal
-
@resam
Cool, thanks
-
This post is deleted! -
Will DSF ever reach feature parity with RRF?
I remember that early in the 3x series, there was a push to get DSF at the same level of functionality as RRF, and while the version numbers now match, the supported feature set doesn't.
It's confusing that "version 3.2" means different things depending on if a SBC is being used or not, and those differences don't appear to be documented anywhere. (If they are, please point me to that document so I can read about any other differences before they surprise me.)
As an example (and asked about in the DSF section), conditional gcode functions (https://duet3d.dozuki.com/Wiki/GCode_Meta_Commands#Section_Functions) don't seem to be implemented in DSF 3.2, but have been supported in RRF for almost a year now (at least since version 3.1.)
-
@garyd9 said in New stable firmware bundle 3.2 released:
and while the version numbers now match, the supported feature set doesn't.
this was a demand from other users that had issues with having to keep up with using dsf version x, rrf version y and dwc version z - and nothing to do with reflecting features.
conditional gcode functions
which ones are you finding not working, i think the majority has been working for a while at least
-
@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.)
-
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
floorThat 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?"
"I'm not saying that you are wrong - I'm just trying to fit it into my real world simulated experience."
-
Small bug, or user error?
Renaming the Duet3_SDiap32_Minip5plus.bin file to Duet3_SDiap_Minip5plus.bin works.
-
user error. that file should have been on the original sd card.
that file is required for the next firmware update
-
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.
-
that look like the content for the duet 2 not the mini 5+
-
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. -
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
-
that sounds like a bltouch problem with the wiring
-
ok i will check thx
-
@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.
-
@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.
