DuetLapse available for Alpha testing

Danal

@tekkydave said in DuetLapse available for Alpha testing:

I noticed that if you have a password set (M551 P"Password") then DuetLapse can't connect to the Duet.
Attempting to connect to printer at 192.168.1.104
http://192.168.1.104  does not appear to be a RRF2 or RRF3 printer
Device at 192.168.1.104 either did not respond or is not a Duet V2 or V3 printer.
Do you have any plans to add this feature in the future?
Cheers

I didn't but based on your feedback, I will look into it.

Danal

@UnderDoneSushi said in DuetLapse available for Alpha testing:

Would it be possible to use an old iphone as the camera?

Yes, if it runs software that will allow a still image to be retrieved via a know URL.

gtj0

HA! Just discovered another reason to use a config file if it exists... To turn off things like auto-focus.

Danal

@gtj0 said in DuetLapse available for Alpha testing:

HA! Just discovered another reason to use a config file if it exists... To turn off things like auto-focus.

Excellent point.

tekkydave

Found a solution to an issue I was having using DuetLapse with MotionEye.

I have a raspicam which is connected to a Pi3B running Motioneye.

MotionEye will allow a single image to retrieved at a URL similar to:

http://192.168.1.106:8765/picture/1/current/?_username=admin&_signature=b75e2c8efb0c0694a7a4ac1f48037f90566fbead

Using this URL with DuetLapse gives this error every time it tries to get an image

Capturing frame     0 at X65.74 Y47.41 Z0.30
http://192.168.1.106:8765/picture/1/current/?_username=admin:
2020-04-07 15:10:57 ERROR 403: Forbidden.

So I amended the following line in the onePhoto() function in DuetLapse.py

cmd = 'wget --auth-no-challenge -nv -O '+fn+' '+weburl

to

cmd = 'wget --auth-no-challenge -nv -O '+fn+' "'+weburl+'"'

to put quotes around the url. This seems to fix the problem

Danal

THANK YOU

I will update

tekkydave

Another tip if you want to play around with DuetLapse without having to set a print going.
Temporarily change

        if ('processing' in status):

to

#if ('processing' in status):
if ('M' in status):   # detect simulating instead of processing

This will make DuetLapse think the Duet is printing when it is simulating. Remember to change it back later

Maybe a -dry-run option can be added to do this in future?

Danal

I've just been starting a print, and then pause/canceling it.

Of course, it can do whatever we all agree to... and can code... and dry run is dead simple. I would note that it really only applies to -seconds. A dry run with any kind of -detect is never going to detect anything.

tekkydave

@Danal said in DuetLapse available for Alpha testing:

I've just been starting a print, and then pause/canceling it.

Of course, it can do whatever we all agree to... and can code... and dry run is dead simple. I would note that it really only applies to -seconds. A dry run with any kind of -detect is never going to detect anything.

It detects layer changes when running a simulation but, as you say, since nothing is physically moving the video is going to be a bit boring. Useful if you are testing options or trying simple code changes though. I know squat about python so I need all the help I can get. I do find your code very easy to follow though

Danal

@tekkydave said in DuetLapse available for Alpha testing:

@Danal said in DuetLapse available for Alpha testing:

I've just been starting a print, and then pause/canceling it.

Of course, it can do whatever we all agree to... and can code... and dry run is dead simple. I would note that it really only applies to -seconds. A dry run with any kind of -detect is never going to detect anything.

It detects layer changes when running a simulation but, as you say, since nothing is physically moving the video is going to be a bit boring. Useful if you are testing options or trying simple code changes though. I know squat about python so I need all the help I can get. I do find your code very easy to follow though

Thank you. I try to balance being "python-esq" with being readable. For me if nought else.

How about having the "detect printing" detect BOTH processing and simulation? Since we control if the script is running, I see very little downside to this.

tekkydave

@Danal said in DuetLapse available for Alpha testing:

@tekkydave said in DuetLapse available for Alpha testing:

@Danal said in DuetLapse available for Alpha testing:

I've just been starting a print, and then pause/canceling it.

Of course, it can do whatever we all agree to... and can code... and dry run is dead simple. I would note that it really only applies to -seconds. A dry run with any kind of -detect is never going to detect anything.

It detects layer changes when running a simulation but, as you say, since nothing is physically moving the video is going to be a bit boring. Useful if you are testing options or trying simple code changes though. I know squat about python so I need all the help I can get. I do find your code very easy to follow though

Thank you. I try to balance being "python-esq" with being readable. For me if nought else.

How about having the "detect printing" detect BOTH processing and simulation? Since we control if the script is running, I see very little downside to this.

That would be the simplest solution I think.

chas2706

