DuetLapse3

stuartofmt

OK! Looks like V1 worked!! So you should have got a message on DWC saying "Test of SBC"

Did you see that ?

jay_s_uk

@stuartofmt
No, nothing displayed on DWC

stuartofmt

Ok - I'm going to have to get some help. The code I have seen elsewhere (including Danal's) does not work (or I've done something stupid). The one that reports success - does not seem to send the gcode .... go figure .....

So - this should work for SBC -- but not for using the pause capability (that's the only thing that sends gcodes). ~~Appreciate it if you could test before I update github~~

Hmm - wont let me upload the file to here. I'll update on github - if you would not mind downloading from there.

stuartofmt

Ok it looks like we are getting close ( thanks to an "anonymous" tip in another thread )

Can you try this please. V3 is the latest (and hopefully correct) form.

~~[SBCTEST.py]~~

stuartofmt

In order to better handle pause situations - I need to access Duet to get a previously unused set of parameters. I'll post a new test script tomorrow. If successful - then SBC should be fully supported. Stay tuned and thanks for the help.

PCR

@stuartofmt i will have acces to my SBC printer tomorrow

stuartofmt

If all y'all could try this on SBC please

~~[SBCTEST.py]~~

In particular verify that a message appears in DWC "Test of SBC"

jay_s_uk

@stuartofmt
Good news

Determine API Version
localhost Testing: rr_model at address localhost
localhost http://localhost/rr_model?key=boards
localhost
localhost Testing: /machine/system at address localhost
localhost http://localhost/machine/status
localhost
localhost API model is: SBC   Version is: 3
localhost Status is :idle
localhost Send Gcode result: None
localhost Layer: None
localhost Get Position X and Y: 160 130

bad news, no popup

stuartofmt

@jay_s_uk

Yikes on the lack of gcode being sent ... Unfortunately the API endpoint reports success - when clearly that is not the case ...

This one last bit is turning out to be frustrating ....

The code for sending the gcode (thanks for the reference) is very simple. It works perfectly for rr_model (just uses a http get) but does not seem to want to play for /machine/gcode (which according to the doc requires a post).

I've added a second slightly different syntax. I found two slightly different versions (one in DuetUI and the second in Danals DuetAPI). They are nearly identical, one has the url as .../machine/code and the other as /machine/code/ ...

If you would not mind running it .....

SBCTEST.py

jay_s_uk

@stuartofmt
no popup there either

localhost Determine API Version
localhost Testing: rr_model at address localhost
localhost http://localhost/rr_model?key=boards
localhost
localhost Testing: /machine/system at address localhost
localhost http://localhost/machine/status
localhost
localhost API model is: SBC   Version is: 3
localhost Status is :idle
localhost URL was: http://localhost/machine/code
localhost Send Gcode result: None
localhost Layer: None
localhost Get Position X and Y: 160 130
localhost URL was: http://localhost/machine/code/
localhost Send Gcode result: None

stuartofmt

@jay_s_uk

I'll go back to the DWC threads and see if there are some ideas I can try.

The good news is I've made the baseline code considerable more robust and have improved the handling of pauses (if used). But none of the pause improvements matter without the ability to send gcodes

PCR

@stuartofmt
https://github.com/Kriechi/Cura-DuetRRFPlugin/blob/master/DuetRRFOutputDevice.py

Maybe this is helpful

PCR

@stuartofmt only for history

pi@duet3:~ $ ./1610998509032-sbctest.py -duet 192.168.140.126
192.168.140.126 Determine API Version
192.168.140.126 Testing: rr_model at address 192.168.140.126
192.168.140.126 http://192.168.140.126/rr_model?key=boards
192.168.140.126
192.168.140.126 Testing: /machine/system at address 192.168.140.126
192.168.140.126 http://192.168.140.126/machine/status
192.168.140.126
192.168.140.126 API model is: SBC   Version is: 3
192.168.140.126 Status is :processing
192.168.140.126 URL was: http://192.168.140.126/machine/code
192.168.140.126 Send Gcode result: None
192.168.140.126 Layer: 3
192.168.140.126 Get Position X and Y: 96.787 119.675
192.168.140.126 URL was: http://192.168.140.126/machine/code/
192.168.140.126 Send Gcode result: None

no DWC message either

PCR

@stuartofmt I changed this line

logger.info('Send Gcode result: '+str(sendDuetGcode2(apiModel, 'M117 Test of SBC')))

to

logger.info('Send Gcode result: '+str(sendDuetGcode2(apiModel, 'M117 "Test of SBC"')))

aand

stuartofmt

@PCR said in DuetLapse3:

logger.info('Send Gcode result: '+str(sendDuetGcode2(apiModel, 'M117 "Test of SBC"')))
aand

![a02d93f9-98a1-4404-bb9a-c67b729cac68-grafik.png](/assets/uploads/files/1611049373109-a02d93f9-98a1-4404-bb9a-c67b729cac68-grafik.png)

Brilliant!.
Last night (in my slumbers) I wonderer if the data=command in the push code needed to be encoded because of the spaces in M117 etc. In the various example code it seems only single gcodes have been passed and likely why those examples worked. Dueui was a bit different but that was javascript and I'm even more unfamiliar with that than I am with Python .....
DuetLapse3 in its current form only needs to send single gcodes. So - as it stands we have a fully working DuetLapse3. The choice of M117 ... for testing turned out to be both good and bad.

What I will do today is try and crack the encoding needs so that it does not break in the future. I've set up a simple webserver and can debug the incoming and see what happens. I have not yet updated the github but either way will do so later today

@jay_s_uk and @PCR
Thanks for being the remote testers.

stuartofmt

Version 3.0.4 released in github. All functionality should now work with SBC.

The issues with SBC gcode appear to be due to differences in the way DWS was handling the test case.

stuartofmt

Version 3.1.1 released on github. This is pretty significant - the details are documented but here us a summary.

###Version 3.1.0###

[1] Added support for Windows
[2] Added automatic detection of operating system (Linux or Windows)
[3] Added integrated http listener for basic browser based control
[4] Changed file naming convention to make filenames unique if multiple instances of DuetLapse3 are running.

An Integrated http listener is available for basic control of DuetLapse3 (not the attached printer).
The http listener is activated by specifying a port number using the -port option.
In conjunction with the -host option it provides the following functionality from a browser (or curl or other method of performing a http get).

http://<ip-address><port>/?command=<valid command>

*Valid commands are:
start - Starts DuetLapse3 recording if the -stopcmd option was used or after a stop command
standby - Stops (but does not terminate) DuetLapse3 recording and discards any images capture. Waits for a start command.
status - returns brief information about the running state of DuetLapse3
pause - causes DuetLapse3 to temporarily stop capturing images
continue - causes DuetLapse3 to resume capturing images
snapshot - causes DuetLapse3 to make an interim video and then continue
restart - causes DuetLapse3 to stop capturing images, create a video and then restart with a new capture set
terminate - causes DuetLapse3 to stop capturing images, create a video and then terminate the program. This is the same as CTRL+C or SIGINT.

Note that depending on your system - it may take several minutes for the http listener to completely shutdown following a terminate request.*

Note that the http listener will stop responding if DuetLapse3 is run from a command console that is then closed. This will happen even if started in background. To avoid this - use nohup (linux).
Windows does not have an (easy) equivalent to nohup so you would need to leave the command console open. An alternative if you are on Win10 is to use Windows Subsystem for Linux (WSL) and run DuetLapse as a linux application inside WSL.
If running in nohup mode CTRL+C cannot be used so you need to send the terminate command (?command=terminate) from the http listener

Made an accommodation (in 3.1.1) for ffmpeg < 4.2 by using a simpler syntax if -extratime is not used.

stuartofmt

@fractalengineer

Take a look at the post above. It does not provide a plugin but the http listener makes it easier to control remotely. It looks like the plugins require javascript and frankly - that's not something I want to get into.
Someone else (with the skills) could create a simple plugin that calls appropriate urls and provide control that way.
I will create a helper script that proved a separate http listener to remotely start DuetLapse3 - but that's a few days away.

fractalengineer

@stuartofmt Thanks Stuart; I did try installing the 3.04 earlier this weekend following each step but got stuck at ffmpeg install; doesn't return anything when checking version.

I guess I'm still way to beginner at linux terminal. I'll try again with the new version

stuartofmt

@fractalengineer said in DuetLapse3:

@stuartofmt Thanks Stuart; I did try installing the 3.04 earlier this weekend following each step but got stuck at ffmpeg install; doesn't return anything when checking version.

I guess I'm still way to beginner at linux terminal. I'll try again with the new version

Don't worry - we will get you going.
I'm assuming you are using a raspberry pi ?

The latest version should work with the version of ffmpeg that installs by default with the pi. The only downside is not being able to use the -extratime option.

I'd recommend you reinstall the default ffmpeg and take it from there.
It sounds like you tried to follow my instructions and the installation of the latest ffmpeg failed somehow? If that is correct then lets try to clean it up and get you back to the default. Try the following in order (I just did this on my pi)

cd ~
sudo apt remove ffmpeg

I'm guessing this will say ffmpeg is not installed.

sudo find / -name ffmpeg

This will may give some output for example:)
find: ‘/run/user/1000/gvfs’: Permission denied
/usr/local/bin/ffmpeg
/usr/local/share/ffmpeg
/usr/local/share/doc/ffmpeg

for each of the files / directories - we'll first delete everything for EXAMPLE

sudo rm -rf /usr/local/bin/ffmpeg
sudo rm -rf /usr/local/share/ffmpeg
sudo rm -rf /usr/local/share/doc/ffmpeg

Next make sure everything is at the latest release level

sudo apt update
sudo apt upgrade

I just did this on my pi - it was quite the upgrade and took quite a while so be patient.

Finally, install the standard ffmpeg

sudo apt install ffmpeg

after that and assuming no errors

ffmpeg -version

should return a bunch of information.

Then reboot for luck