https://github.com/DanalEstes/DuetLapse

Time Lapse camera support for Duet based 3D printers. Works with firmware V2 or V3 (including stand alone V3 or Pi based V3).

Designed to run on a Raspberry Pi, any Pi, not necessarily the one on the printer; may be adaptable to other platforms. Supports cameras via USB, Pi (ribbon cable), and Webcam. May support DSLR triggering in the future. Produces a video with H.264 encoding in an MP4 container. Does not, at this time, manage a library of videos, it simply drops the vid in home directory.

Triggers images based on time, layer change, or pause. Works with existing pauses in G-Code, or can force pauses at other trigger events. Coming soon: Optionally moves head to a specified position before capturing paused images.

See readme on github for the most current list of features, as they get implemented.

I've created a preliminary module/class to allow Python programs on the Pi attached to a Duet3 to interact with the printer. It does so via the "Duet Control Server" socket (not websocket) connection in the "Duet Software Framework".

It is available on Github https://github.com/DanalEstes/PythonDSF

This is an early implementation and it may radically change in the near future. Nonetheless, if you are thinking about Python scripting, give it a try.

There is also an example script. This script is intended to do tool-to-tool measurement to derive offsets on a "Tool Changing" 3D printer of the E3D tool-changer type. Specifically, it is for my Jubilee. There are some instructions in the README about how all this works. This is a whole topic in and of itself.

A very minimal example of use might look something like this:

#!/usr/bin/env python3
import pythondcs
dcs = pythondcs.PythonDCS()

dcs.gCode('G0 Z10       F1000')          # Lower bed to avoid collision with square hole plate.
dcs.gCode('G0      Y225 F10000')        # Move nozzle to avoid other tools
r=getPos()
print("X position ="+r[0])

There are several other modules, including a "r=getPos()" that returns a Python list containing the current position of the printer, in mm. See the example script.

Two tools here: https://github.com/DanalEstes/DuetVersions
Installation instructions on the readme at that link.

Written in 'shell' and they are probably quite sensitive to EXACT formatting of command results and will therefore break at some point. For now, they provide what I want in mapping releases.

MAY add a utility that will show the exact command require to regress. Maybe.

Until then, these two may be handy:

./DuetVersion.sh
  Highest Available DuetSoftwareFramework = 2.1.1
Currently Installed DuetSoftwareFramework = 2.1.1

Dependencies for DSF version 2.1.1 are:
 duetcontrolserver (= 2.1.1)
 duetsd (= 1.0.6)
 duettools (= 2.1.1)
 duetwebserver (= 2.1.0)
 duetwebcontrol (= 2.1.5)
 reprapfirmware (>= 2.1.1-1)
 reprapfirmware (<= 2.1.1-999) )

reprapfirmware apt version 2.1.1-1 is internal version 3.01-RC10

If you specify a number as command line argument, you are asking for that same information on the release that many 'backwards' from the most current.

./DuetVersion.sh 15
  Highest Available DuetSoftwareFramework = 2.1.1
Currently Installed DuetSoftwareFramework = 2.1.1

Command line arg specified to request Release -15 from highest available.
      Highest-15 is DuetSoftwareFramework = 1.2.0.0

Dependencies for DSF version 1.2.0.0 are:
 duetcontrolserver (= 1.2.0.0)
 duetsd (= 1.0.5)
 duettools (= 1.2.0.0)
 duetwebserver (= 1.2.0.0)
 duetwebcontrol (= 2.0.4-1)
 reprapfirmware (>= 1.2.0.0-1)
 reprapfirmware (<= 1.2.0.0-999) )

reprapfirmware apt version 1.2.0.0-1 is internal version 3.0RC1

And... so we don't have to poke through -1, -2, -3, etc, a consolidated list of the DSF to RRF releases:

 ./DuetVersionsAll.sh
Expect this to take several seconds per line of output.

duetsoftwareframework 2.1.1 contains reprapfirmware version 2.1.1-1 which is internal version 3.01-RC10
duetsoftwareframework 2.1.0 contains reprapfirmware version 2.1.0-1 which is internal version 3.01-RC9
duetsoftwareframework 2.0.0 contains reprapfirmware version 2.0.0-1 which is internal version 3.01-RC8
duetsoftwareframework 1.3.2 contains reprapfirmware version 1.3.2-1 which is internal version 3.01-RC7
duetsoftwareframework 1.3.1 contains reprapfirmware version 1.3.1-1 which is internal version 3.01-RC6
duetsoftwareframework 1.3.0 contains reprapfirmware version 1.3.0-1 which is internal version 3.01-RC6
duetsoftwareframework 1.2.5.0 contains reprapfirmware version 1.2.5.0-1 which is internal version 3.01-RC4
...snip...

