@rero You can find build instructions for DSF here: https://github.com/Duet3D/DuetSoftwareFramework/wiki/Build-Instructions
I just checked the build process and both DSF 3.5 and 3.6 build fine on my Windows and Linux setups. Unless you intend to make further changes in DSF, you don't need to build it, though. For the API bindings, it should suffice to pull in the dependencies from NuGet (DuetAPIClient). There are beta/rc packages available, too.
On behalf of the Duet3D team I am pleased to announce the availability of version 3.6.0-rc.1. If no more major problems show up in this release, this will form the basis of the next stable version 3.6.0.
If you are still running v3.5.4 and have not tried any v3.6 beta yet, please consider an upgrade to this version.
The RepRapFimware changelog since 3.5.4 includes 50 new features and 26 bug fixes, and there are many more in DSF and DWC.
If you upgrade, please check the release notes notes first for
This task can be simplified using the ReleaseMgr plugin, too.
Users in standalone mode can upgrade by uploading the firmware bundle from here.
Users in SBC mode may need to change to the unstable package feed before upgrading all packages (e.g. via M997 S2). Please note that M997 S2 does not work on deprecated Buster-based Debian/DuetPi images. See here in case you need to upgrade.
If you encounter any problems, please open a new thread with [3.6.0-rc.1] in the title. Positive feedback is welcome here in this thread.
@awitc The UART channel on io0 should be available no matter if the board is running in standalone or SBC mode but it has to be configured using M575 first (e.g. M575 P1 B57600 S2).
@rero I could reproduce this problem and I'm looking into it. Version 3.6.0-beta.4 does not appear to be affected.
PS: I've got a bug fix ready for the next 3.5 version.
@davidjryan I'm sorry but I can't really help with Python scripts. Here the corresponding example: https://github.com/Duet3D/dsf-python/blob/v3.6-dev/examples/custom_m_codes.py Instead of PRE you need to set the interception mode to Executed, then you should be able to inspect the results of executed G/M/T-codes. Of course that plugin needs to run on the SBC itself, you cannot intercept codes remotely without additional infrastructure. Also make sure that your user is part of the dsf group or let it run as root to avoid permission issues while developing.
You can find the source code of the CodeLogger utility here: https://github.com/Duet3D/DuetSoftwareFramework/blob/v3.5-dev/src/CodeLogger/Program.cs See the corresponding wiki -> Third-Party plugins for further details if you want to write a .NET console app.
Your commands are wrong. This works well for me:
M586.4 S"test" O2
M586 P4 H192.168.1.198 R1883 S1
Published messages from other clients come in as expected as generic messages in DWC. But it looks like there was indeed a problem using M118 P6, up to the next version M118 L6 needs to be used instead. I'm going to fix it in the next release. Example:
M118 L6 S"message" T"test"
@tonybillie The RRF object model does not hold enough information about serial SCARA setups yet, so saving the required information using the configtool isn't really possible yet. I've logged this FR here: https://github.com/Duet3D/RepRapFirmware/issues/1093
@jltx DSF is written in C#, so the official API bindings are provided as .NET (NuGet) packages. As a good start for custom codes using a C# application I'd recommend the DuetPiManagementPlugin source code. If you prefer Python, check out the links @droftarts shared.
@davidjryan That isn't quite right. DWC receives many code replies via the messages array of the object model, at least if they originate from system macros or job files. If you need results of all G-codes (e.g. also from HTTP, USB, or other channels), you should intercept executed G-codes using the IPC API. When you receive them, they should have the result property set which is what you seem to be interested in. Running /opt/dsf/bin/CodeLogger -t executed displays all executed codes, too.
@qurt You should be using DSF 3.6.0-beta.4, v3.5 does not support MQTT in SBC mode. I'm going to try MQTT support again using Mosquitto, I'm quite sure that worked when I tried it last time.
@T3P3Tony Perhaps it was the GET request, not the POST request? I'm not sure.
@rero What DSF version are you using?
@cnc65 @T3P3Tony is right. name specifies the target filename (e.g. /gcodes/foobar.gcode) and the body must contain the file content. I don't know why the generated API does not provide an extra parameter for the file content, though - it's there in the OpenAPI definition.
@taydin Please share your configtool.json file
@timschneider Do you have any more details about this bug, i.e. what G-code triggered it? Can you easily reproduce it?
@davidjryan I just implemented a change in DSF to avoid that re-racking problem.
@rero Your custom data needs to be registered using the data property and since you seem to be able to see it using the DWC OM browser, that should be alright. How are you trying to read your custom data keys?
@MaxGyver @droftarts Looks like Chromium-based browsers don't like plain http links, I replaced them again with https and that appears to fix it.
@stuartofmt It is NOT possible - or at least not safe/recommended - to use the same compiled JS chunk for multiple DWC versions. But you can target DSF 3.x.x by specifying only "sbcDsfVersion": "3".
