DuetLapse3

war4peace

Confusion cleared.

Later Edit I apologize, I was busy at the moment and now realized my answer was too brief.
As I had said, „I am now going through the manual for StartDuetLapse and will adjust accordingly.” Which I did, used the "args=" parameter as specified in the manual and everything is in order now.

stuartofmt

@war4peace said in DuetLapse3:

everything is in order now

Excellent !! I do have a newer version of start DuetLapse3 coming out in a couple of days. Minor tweaks and corrections. Nothing that will cause a change in arguments or setup. A simple file replacement.

stuartofmt

Its been a while -- I've made updates to both DuetLapse3 and startDuetLapse3.
Included in the documentation are instructions on using DuetLapse3 with the Pi camera on Buster.

Version 3.5.0

Remember to keep DuetLapse3 and startDuetLapse3 at the same release levels

Changes to DuelLApse3

[1] Changed some system calls to allow for better error handling.
[2] Fixed an issue with sending gcodes to SBC
[3] Improved the handling of -pause yes and - movehead
[4] Added an optional argument -rest that delays image capture after a pause. This is because the camera feed can be delayed with respect to the actual head position.
[5] Updated documentation with additional notes
[6] Deprecated the use of -camera pi due to changes in Raspberry Pi (see notes in the section on -camera).
[7] Added a new argument -nolog and deprecated -logtype. Logging will always use the console unless the program is running in the background.
[8] If -verbose is used, much more detail is created. Should usually only be used for debugging.
[9] Added new argument -fps. Sets the default frames-per-seconds
[10] Added the ability to change the default frames-per-second (fps) from the main menu.
[11] Added a new argument -hidebuttons. Hides menu buttons that are currently invalid. Otherwise, invalid buttons are greyed out.
[12] General UI improvements.
[13] After Snapshot, returns to the previous logical state either 'start' or 'pause'

Changes to startDuetLapse3

[1] Changed some system calls to allow for better error handling
[2] Updated documentation with additional notes
[3] Added a default logfile (startDuetLapse3.log)
[4] Added a new argument -nolog. Logging will always use the console unless the program is running in the background.
[5] Added a new argument -verbose. Creates detailed debugging information.
[6] Failure to start DuetLapse3 (from the UI) is reported with reasons. Successful starts are reported after 30 seconds.
[7] Shutdown, from the UI, requires confirmation.
[8] The use of http option nohup=yes is deprecated.
[9] Added new argument -fps. Sets the default frames-per-seconds
[10] Added the ability to change the default frames-per-second (fps) when creating a video from the files menu.
[11] General UI improvements.

stuartofmt

I am please to announce the release of version 4.0.0

It has a number of changes, the most significant being the ability to control DuetLapse3 with gcode.

Controlling DuetLapse3 with gcode

The program, among other things, monitors messages generated with the gcode M117 command.
Two message forms will cause the program to react.

[1] M117 DuetLapse3.(x) where (x) is one of the allowed settings.
[2] M117 (execkey) (command) where (execkey) is a prefix specified by the -execkey option and (command) is an arbitrary command that will be sent to the OS.

M117 gcode messages can be embedded in the print file, placed in a macro, or sent from the DWC console.

Note that as a practical matter, This functionality assumes a single instance of DuetLapse3 connected to a single printer.

DuetLapse3 uses a polling method and checks the printer every 5 seconds for M117 messages.<br>
To prevent a message being missed, IT IS MANDATORY that a delay (G4) be added after every M117 message intended for this program.
The strong recommendation is that the delay is 10 seconds i.e. G4 S10

M117 DuetLapse3.(x)

In the first form, the following settings are available:
start, standby, pause, continue, restart, snapshot, completed, graceful, forced

These correspond to the same actions in the UI.<br>
Note that terminate is not supported instead use graceful or forced depending on your need.

There is also a special variant which can be used to change options on-the-fly.
This is equivalent to setting an option in the command line at startup.

M117 DuetLapse3.change.(variable)=(value)
G4 S10

The following variables are supported:<br>
verbose, seconds, poll, detect, dontwait, pause, restart, novideo, keepfiles, minvideo, extratime, fps, rest , execkey

Examples

M117 DuetLapse3.standby # Will place the program into standby
G4 S10

M117 DuetLapse3.start # Will start capturing image
G4 S10

M117 DuetLapse3.change.verbose=False #  will turn of verbose output
G4 S10

M117 DuetLapse3.change.seconds=20 # Will capture an image every 20 seconds
G4 S10

M117 (execkey) (command)

This form allows an arbitrary command to be executed by the operating system.
The character sequence specified by -execkey is used to identify the command.

For example if -execkey was :do: the following message will attempt to run test.sh

M117 DuetLapse3 :do: ./test.sh "hello world"
G4 S10

Note: There are no additional single or double quotes used in the M117 gcode.
The command portion is presented as it would be from the command line of the relevant OS.