@dc42 said in RepRapFirmware 3.0RC1 released:

Some of you may not have have noticed that I did a 2.05 bugfix release, at the expense of delaying the 3.0RC1 release which was almost ready.

I did notice! And thank you.

At the same time, I believe a 2.xx bugfix interacting with the schedule of a 3.xx release is somewhat different than a regular practice of (in order):

3.00 initial release with however many RCs, not shown.
3.01 bug
3.10 feature (and fork)
3.02 bug (on 3.0 base)
3.03 bug (same)
3.13 (integrating 3.0x and 3.1x)

It is the hours that go into that last 'integrating' line that are my concern. Those hours simply disappear from the pool that advances both fixes and features. Factually, they slow things down.

Numerous industry studies show that within software projects that continue to evolve, 80 to 90 percent of fix code hits prior fix code, not base or feature. If that metric is accepted as fact, then fork separating and later re-integrating really accomplishes very little or nothing toward stability.

Therefore, I continue to advocate that a single code path, without multiple fork and re-integration, is proper engagement mode for very small development teams

Large team? Whole different set of answers. DevOps continuous integration, forked bugfix releases, production patch hotfixes, lots of things apply to large teams that just don't apply to very small teams.

Of course, this is all just a fun discussion. The development philosophy is ultimately up to DC42.

Testing on a small delta now.

By the way, love LOVE love the new "zip" package, avoids numerous problems with naming, browsers that put (1) in duplicate downloads, etc, etc.

Brilliant!

I'm sorry Dave, I'm afraid I just can't do that.

I've put three new repositories on Github:

• https://github.com/DanalEstes/installOpenCV
  A script intended to install OpenCV on the Duet provided SD image (full, not lite) with "one press of enter". This exists for two reasons:

First, every "install OpenCV" tutorial I can find is several pages long with twenty or thirty steps.

Second, they all "virtualize" the install to make it possible to have multiple versions and configurations of OpenCV. This makes runtime hard, and we don't need it. We want a single install that "just works".

• https://github.com/DanalEstes/DuetWebAPI
  A way to issue commands and get information from Duet RepRap V2 or V3 printers, via a network.

It is NOT intended as a general interface; it is for 'lightweight' use in scripts, with the strong intent to abstract away as much complexity as possible. More info in the readme in the repository.

This enables TAMV to run on a D3+Pi, or on any Pi that can reach a D2 or D3 printer via the network.

• https://github.com/DanalEstes/TAMV
  This is the real purpose of this post: Tool Alignment with Machine VIsion

This script is intended to allow Duet V2 and V3 tool-changing printers to align any number of tools that have a recognizable circular nozzle via full automation. It will ultimately generate the correct G10 commands and write them to the printer in a file that can be M98 included in config.g.

@TC said in Setting tool offset using USB microscope:

@Danal I am working with a USB microscope right now but so far allways have to do manual fine tuning be printing test objects...

My final target is full automation. I've found that the various microscopes have such a narrow field of view that "starting from scratch" with no offsets (yet), it is often true that if you put T0 over the scope, write down the coordinates (or script capture them), and put T1 in that same position, it won't even be in the field of view.

Therefore, I've switched to the Logitech C270. That specific one because it has a threaded lens held captive by a dot of hot-melt (or similar). It is easy to open up, turn the lens, and get it to close focus.

Anyway, using this camera, and an overlay circle (placed there with openCV), I've found that I can be repeatable to better than the tool-tool repeatability of the printer.

So, yeah, no printing test objects.

C270 image:

Just because it uses a Maestro controller to have enough drivers for a 4-extruder head, the Quad Crane gets mentioned around here every so often.

For any one interested, here is a Mini-Review:

http://danalspub.com/2020/03/crane-quad-from-m3d-part-1/

Hmmm... I have a reflow/rework hot air station and two programmable profile reflow ovens, and I am in North Texas (USA) from a shipping logistics point of view.

I would also be willing to take on some repairs as "best effort" favors, and like Bearer said, as long as this is not harmful to Duet the company.

So... with the thought running through my head "...no good deed goes unpunished..." anyone who believes they have a repariable board and is willing to risk A) Postage both ways and B) The board being made worse, my direct contact is:

danal (dot) estes (at) gmail (dot) com

Either suggested technique will work fine.

Sort of.

You can

• sudo apt-get install samba
• sudo smbpasswd -a pi
• sudo nano /etc/samba/smb.conf # and change 'read only = yes' to no. It is fairly far down in the file.

Then, on your windows machine,use a UNC like '\192.168.7.101\pi' in windows explorer, or an editor, or whatever. This is not a pure SAMBA "net share" in that there is no drive mapping. In my opinion, it actually works better...

Any port. If you haven't run DuetLapse again, and have not rebooted, all the stills are in the /tmp directory. You can look at them individually, and/or re-assemble them into a video.

