Hi all,
I wrote a little tool that allows me to create timelapse videos with pictures on every layer change, using a Duet controller, a Telnet connection from a Raspberry Pi (or other PC), and a webcam (to get still pictures over a URL):
https://github.com/kriechi/DuetRRF-timelapse
(see the README for more information)
Feel free to ask questions or post feature requests!
I hope somebody finds it useful!
I finally pulled all pieces together into a single project and wrote a README to have a nicely integrated filament weight sensor:
https://github.com/Kriechi/duet-plugin-filament-load-cell
It contains a DCS plugin to expose an HTTP endpoint, which returns a simple weight measurement in the style of approx. 762g filament left and displays that via a DWC plugin in the top menu bar in the browser - which makes it easy to prevent out-of-filament pauses or failed prints.
The sensor itself is based on a 1kg load cell, mounted with a small bracket to my printer frame. The load cell gets read by an HX711 chip, which gets read by an Arduino Nano, which gets read over I2C by my Raspberry Pi / Duet SBC, which gets read by the DCS & DWC plugins.
The Arduino Nano / ATmega168 firmware code is included and can be compiled & flashed via PlatformIO.
While this was pretty much a "done" project for my printer, because its working for years already, I only recently merged and refactored everything into new Duet plugins. The DWC plugin is a very simple Javascript with an XHR/XMLHttpRequest/AJAX call to the new DCS HTTP endpoint and inject the returned measurement value into a new HTML element. No complicated Vue.js trickery involved - the JS code originated from a Tampermonkey script, so it is dead simple and only a few lines!
Check out the README for more details!
Enjoy!
@dc42 Cura-DuetRRF Plugin to embed thumbnails just landed on the public Ultimaker Cura Marketplace - but due to this issue it is not yet compatible with 3.4-rc1.
So, with the next RC it should immediately work with the latest Cura plugin version v1.2.5.
v1.0.1 of the plugin is now published and available in the Cura Marketplace for Cura 3.6 and the 4.0-beta.
I'm using a Cura PostProcessing plugin to inject the following on every new layer:
M118 P4 S"LAYER CHANGE"
Then I'm using a small Python script running on a Raspberry Pi that connects via Telnet to the Duet and listens (waits and reads) for exactly that string LAYER CHANGE. Now I can pull a snapshot image (mjpg-streamer for the webcam) and save it to a jpg file:
r = requests.get('https://127.0.0.1/webcam/?action=snapshot', timeout=5, stream=True)
if r.status_code == 200:
now = datetime.datetime.now()
with open(os.path.join('images', now.strftime("%Y%m%dT%H%M%S") + ".jpg"), 'wb') as f:
for chunk in r:
f.write(chunk)
And at the end of the print, I use ffmpeg to render a timelapse movie:
ffmpeg -r 30 -y -pattern_type glob -i '*.jpg' -c:v libx264 output.mp4
Fairly simple if you know your way around a bit of Linux and Python programming.
If you use firmware retracts and z-hops, one could avoid the M118, and simple pull a snapshot image on every Z coordinate change. YMMV.
@dc42 Here the file beginning with a 320x320 QOI (about 37kB, so only the first few lines):
;FLAVOR:RepRap
;TIME:4199
;Filament used: 3.57983m
;Layer height: 0.15
;MINX:69.693
;MINY:92.957
;MINZ:0.2
;MAXX:174.818
;MAXY:152.057
;MAXZ:7.55
;POSTPROCESSED
;Generated with Cura_SteamEngine 4.12.1
;Exported with Cura-DuetRRF by Thomas Kriechbaumer 1.2.5
; thumbnail begin 320x320 37140
; cW9pZgAAAUAAAAFABAAA/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f
; 39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39
; /f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f
; 39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39
; /f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f
; 39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39
; /f39/f39/f39/f39/f39/f396P8aFQYa/4BnHYIA/f39/f3F/xoVBRr/06sw1/+DaiCnAP39/f39xP
; 8aFQYb/9auMNr/+so5//9xXBp7AP39/f39wz//06sw2P/6yzn/wP9hTxduAP39/f39wgoWKcH/OzAR
; bgD9/f39/cEK/9SsMNgpwv83LxdVAP39/f39wP85Lg06FinCnnn/EA4GNQD9/f39/f86Lw07/+y/Nf
; Apw//3yDj+/wQEBCkA/f39/fz/OzANPP/uwTbzKcT/5rs2+wD9/f39/P86Lw08AinF/8WhMfsA/f39
; /fsQ/+/BNvMpxv+7mCzQAP39/f36EP/tvzXx//vLOf/H/450JMMA7/9CNQ9D/yoiCSv/AAAAAP39/f
; 3G/zwwDT09LMj/jHIisADs/wcFAQf/RTgPRv/AnCvE//nKOP7/IhwKRwD9/f39xf9HORBI/+3ANfEs
; yf9nVBqKAOr/AwIAA/9hThZj/9WtMNkpwP7bsjT/CAgFLgD9/f39xP9pVRdq//rKOP7/+8s5/8r/Vk
; cYigDo/xANAxD/c10adf/asDHeKcL+pYct/wICAQ4A/f39/cP/aFQXav/4yTj8LMv/RjkRWADm/w8M
; Aw//emMbfP/pvDXtLMT/b10k9v8BAQELAP39/f3C/2lVF2sS//vLOf/M/x4aC1EA5P8iHAcj/5Z5Ip
; n/6r017izFnXr/Ny8YwgD9/f3L/xcTBRj/Ix0IJADxEzEszf8cFwg5AOL/HxkHH/+ZfCKc//LEN/Ys
; ... snip
; thumbnail end
T0
M190 S60
M104 S215
M109 S215
...
Latest changes pushed to https://github.com/Kriechi/Cura-DuetRRFPlugin/tree/next
M929 is currently very verbose and fills up my SD card quickly.
Just flashing out a few ideas for statistics:
printing (general stats)All counters should have a total value (persistent on SD card), and a user-resettable (i.e., via UI) "trip mileage" value. Every time I do maintenance, I would reset the trip counter, while keeping the total counter intact.
To save the SD card from early death, I suppose persisting both counters after a print job finishes / was canceled should be fine.
Ok - so here is how you can take full advantage of the pre-compile steps from DuetWebControl (skip ahead if you don't have a complex plugin):
git clone https://github.com/Duet3D/DuetWebControl.git
cd DuetWebControl
git checkout v3.3-dev
npm install
Then call a heart and blood pressure specialist doctor due to:
25 vulnerabilities (13 moderate, 12 high) and tons of this library is no longer supported messages...
Then add the following snippet to the big plugin array/list at the bottom of src/plugins/index.js to include your new plugin:
new DwcPlugin({
id: 'MyNewPluginID',
name: 'My-New-Plugin',
author: 'Thomas Kriechbaumer',
version,
loadDwcResources: () => import(
/* webpackChunkName: "MyNewPluginID" */
'./MyNewPluginID/index.js'
)
}),
Then continue with:
# still in the root dir of DuetWebControl repo
cd src/plugins/
mkdir MyNewPluginID
cd MyNewPluginID
echo 'console.log("Hello World!");' > index.js
npm run build
This will create 4 new files with MyNewPluginID.123abc.<different-extensions> under dist/js/. Copy those into your plugin ZIP file under dwc/js/.
And essentially all this can be shortened by directly doing this:
Create a ZIP file with these files:
MyNewPluginID.zip
- plugin.json
- dwc/
- js/
- MyNewPluginID.js
With plugin.json being this:
{
"id": "MyNewPluginID",
"name": "My-New-Plugin",
"author": "Thomas Kriechbaumer",
"version": "1.0.0",
"license": "MIT",
"homepage": "http://example.com",
}
(observe that I did not mention dwcFiles - it will figure itself out that there is a .js file to copy into the right place.
With MyNewPluginID.js being this:
(window["webpackJsonp"] = window["webpackJsonp"] || []).push([
["MyNewPluginID"], {
"./src/plugins/MyNewPluginID/index.js": function (e, t, n) {
"use strict";
console.log("Hello World");
// YOUR CODE HERE!
}
}
]);
Not sure if this is the best way to build new plugins, but it worked for me.
Since this post is getting rather long, let me summarize briefly and post a few bits that I haven't found here yet:
@deadwood83 has made a nice PCB nice PCB here with PCB and schematic sources in EasyEDA. It fits nicely on a Duet 2 WiFi and DuetEthernet without desoldering the existing WiFi module.
The pins on the PCB are mostly self-explanatory to hook them up to a Raspberry Pi:
(see this for a Raspberry Pi pin out table to double check)
Happy vacation! You deserve some time off! 
Thanks for the great and almost around-the-clock support! 
@chrishamm any insights into the error posted by @NikA ?
Was there a code change that I need to integrate into the Cura plugin to make it work with the latest DSF beta?
@cdoe are you running with an SBC / Raspberry Pi?
I recall similar issues with my printer when there was a lot of tiny moves due to high-fidelity / super smooth geometry that resulted in SPI data transfer queue issues.
I was able to work-around the issue by tweaking the SPI and transfer queue sizes in the DSF config.
Thanks all for questioning my setup! I now managed to get it fixed / changed in the following way:
# define Z probe
G31 X0 Y60 Z3.80 P25 # Y was -50 before
# bed leveling with left+right lead screws
G30 P0 X10 Y130 Z-99999 # Y was 20
G30 P1 X240 Y130 Z-99999 S2 # Y was 20
G28 Z
# mesh leveling
M557 X20:240 Y55:230 P9:9 # Y was -49:137
So I had to roughly add 3 x probe_offset to most positions compared to my previously (flawed) configs.
Now the visual heightmap in DWC looks reasonable.
@droftarts thanks for your response. The physical movements are correct, so I don't understand how the probe offsets would be wrong.
One thing I noticed: M557 ... Y0:137 ... actually starts probing at Y=50. So the M557 coordinates are probe coordinates. My probe is offset from the nozzle in Y by -50, see my G31 command. Thats why in my M557 I want to probe at Y=-49 to move the tool head as far forward as possible.
The generated heightmap.csv starts like this:
RepRapFirmware height map file v2 generated at 2024-08-28 18:44, min error -0.217, max error 0.199, mean 0.046, deviation 0.088
axis0,axis1,min0,max0,min1,max1,radius,spacing0,spacing1,num0,num1
X,Y,15.00,245.00,-49.00,137.00,-1.00,28.75,23.25,9,9
...
Searching through https://github.com/Duet3D/DuetWebControl/blob/v3.5-dev/src/plugins/HeightMap/HeightMap.vue and similar files, I don't see the probe offsets being used anywhere.
Is the heightmap visualization aware of probe offset?
I'm on RRF+SBC 3.5.2 on my Duet2.
I recently started again using mesh bed leveling.
I have a CoreXY gantry with the bed moving up and down.
The extruder on the XY gantry has a normal nozzle with an inductive probe mounted "behind (Y axis)" the nozzle.
config.g:
; Z probe
M558 P8 C"exp.e5stop" H3 F200:50 T7000 A3 S0.05 ; use E5_STOP as inductive-NPN probe, dual speed, multi-probe
G31 X0 Y-50 Z3.80 P25 ; Z probe: set the probe XY offset, Z height and signal threshold
; Axis dimensions
M208 X0:265 Y0:244 Z0:240 ; axis maxima
M671 X-52:306 Y113:113 S10 ; define positions of Z leadscrews
M556 S100 X0 Y0 Z0 ; axis compensation
Macro to run the mesh:
M561 ; clear any existing bed transform
G32 ; home and level
M557 X15:245 Y-49:137 P9:9 ; set probe coordinates
G29 ; detailed Z probe
After running the mesh, DWC shows me this heightmap:
(please ignore the actual shape and deviation)
My concern here is the Y shift of the bed relative to the 0,0 coordinate origin. It looks like the coordinate system is incorrect by about the same amount as the nozzle-to-probe offset.
The probing points are aligned in such a way that the inductive probe is moved to the edges of the bed as far as possible.
Is this a visual-only bug in DWC, or is the actual compensation matrix incorrectly computed and therefor also affecting the compensation during printing? How do I move my probed bed to Y=0? The actual physical movements and probing points are correct and how I want them to be.
@Phaedrux not sure why you moved this to "Beta Firmware" -- v3.5.1 is marked stable, unless the Duet2-SBC variant is officially not supported any more?
I'm running a Duet2 with SBC on the latest 3.5.1.
I uploaded a new print gcode file and started a simulation job via the SBC HTTP API. This piece of code is able to talk to SBC and direct-RRF boards using the new API and old rr_* API. It first tries the old API, which used to fail with a clear error, to then switch into "new-API" mode and try again.
In the DSF changelog I found this:
Added rr_ compatibility layer to DuetWebServer (HTTP calls in standalone mode)
This means that my code now always auto-detectes the old rr_* API, instead of switching over to the new one when available.
Now to the actual issue at hand:
Sending the following request causes the printer to actually start printing the file, instead of running a simulation job as intended by M37!
curl -vvv 'http://192.168.1.42/rr_gcode?gcode=M37%20P%220%3A%2Fgcodes%2Ftest.gcode%22'
Producing these SBC log from DWC/DSF/DCS:
May 26 12:40:56 voron DuetWebServer[634]: Microsoft.AspNetCore.Hosting.Diagnostics[1] Request starting HTTP/1.1 GET http://192.168.1.42/rr_gcode?gcode=M37%20P%220%3A%2Fgcodes%2Ftest.gcode%22 - -
May 26 12:40:56 voron DuetWebServer[634]: DuetWebServer.Singletons.SessionStorage[0] Session 2d8c1c548454408ab4a470c857aa2725 added (readWrite)
May 26 12:40:56 voron DuetWebServer[634]: Microsoft.AspNetCore.Routing.EndpointMiddleware[0] Executing endpoint 'DuetWebServer.Controllers.RepRapFirmwareController.DoCode (DuetWebServer)'
May 26 12:40:56 voron DuetWebServer[634]: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[3] Route matched with {action = "DoCode", controller = "RepRapFirmware"}.
Executing controller action with signature System.Threading.Tasks.Task`1[Microsoft.AspNetCore.Mvc.IActionResult] DoCode(System.String) on controller DuetWebServer.Controllers.RepRapFirmwareController (DuetWebServer).
May 26 12:40:56 voron DuetWebServer[634]: DuetWebServer.Controllers.RepRapFirmwareController[0] [DoCode] Executing code 'M37 P"0:/gcodes/test.gcode"'
May 26 12:40:56 voron DuetWebServer[634]: Microsoft.AspNetCore.Mvc.Infrastructure.ContentResultExecutor[1] Executing ContentResult with HTTP Response ContentType of application/json
May 26 12:40:56 voron DuetWebServer[634]: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[2] Executed action DuetWebServer.Controllers.RepRapFirmwareController.DoCode (DuetWebServer) in 104.242ms
May 26 12:40:56 voron DuetWebServer[634]: Microsoft.AspNetCore.Routing.EndpointMiddleware[1] Executed endpoint 'DuetWebServer.Controllers.RepRapFirmwareController.DoCode (DuetWebServer)'
May 26 12:40:56 voron DuetWebServer[634]: Microsoft.AspNetCore.Hosting.Diagnostics[2] Request finished HTTP/1.1 GET http://192.168.1.42/rr_gcode?gcode=M37%20P%220%3A%2Fgcodes%2Ftest.gcode%22 - - - 200 27 application/json 163.1642ms
May 26 12:40:57 voron DuetControlServer[1649]: [info] Selected file 0:/gcodes/test.gcode
May 26 12:40:57 voron DuetControlServer[1649]: [info] Starting file print
May 26 12:40:57 voron DuetControlServer[1649]: [info] Simulation mode: off, move time: 0.0 sec, other time: 0.0 sec
This just caused my printer to crash and bend it's carriage rods, before I was able to jump to the E-stop button.
I'm the author of the Cura Duet-RRF Plugin, which is using the above mentioned auto-detection code. Meaning, potentially all users of Cura running the latest RRF 3.5.1 in SBC mode and the plugin who want to simulate a job are at risk of damage due to unplanned real printing activity instead of simulation.
What's the expected behaviour in this case?
Is this a bug in the emulated rr_* API in DSF, or something else?
edit
After some more debugging, it turns out that even using the new API is causing a simulation job to be executed as real print job!
This can also easily be triggered using DWC by right-clicking on a gcode file and selecting "Simulate File", upon which it will send the correct gcode M37 but will in fact start heating the hotend and bed and start homing!
May 26 13:54:01 voron DuetWebServer[634]: Microsoft.AspNetCore.Hosting.Diagnostics[1] Request starting HTTP/1.1 POST http://192.168.1.42/machine/code application/x-www-form-urlencoded 68
May 26 13:54:01 voron DuetWebServer[634]: Microsoft.AspNetCore.Routing.EndpointMiddleware[0] Executing endpoint 'DuetWebServer.Controllers.MachineController.DoCode (DuetWebServer)'
May 26 13:54:01 voron DuetWebServer[634]: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[3] Route matched with {action = "DoCode", controller = "Machine"}. Executing controller action with signature System.Threading.Tasks.Task`1[Microsoft.AspNetCore.Mvc.IActionResult] DoCode(DuetWebServer.Singletons.ISessionStorage, Boolean) controller DuetWebServer.Controllers.MachineController (DuetWebServer).
May 26 13:54:01 voron DuetWebServer[634]: DuetWebServer.Singletons.SessionStorage[0] Session 5fbbc7e78464425b8c043dc244cf336f started a long-running request
May 26 13:54:01 voron DuetWebServer[634]: DuetWebServer.Controllers.MachineController[0] [DoCode] Executing code 'M37 P"0:/gcodes/test.gcode"'
May 26 13:54:01 voron DuetControlServer[9372]: [info] Selected file 0:/gcodes/test.gcode
May 26 13:54:01 voron DuetControlServer[9372]: [info] Starting file print
Is something wrong with my machin and setup - or was such a potentially dangerous bug not caught during testing and beta/RC releases?
@chrishamm Thanks! I installed the new package, and it updated fine - seems to work now!
@achrn not sure such a hard stance is needed here. Its perfectly fine to override this behaviour if you know what you are doing. The pip output you posted contains all instructions you need:
You can override this, at the risk of breaking your Python installation or OS,
by passing --break-system-packages.
Not pretty, I agree, but certainly an easy fix to get the package installed "the old way".
I am running an Duet2 Wifi with the SPI adapter to connect an SBC.
I tried upgrading from a working 3.4.6 setup to 3.5.1 using apt upgrade. DCS, DWC, etc. all upgraded nicely. The reprapfirmware package also updated and flashed the new firmware as expected, however, then the SPI connection to the Duet2 failed to re-establish.
After some troubleshooting, it turns out, that installing the Duet2Firmware_SBC.bin for 3.5.1 on my Duet board, it will simply crash loop the board.
DCS fails to connect with:
May 04 16:27:56 voron DuetControlServer[952]: Duet Control Server v3.5.1
May 04 16:27:56 voron DuetControlServer[952]: Written by Christian Hammacher for Duet3D
May 04 16:27:56 voron DuetControlServer[952]: Licensed under the terms of the GNU Public License Version 3
May 04 16:27:57 voron DuetControlServer[952]: [info] Settings loaded
May 04 16:27:58 voron DuetControlServer[952]: [info] Environment initialized
May 04 16:27:58 voron DuetControlServer[952]: [warn] Restarting full transfer because a bad header format code was received (0xff)
May 04 16:27:58 voron DuetControlServer[952]: [fatal] Could not connect to Duet: Timeout while waiting for transfer ready pin
May 04 16:27:58 voron systemd[1]: duetcontrolserver.service: Main process exited, code=exited, status=69/UNAVAILABLE
May 04 16:27:58 voron systemd[1]: duetcontrolserver.service: Failed with result 'exit-code'.
May 04 16:27:58 voron systemd[1]: Failed to start duetcontrolserver.service - Duet Control Server.
May 04 16:27:58 voron systemd[1]: duetcontrolserver.service: Consumed 2.409s CPU time.
Flashing back 3.4.6 via USB and bossac is recovering the device.
When working with 3.4.6 I can use USB-serial to connect to the Duet2 directly and get this output:
<CONNECTED>
RepRapFirmware for Duet 2 SBC version 3.4.6
<DISCONNECTED>
After bossac-flashing the 3.5.1 binary, the USB-serial port vanishes and re-appears about once per second. This matches the LED next to the USB port on the Duet2 briefly flashing red. I can't capture any debug output on this USB-serial console as it disappears before I can connect.
I noticed that the 3.5.1 binary is using 927 flash pages (474572 bytes), while the 3.4.6 uses only 877 pages (448900 bytes).
Is Duet2 + SBC over SPI still a supported setup?