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! 
Concrete printer and knife follower have definitely been a topic here. Usually they get controlled with an extra axis which gets positional movement instructions from the slicer / gcode directly (instead of trying to calculate it on the fly). See https://forum.duet3d.com/topic/6993/requests-for-help-gcode-cam-follower-tangential-knife-control
Hi all,
I just pushed a PR to the Cura GitHub project: https://github.com/Ultimaker/Cura/pull/4273/, which adds a new post-processing script to insert a M226 pause at a specified height. I think I posted the snippet on the forum a while ago as well, so now I want to integrate it directly with Cura.
Would be nice if anyone could give it a try, and maybe leave a on the PR - if it works for you!
@oliof throwing my plugin https://github.com/Kriechi/Cura-DuetRRFPlugin/ into the mix as a well-known and popular Duet RRF plugin for Cura.
@dc42 would you mind pointing me towards a spec on how PanelDue wants to read the QOI data from the gcode file? Or is this yet to be defined?
I believe I have a working Cura integration that takes a 320x240 snapshot of the scene, encodes it as QOI, and puts it at the beginning of the gcode file before uploading it.
@dc42 just let me know where or how you want to parse it: special M-code? magic comment?
@bot let's make sure we keep in sync what SuperSlicer/PrusaSlicer and the Cura plugin are doing.
As long we are consistent, things work (or break) all in the same way.
I'm now running 3.4RC1 on my Duet2Wifi with SBC.
This input file generated by Cura with the Cura-DuetRRF plugin:
CFFFP_Dont_Panic.gcode
Causes M36 to fail with an error, and the SBC throws an exception:
[debug] Waiting for execution of M36 "CFFFP_Dont_Panic.gcode"
[debug] Processing M36 "CFFFP_Dont_Panic.gcode"
[debug] Found Prusa Slicer QOI Image
[debug] Failed to return file information
DuetControlServer.Files.ImageProcessing.ImageProcessingException: Exception of type 'DuetControlServer.Files.ImageProcessing.ImageProcessingException' was thrown.
at DuetControlServer.Files.ImageProcessing.PrusaSlicerImageParser.ProcessAsync(StreamReader reader, CodeParserBuffer codeParserBuffer, GCodeFileInfo parsedFileInfo, Code code, Boolean readThumbnailContent, ThumbnailInfoFormat format) in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/Files/ImageProcessing/PrusaSlicerImageParser.cs:line 77
at DuetControlServer.Files.InfoParser.ParseThumbnails(StreamReader reader, Code code, CodeParserBuffer codeParserBuffer, GCodeFileInfo parsedFileInfo, Boolean readThumbnailContent) in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/Files/InfoParser.cs:line 538
at DuetControlServer.Files.InfoParser.ParseHeader(StreamReader reader, Boolean readThumbnailContent, GCodeFileInfo partialFileInfo) in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/Files/InfoParser.cs:line 105
at DuetControlServer.Files.InfoParser.Parse(String fileName, Boolean readThumbnailContent) in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/Files/InfoParser.cs:line 51
at DuetControlServer.Codes.MCodes.Process(Code code) in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/Codes/MCodes.cs:line 363
[debug] Waiting for finish of M36 "CFFFP_Dont_Panic.gcode" => {"err":1}
[debug] Completed M36 "CFFFP_Dont_Panic.gcode" => {"err":1}
I believe this is due to the incorrect thumbnail end tag parsing at https://github.com/Duet3D/DuetSoftwareFramework/blob/v3.4-dev/src/DuetControlServer/Files/ImageProcessing/PrusaSlicerImageParser.cs#L80.
The correct end tag is the same as the beginning tag: thumbnail_QOI begin and thumbnail_QOI end
See RRF change here: https://github.com/Duet3D/RepRapFirmware/commit/2f5da09e7dda9b8c95fffb572ce9a2c202b06673
Also nitpick: It identifies the thumbnail as "Prusa Slicer QOI Image", while this gcode file was generated with Cura (which doesn't matter either way, so I suggest renaming the DCS source code classes to a generic name and changing the log output).
@chrishamm I've sent a PR with both changes and included a new unit test for QOI thumbnails:
https://github.com/Duet3D/DuetSoftwareFramework/pull/179
It might be related to your CNC config - since you don't have a tool / extruder / hotend defined, this condition might kick in and hide all macros:
https://github.com/Duet3D/PanelDueFirmware/blob/master/src/UserInterface.cpp#L2421
just to confirm, can you try and define a dummy tool - I think the macros should show up then.
Of course as luck will have it, I cannot reproduce it anymore.
So take my report from above as tainted - might have been a race condition or something else. ¯_(ツ)_/¯
I just published v0.0.19 - I would appreciate feedback.
https://github.com/Kriechi/Cura-DuetRRFPlugin/releases
I'm also trying to push the plugin into the new Cura Toolbox - stay tuned for that!
@chrishamm coming back to one of the earlier issues here, something for the DWC wishlist:
Would it be possible to make the Z-Probe box reflect the actual probe type?
Currently DWC always displays the 0-1000 analog reading, which might be confusing for people with digital/switch-type probes.
So, if its an analog type P1, P2, and P3 (?), then show the value 0-1000, as currently implemented.
But if it is a switch-type / digital, P4 through P9, then just show "triggered" and "untriggered" - accounting for the invert-flag.
Motor-stall detection P10 could be considered as P4-P9, or with "not stalled" and "stalled" strings.
One caveat: some people (including myself), reconfigure the probe type with multiple M558 commands in config.g and homez.g and various macros. To simplify things, I would suggest to only retrieve the probe type after booting (DWC connecting). Unless you think continuously querying M558 is reasonable (in non-printing states)?