Test Example

This example demonstrates controlling DuetLapse3 using M117 messages.
It does not print anything but simulates a small print job.
DuetLapse3. messages are both inline (in the gcode) and called inside a macro.

Copy the following file to your printer job folder:

M117Test.gcode

and this file to the macro folder:

test_job_settings.g

Optionally (Linux only) create a file test.sh in the DuetLapse3 directory.

#!/bin/bash
echo "-----------"
echo "$1 $2"
echo "----------"

Don't forget to make the file executable:

chmod + x ./test.sh

Start DuetLapse3 with the following suggested options, in addition to those needed for -duet and -camera:
-restart -verbose -standby -keepfiles

Note

[1] The use of M117 DuetLapse3.standby early in the print job (in the macro) to prepare for capture.
[2] The use of M117 DuetLapse3.start to control when capture will start.
[3] The use of M117 DuetLapse3.complated to indicate when capture will stop.

Placement of these options allows fine control over the timelapse. This is especially useful if -restart is used and DuetLapse3 is running continuously.

Macros can be especially useful if running DuetLapse3 continuously.
You could (for example) having a standard set of options that are called at the end of each print job and specific macros (layer only, layer and time, time only, different -second settings etc.) for certain type of timelapse.
Embedding these macro calls from your slicer makes easy use of this functionality.

stuartofmt

###VERSION 4.0.0
[1] Added the ability to control the program with gcode M117 messages
[2] Added the ability to execute an arbitrary program by sending M117 gcode with configurable prefix
[3] Added -restart option to allow a program to continue running at end of print
[4] Significantly improved ability to continue running after extended network interruptions.
[5] Can continue to run even if printer is turned off
[6] Changed - extratime handling so as not to require tpad support in ffmpeg
[7] Added -minvideo option to set minimum video length (seconds default 5)
[8] Changed default -poll to minimum of 12 seconds.
[9] Changed default -seconds to minimum of 12 seconds.
[10] Suppressed a lot of output unless -verbose is used
[11] Changed logfile naming convention to better support - restart.
Initially the logfile is created with a timestamp. When the print starts the logfile is renamed to reflect the name of the print job

The latest versions can be downloaded from here:

DuetLapse3.py

startDuetLapse3.py

JohnOCFII

@stuartofmt Glad to see work continue on this very useful tool!

stuartofmt

@johnocfii Hope you like the new additions. My intent was to allow fairly precise control and at the same time provide the option to have DuetLapse3 run continuously between print jobs.
Any and all feedback greatly appreciated.

stuartofmt

This post is just to illustrate the sort of flexibility and control that DuetLapse3 V4.0 provides.

Usually, when I print, I like to use a combination of layer changes and time to capture images. This makes the position of the printhead somewhat ambiguous at the end of the print job.
I also lower the print bed at the end of the print job.
For timelapse, I want the print head out of the way for the last image capture and I do not want any of the lowering etc.

Here is what I want it to look like:
Benchy.mp4

The following skeletal gcode illustrates one way of achieving this:

; This is the Start G-code
;  Call macro that puts DuetLapse3 into standby and sets the desired parameters
;  Among which seconds=20 and detect=layer and extratime=4
;
;M98 P"/macros/timelapse_layer_20sec.g"
;
;<snip> Pre-print gcode
;
M117 DuetLapse3.start  ; starts both layer and seconds capture just as the real print starts
G4 S10
;
; End of start G-code
;
;<snip>  The actual print gcode
;
; This is the End-gcode
;
G91           ; Use relative mode
G0 Z1         ;E Move the bed away a little note use of E after comment for correct layer count
G90           ;Back to absolute mode
G0 X0 Y0      ;Get the print head out of the way
              ;I don't do this in pause.g
;
;  This next bit is a bit sneaky - change DuetLapse to detect=pause will capture a final image when the pause is sent
;  Because we previously used G0 X0 Y0 the print head will not be in the way when the extratime images are generated
;
M117 DuetLapse3.change.detect=pause
G4 S10
;
M25          ; Don't use M226 here. DuetLapse3 sends unpause when its ready
G4 S10       ; Give pause unpause etc time to catch up
;
M117 DuetLapse3.completed  ; Stop the DuetLapse3 timelapse here
G4 S10					   ; None of the movements that may follow will be captured in the timelapse
;
; <snip>
;
M98 P"/macros/timelapse_defaults.g"  ; Reset to my normal defaults for DuetLapse3
;
M0            ; stops the print job and calls stop.g which in my case has a move to the bottom that I don't want to see
; End of End-gcode

stuartofmt

Just released V4.1.0

The main change is increase control in the DuetLapse3 UI. For many users, this will mean that the use of startDuetLapse3 can be infrequent and instead just have DuetLapse3 running all the time.

Version 4.1.0

