Posts made by chrishamm

@adhanabal M568 P0 S0 R0 where P0 means the first tool (T0). You can put it in your config.g after your M563 codes.

@Hernicz I agree that it would be better to start unloading only as soon as a filament is selected and I'm going to change DWC in the next 3.6 beta. But note that for non-MMU setups, you actually need some time between unloading one filament and loading another, otherwise it would eject the filament and then load it again immediately. So I think an optional confirmation prompt between unloading and loading is necessary.

@NineMile Conditionals are not supported outside files. You should wrap it in a macro file and then invoke it using parameters.

@rero I could confirm that there is a problem in DWC preventing the correct display of updated plugin data even though it's correct in DSF. I've got a fix ready for the next DWC beta. Thanks for reporting this!

@rero The dsf-python library for v3.6 is being overhauled, because unfortunately it didn't fully adhere to the IPC protocol standard. A while ago I made a DSF plugin in C# for DSF 3.5 and that worked well with SetPluginData but I'm going to test it again to be sure.

Version 3.5.4 should work as expected, but note that I've never tested the Python set_plugin_data function myself.

@rero Are you using software version 3.5 or 3.6-beta?

@NineMile I suppose you're running your board in standalone mode? If yes, see this related issue: https://github.com/Duet3D/RepRapFirmware/issues/925 DWC cannot yet determine when a code has actually finished, so it assumes the last code has finished once it receives a new reply. In SBC mode, you should only get back a reply of the requested code as soon as it finishes, but not before.

chrishamm created this issue in Duet3D/RepRapFirmware

open Return full code reply via HTTP rr_reply code for corresponding rr_gcode calls #925

@St-Taw You've got a mistake in there, it should be

echo "move.axes[0].babystep=",move.axes[0].babystep

PS: You probably want move.axes[2].babystep for Z.

@rero In SBC mode, it doesn't really make sense to use global variables to store SBC-specific data in the object model. Instead, consider defining a custom JSON object in the plugin.json manifest of your new plugin and define it using the data property:

{
  ...
  "data": {
    "myVal": 123
  }
}

and update it using the SetPluginData IPC command:

conn/set_plugin_data("myVal", 456, <plugin ID if plugin is not started by DSF>)

Then you can access it using plugins.<plugin ID>.data.myVal in meta G-code expressions.

See also https://github.com/Duet3D/DuetSoftwareFramework/wiki/Third-Party-Plugins

@AlexKid Thanks for your config file, I could reproduce it here and I believe I found DWC settings that prevent this problem. Can you please try to change the following values on the Settings -> Machine-Specific page and check if DWC remains stable then?

• Communication -> Maximum number of AJAX retries: 3
• Communication -> Time to wait between AJAX retries (in ms): 250

If that fixes it for you, too, I will change the default DWC settings in the next version.

PS: You could also try to increase the PanelDue BAUD rate from 57600 to 115200. That way, data can be sent to PanelDue quicker which could result in better network performance, too.

In addition to the latest software bundle 3.5.4 I am pleased to announce the availability of our next DuetPi image version, which is based on Debian Bookworm. This build comes with software version 3.5.4 and it includes a new Wayland compositor (labwc) which was introduced by the official Raspberry Pi image earlier this month. At first glance, this desktop compositor seems a bit faster than the previous one and it appears to fix support for the official RPi 7'' display when operated with a RPi 3.

You can find our latest 32- and 64-bit builds here: https://github.com/Duet3D/DuetPi/releases/tag/bookworm-2024-11-27 Alternatively, you can download and install them using the official Raspberry Pi Imager tool via Choose OS -> Other specific-purpose OS -> 3D printing -> DuetPi.

For easy remote management, the relatively new Raspberry Pi Connect software might be of interest, too.

@miguel_lopez In standalone mode, you could also use UART which is available on the io0 port (e.g. using an Arduino or similar). Extrusion control comes down to plain G1 E1 commands. If you are looking for a demo, see the pendant controller firmware here: https://github.com/Duet3D/CNC-Pendant-Firmware That is used for axes, but could be changed for extruders as well.

In SBC mode, you can either use the /opt/dsf/bin/CodeConsole utility to send commands to RRF or write your own .NET or Python plugin which reads data from other available RPi pins.

Alternatively, you can send G1 commands using the web interface (HTTP API), via Telnet, or via USB. It's really up to you.

Note that there is no "start extrusion" and "stop extrusion" functionality, so you probably need to send G1 E commands in given intervals while extrusion is supposed to happen.

@GeneRisi The web interface only displays information from the object model. Is it move.extruders[].position that you are looking for?

@Ant1 state.messageBox isn't a live key (f flag), so it is omitted. Perhaps better use v instead of f in the M409 flags and check again.

@NineMile Thanks for reporting this, it looks like G69 does not notify DSF/DWC about a change in the move key. We're going to fix this in the next versions.

@AlexKid Can you please share your config file, too? You might find that increasing the number of AJAX retries in the DWC settings helps.

@Alex There were some compatibility issues between the old and new configtool but that's fixed now. On the start page you should be able to click "Load config template" and then load your config.json.

@Surgikill Not without a DWC plugin or a custom fork.

@lazy_mosquito I just fixed the SPI port selection.

@wschadow Thanks for reporting this. I've got a bug fix tested and working. Version 3.5 is not affected.