@Danal said in DuetLapse available for Alpha testing:

Keep the ideas coming!

In my customised build of Raspbian with duetpi I created a timelapse.desktop entry so that I can access your program from my start menu.

By default I set it to take a picture upon Z movement.
So now, when I start a print and the printer is ready all I have to do is click on the program entry in the start menu.

Thank you again danal for giving us this great program.

kingfisher

I've set it up and it works
I did get an error on a small print doing a quick test though
The error was "requests.exceptions.ConnectionError:

('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer'))"

My guess (Although I'm not a Python expert) is that the pi couldn't keep up saving the images as the layers were only taking 20sec (And its an old V2 pi)

kingfisher

@kingfisher
I actually think it might be my Duet wifi board causing an error. I've also got a duet maestro and running the same python settings on the maestro IP address hasn't resulted in the "('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer'))" error

Danal

Updates based on feedback:

Added -dontwait flag. This causes the script to not wait for a print to start; it captures images immediately. Of course, it will only capture things that happen... Example: If told only to capture on layer changes, well, that won't happen prior to a print...
Added 'camparms -parms' subsection to command line flags. Anything in that subsection is passed to the camera command (whichever for the appropriate camera type, fswebcam, raspistill, or wget)
Removed pallet from fswebcam (USB attached cameras, despite its name). It will automatically attempt to find the best, or you can specify one, example:
./DuetLapse.py -duet 192.168.7.101 -dontwait -seconds 3 camparms -parms -p YUYV
Removed -q from fswebcam. Default is 35. You can override, same as above.
Slightly changed the loop timer, to beat on the printer a little less often.

*** IMPORTANT *** Found a bug in DuetWebAPI and fixed it, you must download this as well. Therefore, pull these two things into the same directory. One way to do this would be:

wget https://raw.githubusercontent.com/DanalEstes/DuetLapse/master/DuetLapse.py
chmod 744 DuetLapse.py
wget https://raw.githubusercontent.com/DanalEstes/DuetWebAPI/master/DuetWebAPI.py

Danal

Also, added quotes around the wget URL.

Danal

Still thinking about overlay of Z, print time, etc.

tekkydave

@Danal said in DuetLapse available for Alpha testing:

Also, added quotes around the wget URL.

tekkydave

@Danal what ide / dev tools do you use for python development. I'm using Eclipse for c/c++ and Netbeans for Java. Is there a tool for python that will allow local (Ubuntu) testing and remote deployment to the pi?

Danal

For Python, I edit with Sublime on a PC. It could be any editor or IDE that you like that has syntax highlighting or whatever. I interface to the Pi by doing this on the Pi:

# If you want to be able to edit files on the Pi from windows, via a netshare (not a mapped drive):
sudo apt-get install samba
sudo smbpasswd -a pi
sudo nano /etc/samba/smb.conf   # and change 'read only = yes' to no. 
# Then use a UNC like '\\192.168.7.101\pi' in a file open in your favorite editor.
# Quite often, you may have to start with just the "\\192.168.7.101" and no subdirectory to get
# it to prompt you for userid and password.  Use 'pi' and the password you set above.
# You may have to try and retry several times to get connected.  It's worth it. 
# BE SURE that your editor HONORS UNIX LINE ENDS and that you turn them on in any new files. 
# For windows users, I suggest notepad++ or atom or Sublime Text (that last one costs money. Worth every penny)

The big key is the UNC on Windows. \192.168.7.101\pi This is NOT a drive share... and doesn't behave like SMB shares behave. In sublime, if I do an "open folder" on that UNC, I can then click into \192.168.7.101\pi\DuetLapse (or whatever) and see all the files.

Note: This WILL cause your editor to hang if it has files/folders open and the Pi goes away. In sublime, I set it to NOT re-open whatever it had at close...

Testing? For python there is no "make" or "build" phase, so I just test directly on the Pi. Either VNC if I need graphics, or Winterm and ssh if not.

You can, in theory, test on your desktop distro, by building enough "context" around the thing you are testing. Directories, etc. However, many of the things that I'm testing (not necessarily the stuff you are seeing for Duet) is so tightly related to interfaces or other structures in Raspbian and/or the actual Pi hardware, it is just easier to test there.

For cross compile, like binaries for ESP32, or the Atmel chips, or similar, I still edit in Sublime, with the PlatformIO plugin. This makes it a cross-platform IDE. I've come to really like PlatformIO (as vs. the more 'Arduino' like environments). It runs a mini-RTOS and is very well documented and very flexible.

If I'm working with stuff developed by others for Atmel, then it is Atmel studio all the way.

That covers pretty much everything that fits a pattern. There are, of course, one-off environments for exceptional cases.