Best posts made by Danal

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

I'm starting this topic to report progress as I build and commission a printer that is using Duet 3 6HC hardware, specifically including use of two Duet 3 expansion boards.

The printer is a Jubilee. This is a CoreXY printer that is intended to further exploit the E3D "de-facto" standard for kinematic couplings on tool changers. That is, a coupling that will put the tool in the exact same place every time (with 'exact' being defined as 'more than sufficient for an FDM 3D printer')

@droftarts said in Incident report: RRF 3 RC6 DWC 2.1.0 Lockup during print.:

I agree. It's just taking time to get DSF (which is pretty much brand new) up to speed with the rest of the firmware (painstakingly developed over many years). But without community interest and expertise getting it working, reporting bugs and fixing, it will take much longer. So once again, thank you all for your continued support.

This completely misses the points being discussed by at least three or four vocal users. It is a powerful indication of the "blind spot" within Duet that causes me to invest the energy in typing these responses:

Any rational person would expect a new major section of software to climb a maturity curve. Totally agree with you on that. And introducing major new architecture and function in V3.x, I believe we all expect it to take time to stabilize. Regardless of where it runs or what tech stack it uses or... it will just take time, testing, feedback, and improvement. Agreed, D'accord.

All of that has nothing to do with the pervasive attitude that RRF and DSF are two separate things. From the viewpoint of the end user they are one thing with defined external interactions (Gcode, Web API, etc).

There are numerous examples of this mis-perception. All of which are seriously complicating the ability to build, deploy, test with the community, upgrade, downgrade, and generally "deal with" the product that fits under the general header of Duet V3. And the folks at Duet appear to be unable to see or acknowledge this is even happening.

When I said "sort of." above, this is what I meant. I don't believe I am ranting anymore; yet there is still more to discuss. I sincerely hope these strong words are read with the intent they are written: To help Duet get better.

I've "fixed" a lot of glitchy CNC machines by grounding. I have NOT had to do this with 3D printers... but... I've had less hands on with other people's printers.

Things I've learned with CNC:

• Bond metal frame components frames across joints. Even bolted joints. A short jumper.
• As already mentioned, file or sand through anodizing on aluminum frames. Including clear (silver).
• Run all ground wires (other than joint jumpers) to a single point, creating a physical "star" configuration. Use a long bolt and stack the crimp-on rings.
  Star ground configuration is probably the most important point to achieve stability.
• If you have SHIELDED cables, ground ONE END, not both. Normally, the end that is physically closer to the "center of the star".
  "Only one end of a shield" is the second most important point. This is also the hardest thing to get people to actually do, it just seems counter-intuitive.
• NEVER use a shield in place of a ground wire.
• Do NOT connect the star ground bolt to Earth ground*. Normally. (See below).
• If the machine runs stably, keep "star center" isolated from Earth... if it still glitches, then do consider connecting them. Double and triple check that this is done safely, abolutely no chance of the star ground and/or frame encountering anything that is Mains "hot".

A "star" ground with each wire back to a given central point, that technique has stabilized quite a few CNC machines that were having problems.

.

*Terminology: Earth = Ground Pin in Wall Plug in US, Ground Pin in Mains plug in UK, etc.

If you don't already have the extruder, I'd recommend a Bondtech over the Titan, by a wide margin.

Feedback: The whole

apt update
apt upgrade

process is getting very smooth and nice. A very effective way to install everything.

@oliof said in Duet 3 GND header:

Hi,
My V core pro has all GND on the AC. I wonder if/when/where to connect the GND header on the duet3 board (I have a revision 0.6 board)? It seems like a bad idea to tie DC GND to AC GND ...

You received a lot of information and posted that you were overloaded with info but still did not know the answer to the original question ("...know nothing..."). Therefore, I've repeated your original question above and will try to be as clear as possible:

• Connect your 24V power supply to VIN with stranded wire of at least 18 AWG or .8mm2. CRIMP, do not solder, "bootlace" connectors to ends that go under screw terminals.

• If you have a 24V heated bed, connect "Out 0 Power In" to the 24V supply with wire sized for that bed. The fuse is rated to 15A (the board to 18A) so 14AWG or 2mm2 is very roughly the largest that will be used. Use the same gauge from "Out 0" to the bed.

• If instead you have a mains powered bed, via an SSR (Solid State Relay), it is OK to jumper "Out 0 Power In" from VIN (careful with polarity they are 'backwards' in relation to each other) and then use 20 AWG or even 22 from "Out0" to the SSR low voltage input. ALSO, bond the frame of the machine to mains (earth) ground.

• Use an isolated 24V supply if at all possible. Cheap ones usually are not isolated. Meanwell is a brand that usually is.

And, at last, the answer to your original question:

• No need to connect the tab near the ether to anything.

• WIth one exception: If the board is in a metal case, connect the tab near ether to that case.

And a bit of "best practice" with regard to ground:

• Bring all grounds back to a single point. Do not 'chain' them. This is known as 'star ground'.

• Normally, do not bond Low Voltage grounds to mains (110V or 220V) ground. That is also why the statements above about isolated 24V supply.

I agree with @T3P3Tony the device (in this case printer) should NOT be secured, instead, the network segment on which IOT devices run SHOULD be secured, and reachable only by a (secured) "reverse proxy" or "jump host" or "Firewall" or "VPN" or whatever you call it. Let the good guys on that segment; keep the bad guys off that segment, AT THE BOUNDARY OF THE SEGMENT, not at the IOT device.

Why?

Because security in our current software/processor/service architectures is INCREDIBLY difficult. Honestly, I'd never trust any given device/program that was not a specialized security device/program which is in very common use and has been hammered and debugged and pen-tested very thoroughly.

As such, I'd STILL insist on having any given IOT device on a secure segment, with a secure proxy/firewall/VPN into that segment.

Therefore, I'd much rather see the limited time/energy of the developers for the IOT device go toward that device's actual function, and not toward security that ultimately can NEVER mean "run that IOT device unprotected".

Does that chain of logic make sense?

Here is a working 3-motor on Z, for auto leveling, config.g and bed.g

config (1).g
bed (1).g

I do understand that you are pretty far down the USB path... and it may be hard to convince you to change... but...

I don't believe I've ever plugged USB into any of my Duets. Just edit the files on the card in a PC or Mac enough to get wireless working, and then did everything else via the web interface. The key file & statements for the first wireless connection are:

/sys/config.g

M550 PDanal's BFD ; Set machine name
M551 P ; Set password (for Duet Web interface, not for WiFi network)
M587 S"MySSID" P"myPassWoRD" ; Set SSID and network key password for WiFi network.
M552 S1 ; Enable network

After you get connected the first time, remove the M587 so that you don't have your WiFi password floating around in a file. The Duet will 'remember' it.

.

Doing it that way, you need never connect USB.

Also, if you hover over the line, without hovering over a G/M word, you get this:

Which shows the move, and offers to send a move, set the "start" position (i.e. zero the current work coordinate system to this point).