Hey guys,

after countless hours and multiple iterations, I would like to present to you the D-PATCH (Delta Printer with automatic tool changing). To my knowledge there is no Delta Printer available with tool-changing. I have been working on it for over 2 years (started in March 2018) and I am proud, that it is now a reality.

As you can see it’s not completely finished yet, because the actual tool changer is missing, but is in the making. A prototype is existing already.

Stats about the Printer:

Print volume: 300x300mm

Available tools: 5 (for now)

Board: Duet 2 Wifi + Duex 5

Power Supply: 24V 13A Meanwell

Security: Circuit breaker + RCD +Emergency Stop

Bed: milled aluminium bed with 600W mains heater switched with SSR

Print surface: Magnetic bed

Tool-Changing: Automatic and Manual

Control: PanelDue

I will updated the tread when I make more progress.

I'm really curious about your opinions and please let me know if you have any questions.

Adrian

Hey guys,

I worked on a tool length sensor which some of you may find convenient in certain circumstances.
e.g.

• nozzle change
• change of the hot-end
• tool changing

It is fully printable with some minor add ons which most of you have lying around. The Tool Length Senosr (TLS) can be wired in parallel to your z-probe (connecting between GND and IN), because its in fact a normally open microswitch.

I made a macro with conditional G-Code for it, which iterates through the defined number of tools. When the probe is hit by a clean cold nozzle (hot nozzle is possible as well with a small add-on) the current z position relative to the TLS is stored in G10 Commands and stored in the EEPROM (p.s. don't forget to add the needed command to your cofig.g).

;05.08.2020
M291 P"Please put Tool length sensor in the middle of the build plate and hit okay when done" R"Placing tool length sensor" S2
M291 P"ATTENTION: Machine is moving during the probing moves" R"ATTENTION" S2
G28 ; home
G90
G1 X0 Y0 ; move to center
G1 Z50 
while iterations<#tools		;run as often as number of tools
	if tools[iterations] != null	; check if tool is really asigned
		M291 P"Please put Tool" ^ iterationis ^ " into the effector and hit okay when done" R"Tool [iterations]" S2
		if sensors.gpIn[1].value=0	; check if tool is in effector
			M291 S0 T3 P"Tool in effector"
		else {}
			M291 S0 T3 P"Tool not in effector"
                        abort
		G91
		M98 P"Alarmsound.g"
		G30 Z-45 S-1 
		if  sensors.probes[0].value[0]>500
			G10 P{iterations} X0 Y0 Z{move.axes[2].userPosition-12.5}
			M500 P10
		G1 Z50 F500

If you have any questions or suggestions please feel free to ask

@oliof Yeah you are right - I found these videos, too, when I started to look into tool changing Delta printers, but not many infos out there.

About your question - yeah a little more brain juice went into the design of the locking mechanism.
So it is basically a bayonet lock that is driven by a Bowden cable and reset by a bunch of springs

The pieces of the bayonet that lock the tool are angled so a downward force is created by the rotation of the bayonet. It is locking onto 3 zylindrical pins that are placed 120° apart from each other so that the locking is uniformly

@JoergS5 Thank you
@jpomo10 of course ;). There are multiple options:

1. set the stand-by temperature so low, that a equilibrium is reached
   (+ no additional fans, - long heat up time)

2. one fan for each tool in parking position
   (+ sufficient cooling, - lot of fans with lots of noise)

3. one bigger fan with a fan-duct to direct the air to the heat sinks of the tools in parking position

For now I have no fans at all. So after the first prints I had not a lot of heat creep and no problems with jams. But I guess I will move on with option 3

BTW: I posted another video of the first dual color print on youtube

Hello guys,

I went a new way for the cooling of the tools without some parts of the sci fi attack hovercraft.
I added a fan to each tool instead. The data shows that the cooling is sufficient.

Hey guys,

as I have just 1 Fan output to spare I decided to make a small LED extension board which can control individual addressable LEDs (e.g. Ws2812) with just 1 PWM output from the Duet. This has several advantages.

Components:

• DC/DC converter (from 12/24V to 5V)
• Arduino Nano
• Screw terminals or pin headers

Advantages:

• LED modes (e.g. pulse, running LED, rainbow, ...)
• Just 1 PWM output needed
• With the DC/DC converter you have enough power for the Nano and the LEDs
• Nice integration in the macro system (just set the PWM of the Fan output in e.g. start g-code)

I will order some PCBs so when you are interested - let me know. When the files are final, I will publish them.

Here you can see some better pictures of the D-PATCH

As it showed up on the DWC I reworked the config and now it is there

So I guess all issues I had are now resolved.

Thank you all for your support!

Thanks that you like it! Yeah as soon as this version will be finished I'm thinking about publish the files under CC-BY-NC so that the community can use it

BTW: I really love your unconventional tripteron design!

Started working on the Tool-Changer itself

@fcwilt are you sure you habe filament diameter 1,75 Set in the settings? Default for cura is 2.85

@paulhew As I said it was already working. I guess the update try did something to the image. I don't have the in-depth knowledge to know how and which files to delete to free up space

@paulhew
I changed the default password and can login with the new password via SSH. The past weeks I was able to login with the new password aswell. I tried rapsberry but I get an error promt

Hey guys,

I have a Raspberry Pi for an 7" touchscreen. It runs the duet image and I tried upgrading it but if failed because of to less storage (the image is running on an 8 GB card).

But everything was working fine.

As of today I can't login to the pi (the desktop is not running) and I can connect via VNC but can't login

I can connect via SSH and the df command showed:

why is the root folder 100% full? what can I do to fix that?

@bberger
@dc42
is there an explanation why Klipper is performing better than RRF? Has it something to do with the processing power? or is the algorithm implemented differently

I see something similar as RRF is not able to get completely rid of ringing

I have the same problem - from 3.4 I have the behaviour that even during filament loading I get an filament error so the loading is canceled

I talked to Tony on Formnext and he told me that support for Duet2 will be ongoing for years. Now you are thinking about a feature freeze. To be honest I don't think it's a good idea because then I guess more and more people are not going to use Duet2 anymore but prefer to run Klipper when the firmware for Duet2 gets more and more outdated. I can't say if the Duet3 boards are a viable replacement (e.g. I am running Duet2 and Duex5).

I prefer the option to remove the support for exotic kinematics from 3.4 onwards (so they could still run 3.4).

To make a real decision I guess it would be important to know what you would like to do the RRF in the future. Which features do you want to implement which are a USP for RRF

Hey guys,

Is there a way to assign an filament run-out sensor to a specific tool. Reason is that I get filament run-out error even if the tool is not used in the current print.

Thanks guys

But then I guess the documentation is wrong

@alankilian
You are totally right - there are no such things as obvious - I am sorry that I did not provide all the information you need.

@dc42
So In my head the Duet GPIO Inputs looks something like this

I don't mind if its inverted, the problem is that I already have a PCB with the functionality. Problem is that I am not that deep into circuit design. I don't get why it was working before ( did I plan the TCMT4100 wrong)?

EDIT:
Oh no I see my error ...