[1] Added support for M117 DuetLapse.change.movehead=x,y
[2] Added Delete, Zip, Video in UI for completed jobs in currently running instance
[3] Suppressed long message when a client (browser) disconnects during UI update

LuniLAB

Is there any noob friendly guide to get it running...?

stuartofmt

@lunilab
I have not been active for a couple of weeks and just saw your post. What problems are you having?
The documentation is fairly comprehensive - if it needs improvement / fixing then I can help.

T3P3Tony

@stuartofmt would you be able to look into submitting DuetLapse to the plugin repository as well?
https://plugins.duet3d.com/

stuartofmt

@t3p3tony said in DuetLapse3:

@stuartofmt would you be able to look into submitting DuetLapse to the plugin repository as well?
https://plugins.duet3d.com/

I will. I have not looked at the plugin requirements. DuetLapse is written in Python, so not sure if that is an impediment.

T3P3Tony

@stuartofmt a DSF plugin can be written in python so that should be fine

stuartofmt

@t3p3tony
Ok! So the UI presented by the plugin would be the same as the current browser ui (more-or-less)? In other words the intent of the plugin would be eliminate the use of a browser UI ?
I'm trying to tease out the desired functionality. Might a simple iframe be just as effective ? Just probing here ...

T3P3Tony

@stuartofmt Thanks for the questions, its forced me to articulate my ideas better!

I visualised it as the "front end" UI elements are displayed as a plugin within DWC, similar to how other plugins are displayed. This would allow the setup of the time-lapse parameters in a GUI. As a bonus it would also display either a static image (last capture?) or a video feed of the camera (that could be something for a future version though)

The back end elements would run as a DSF "plugin" to manage the captures. It could gather any information it needs from the object model/intercept gcode using the DSF API. It could use the DSF API to manage the printer during the capture (either directly by sending the gcode movement and dwell commands, or by calling the a macro).

What do you think about the idea?

stuartofmt

@t3p3tony
I'm wondering whether the main intent might be to use the plugin framework as a convenient means of installation?

Given that DWC is browser based and the DuetLapse UI is also browser based (albeit ugly) - is there added utility having a UI within a UI compared to just having DuetLapse in a separate browser tab?. I'm not asking this to be difficult - just to better understand the ask.

For example - in DWC --> Settings --> General --> Webcam if you put in the URL for DuetLapse. You will get the Duetlapse UI by clicking the Webcam link in DWC. Is this the general sort of behavior you envisage?

Regarding the use of DSF API -- I do not know what the added benefit would be (remember - I've not looked yet). DuetLapse already interrogates the object model and sends gcode (using http). Maintaining and testing two different interfaces would need to be offset by some material advantage.

I had not thought about Duetlapse displaying the last captured image. I usually use videostream to broker images and have a link to that in my DWC. There is certainly utility in incorporating an image display function into DuetLapse - it should be straightforward enough.

T3P3Tony

@stuartofmt Yes they main point from the front end is it brings it into the structure of plugins which ease installation (and potentially discovery by users, once the plugin repository is more used). In addition alerting users to updates through the plugin system would be available once that feature is implemented.

The back end side of things could stay with the http API. In some ways that's more flexible as you could then run it on a Pi, without having a duet 3 in the mix. The biggest advantage of using what you have is of course that it already exists. In the long run using a DSF "plugin" for the backend instead will hopefully also ease installation and updating. It will potentially also allow for the plugin directly managing the gcode stream with nothing inserted form the slicer (using gcode interception to spot layer changes for example, carrying out some user defined functions, and then allowing the print to continue).

All that said, the most immediate benefit appears to be with a DWC plugin for the UI to ease installation and discovery.

stuartofmt

@t3p3tony said in DuetLapse3:

@stuartofmt Yes they main point from the front end is it brings it into the structure of plugins ......

Can you point me to a "step by step" document / example? I've searched and searched but all I seem to find is descriptions of folder structures within a zip file, or git references that are just source code. I get that bit (more or less).

What's missing for me is a clear explanation of what goes in which folder, how those components need to be structured (internally) , and the structure (and switch meaning) for the main config file. Especially: what is the mechanism for linking to the http interface.

I've made some interim changes to my code to support the idea of its own configuration file (previously all cmd line). I need to understand what other changes may be needed.

Thx in advance.

chrishamm

@stuartofmt You can find current documentation about plugins here:

for DSF: https://github.com/Duet3D/DuetSoftwareFramework/wiki/Third-Party-Plugins
for DWC: https://github.com/Duet3D/DuetWebControl/wiki/Third-Party-Plugins
There is an automated build script for DWC plugins as well, it should be described in the second link, too.

DWC is being heavily changed at the moment but as a general starting point I suggest you read through these two articles and have a look at either the endstops plugin or the motion webcam server plugins. In both repos you can find a short README section explaining how they can be built.