DuetLapse available for Alpha testing

Danal

@gtj0 said in DuetLapse available for Alpha testing:

Just about to try it but noticed that it seems to be opening and closing the unix socket twice a second. Not usually an issue except I run the DCS with debug logging so it's kinda distracting. Any chance of just keeping the socket open or better yet, just getting the model updates as they happen?

It doesn't touch the unix socket. It is opening and closing a websocket connection, and not persisting it. This was a design choice in startup to not track state. I will look into persisting that connection.

zapta

@Danal said in DuetLapse available for Alpha testing:

Keep the ideas coming!

Danal, here is an idea, not necessary specific for this timelapse app, but since you know how to monitor the duet during printing and generate visualization, would be interesting to have something that plot the different time left estimations that the Duet provides.

Think of an x/y graph. X is print time from 0 to total print time T. Y is the time left for completion. The ideal reporting is a straight line from (0,T) to (T,0). And then you can sample the duet and plot the time left graphs by the various methods the Duet uses.

The output can be an actual graph or a csv file that can be plotted with a spreadsheet and the likes.

gtj0

@Danal said in DuetLapse available for Alpha testing:

Which USB camera?

Teslong USB "Endoscope". It only supports MJPEG as a palette and I just noticed that you've got YUYV hard coded on the fswebcam command line. Maybe don't specify '-p' and let it default?

@Danal said in DuetLapse available for Alpha testing:

@gtj0 said in DuetLapse available for Alpha testing:

Just about to try it but noticed that it seems to be opening and closing the unix socket twice a second. Not usually an issue except I run the DCS with debug logging so it's kinda distracting. Any chance of just keeping the socket open or better yet, just getting the model updates as they happen?

It doesn't touch the unix socket. It is opening and closing a websocket connection, and not persisting it. This was a design choice in startup to not track state. I will look into persisting that connection.

Ah yeah, the websocket will result in the same messages. It's not critical so don't spend all that much time on it.

Danal

@gtj0 said in DuetLapse available for Alpha testing:

Teslong USB "Endoscope". It only supports MJPEG as a palette and I just noticed that you've got YUYV hard coded on the fswebcam command line. Maybe don't specify '-p' and let it default?

I think I did that and it required it for some reason. I will try a couple of different things to get it as automatic as possible.

kingfisher

Thanks for sharing I. I'll try installing this in whilst in lockdown.
I had an idea to use a pi remotely to control RGB LEDs based on the printer status. (eg red = heating, white = printing, green = finished)
I might try and learn how to do this based on your code/logic

UnderDoneSushi

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

tekkydave

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

gtj0

@Danal said in DuetLapse available for Alpha testing:

@gtj0 said in DuetLapse available for Alpha testing:

Teslong USB "Endoscope". It only supports MJPEG as a palette and I just noticed that you've got YUYV hard coded on the fswebcam command line. Maybe don't specify '-p' and let it default?

I think I did that and it required it for some reason. I will try a couple of different things to get it as automatic as possible.

fswebcam doesn't require it at least for my camera. It figured out MJPEG by itself. Maybe it's an issue if the camera supports more than 1 palette. You could check for the existence of ~/.fswebcam and if it's there, add a -c ~/.fswebcam to the options. This way a user can put whatever options they want in it.

Once I changed the palette, it worked great!

Danal

@kingfisher said in DuetLapse available for Alpha testing:

Thanks for sharing I. I'll try installing this in whilst in lockdown.
I had an idea to use a pi remotely to control RGB LEDs based on the printer status. (eg red = heating, white = printing, green = finished)
I might try and learn how to do this based on your code/logic

The "interface" is in a separate library, for just that reason.

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.