SCARA. The actual Sisyphus uses a sort of "bar on top of a rotary shaft" that certainly seems to work. I may convert over (back?) to that. But the SCARA seems to produce good patterns if you get it to "home" EXACTLY to the center (as defined by its own arms). And the opticals seem to make that work.

I haven't looked at Sandify in a few months; I'll give them some fresh attention.

The pic of the mechanism is pretty bad, I was apparently trying to get the board. It may help to know the "elbow" of the SCARA is pointed almost at us, at the right edge of the pic. The wrist and hand are visible with magnets in the background.
Also, the rim LEDs need to be "Higher". (Proto...). Yada Yada.

@luckyflyer said in DuetLapse available for Alpha testing:

@Danal I've got the numpy required error on my Duet pi, you said in a previous post that "I've updated the script to show the required commands, if numpy is not found." I'm on your Duetlapse github wiki, usage section. I don't see any commands for if numpy not found. Where do I find them?

Also I've loaded everything onto a standalone pi and everything works except there is no video. I'm using a microsoft usb camera that works with motion eyes, I have the script set for usb camera. I read where someone else had this problem but was unable to follow what they did to correct, cuz I'm a noob with linux, would you please walk me through what I need to do to get video?
I'm not going to use the stand alone pi if I can get the Duet pi working but ask because I figure if its not working on the stand alone pi then it won't work on the Duet pi.
Tia

ahri's commands should work.

I was referring to having the script tell you that, instead of half a page of stack trace and a "numpy not found". I'll check and see if I did that or not...

@arhi said in DuetLapse available for Alpha testing:

@Danal no idea, I'm mostly the "ssh to a dev machine and work in console", gui is not my thing. I use "visual studio code" only barely (learning go and rust) and that's it. For ESP32 I use basic arduino IDE, did not use it so far for anything serious, ESP8266 I did some "bigger" projects back in the day and with their whole SDK I used xtensa from them and made Makefiles manually, so easy to call gcc or g++ depending on the c/cpp extension. I had platformio setup on previous computer that went out in flames half a year ago and never redid the setup on the new one as I didn't find it very nice. Something about VSC is not sitting with me properly and PlatformIO was taking it too far. I'm the old style Makefile / autoconf and VIM ... recently we moved to cmake but I still did not use cmake for any of my own projects and the cmake structure of mysql is maintained by someone else

Yeah, I have a lot of resonance with that. Nonetheless, breakpoints on the embedded board and hover the mouse over a variable (when paused) to see its value... that makes me put up with a lot from the IDE.

You'll both appreciate this: I'm all over that very lower right magic dot...

If it might have had resin, give it a REALLY GOOD wash with pure IPA, then put it in a warm spot for a long time...

Clicky would work well... I'd exactly copied the person with the hall effect stops. They are just a little to loosey goosey for exact centering of a SCARA.

Also, I don't have glass on mine yet, so take this with some limits... I am using "Hamster Bathing Sand". Seems to work very well. Amazon. It might stick less (or more, who knows). Thanks for the exact speeds, I'm still experimenting.

@arhi said in DuetLapse available for Alpha testing:

I do system service programming 10 hours a day in c/c++

Then I have a really off the wall question for you:

Do you know how to FORCE "Visual Studio Code" (Note: not Visual Studio) with PlatformIO installed running the Espressif32/ESPIDF platform, force it to compile a mixed source module project with C compiler for .c and .h files and C++ compiler for .cpp and .hpp files? I can handle the 'extern' and such for the cross-calling, so the linker is happy, no problem. I just need it to use the right #$% compiler.

I thought the whole "use the right compiler by file extension" thing was automatic, and it seemed like it has worked before in VSC. However, at the moment, I have a project that throws tons of errors in the .cpp files, because it is treating them as .c.

Like I said, off the wall, because it is a VERY narrow question: VSC (not VS), PlatformIO and Espressif32/ESPIDF...

@arhi said in DuetLapse available for Alpha testing:

I actually expected that I'll easily find a video player that will do just that, allow 2 tracks to be played pip style or one next to another or something like that, but most players don't even support multi track video and best I could find is "easy switching" with ALT+V on the potplayer. I generate first both videos as mk4 and then use ffmpeg to copy them into single mkv with two tracks. Will investigate further, maybe there is better way. So far I like that I don't have to use raspistill and that the fs.. can do both rpi camera and usb camera, and I want to be able to capture both and that works somehow ok. Now I need to see how to make a best output from the two sets of images

I was thinking more of an editor, so there is nothing at "my end". Just a regular vid, with side-by-side or p-n-p.

Speaking of which, I don't have any players installed on this machine, and I haven't been able to look at that mkv quite yet.