3DPrinting
3DPrinting is a place where makers of all skill levels and walks of life can learn about and discuss 3D printing and development of 3D printed parts and devices.
The r/functionalprint community is now located at: [email protected] or [email protected]
There are CAD communities available at: [email protected] or [email protected]
Rules
-
No bigotry - including racism, sexism, ableism, homophobia, transphobia, or xenophobia. Code of Conduct.
-
Be respectful, especially when disagreeing. Everyone should feel welcome here.
-
No porn (NSFW prints are acceptable but must be marked NSFW)
-
No Ads / Spamming / Guerrilla Marketing
-
Do not create links to reddit
-
If you see an issue please flag it
-
No guns
-
No injury gore posts
If you need an easy way to host pictures, https://catbox.moe/ may be an option. Be ethical about what you post and donate if you are able or use this a lot. It is just an individual hosting content, not a company. The image embedding syntax for Lemmy is ![](URL)
Moderation policy: Light, mostly invisible
view the rest of the comments
As long as the basic connections are an open design.
It would be a great step towards multihead printing.
Lets face it long term to gain the full ability of 3D printing. It will need to move to a multi material design. And that is likely to require the ability to change tool types mid-production.
Multihead printing is still in the early days. The software isn't there: For example, RRF (Duet) would throw error messages for missing CAN boards when you would try pogo pins and only electrically connect the active tool head. The most advanced we have at the moment are toolchangers with 4-5 fixed tool-heads.
RRF/Duet in standalone is very stable and what you want. The flipside is that even through it is flexible with macros there are limits. This is more and more an issue that limits what can be done. Due to stability, I so far reject the idea of switching to Klipper (even duet in SBC mode isn't stable enough for my taste).
Also keeping track of heads is ugly at the moment. In a perfect world each toolhead would have an EEPROM and the machine would recognise it. Maybe even look up on a server/database what offset and parameter this tool needs so it could be swapped between tool-bays/docks and machines. For example with CNC milling it is state of the art that tool holder have RFID chips for tool identification and data is synced across the production floor (e.g. the shrink/tool setup station provides the tool data to a server and the CNC-mill controller gets the data automatically from this server).
If you like to install the same thing I can send you the Gerber, BOM and 3D-files for E3D toolchanger. In a nutshell this does nothing more than beeing "inserted" into the wire. If you want to call it special: platform agnostic. The small black header on the side is the auxiliary connector and is there for toolheads that require 5, 12 or 36V. For good measure three fuses (24V, 36V supply and heater).
end effector 1: FDM end effector 2: FDM end effector 3: silicon (paste/liquid) end effector 4: subtractive milling *
Sad part is that this type of setup will be for the next two decades exclusive to the DIY community or a company with deep pockets and good lawyers due to a removed Stratasys patent on making an electrical connection between toolhead and the gantry/mount.
The part that makes angry is this isn't even a Stratasys invention at all. Since the beginning of industrial robots, there have been electrical, pneumatic and liquid interfaces between the motion system and tool head. A toolchanging 3D-printer is a motion system with a tool head (e.g. filament extrusion) but this is locked behind a patent for this application.
Klipper will halt if a canbus toolhead disconnects anyhow, or at least how I have it configured it seems to, will handle packet loss just fine, outright disconnects? Nah, it wasn't happy.
Klipper wise, imagine you could do something with the can uuid, I have a macro that I found that sets offset based on sheet (replicating prusa's sheet selection in marlin, I like to have a bit less squish for nylon for example, more for textured sheets), offsets stored in a config file but you could easily swap that for an actual database if you wanted to.
There's some klipper extensions like spoolman that are kinda sorta that for material management, yes relies on manual entry afaik, but supports material changes so presumably multi toolheads and more importantly, can share across printers, have it running on my server.
Don't even get me going on patents...
Duet has Filament macros. Which can be uploaded/changed over the network. Not great but could be done with some glue logic.
Similarly, the config files can be exposed to the network and a server could "sync" them. All of this works but is a crapy solution that requires countless glue logic to make it work.