@Jacotheron Finally had a chance to test this with Fusion 360 and it is working for milling. Thank you!

Saw this posted on reddit and wanted to share:

YouTube link

@alankilian

Thank you all for the help.

I used M571 "e0heat" Qxx Sxx and it's working now. Also upgraded to 3.3 as @Phaedrux recommended.

@dc42 I'll admit, I have a specific use case that requires multiple components to turn on when extrusion (syringe) is active. No idea if it's feasible, but I would love to see multiple M571 commands supported so that each external component can have a dedicated output.

For now, my workaround is to define a M571 in tpreX.g for each tool. All my external components use 24v input, so I'll just connect all of them to the needed output and turn them on simultaneously.

Hey, exactly what @Jacotheron said. Here are a couple of post processors found on the forum, but you can search for others too. You'll have to try some out and see what works best for you. If you find one that works, you may also need to manually edit the Gcode to add or remove commands as needed (I have to do this).

I've used this with success:

https://github.com/mwinterm/fusion_post/tree/master/DuetCNC

I tried this but it didn't quite work for me:

https://github.com/guffy1234/mpcnc_posts_processor

Search google for how to import a post-processor into Fusion360

@JoergS5 There may be hope... I contacted the author of that topic in March and they said the linear rails had been sent off to be EDM'd.

@bot I too have been dreaming about using linear motors in a build. I've heard they can sometimes be salvaged from old electric typewriters from the 80's like the Daisy Wheel or Brother EM series. But I don't know if those are suitable for a printer.

@fcwilt @Alex-cr

Points well taken, thanks.

I'm building a tool-changing printer with two independent z-axes (one for each tool).

The Duet thinks there is only 1 z-axis at any given time, so I use M584 to switch stepper outputs during tool changes.

(dc42 suggested this method here: https://forum.duet3d.com/topic/16609/multiple-z-axis-and-complex-tools-possible)

Is there a way to get each Z axis to move in sync during a print?

For example:

Printer homes and both axes home to their endstops. T0 & T1 Z-height are both at 0

T0 starts the print and completes Layer 1 & 2

Tool-change to T1

T1 Never moved from its homed position (Z=0) so it will crash into the print.

Does anyone have insight to ensure that both T0 & T1 move upward as the print progresses?

Ideally, each tool would move to some intermediate position defined in Tfree, and the return to the correct z-height for printing when it becomes active again.

Thanks!

In the photo, T0 is on the left, T1 is on the right.

@taconite Hey any thoughts about preventing heat-creep after a (hot) tool is placed back on the carousel?

I had an issue like this that was caused by a poor ribbon cable connection between the Duet and Pi. It usually required that I reseat the cable before DWC would work again, but It was also somewhat unpredictable.

I replaced the ribbon cable with some jumper wires and the issue hasn't returned.

@oozeBot

My deviations show -0.117/0.315mm and I get ok results.

Somewhere on the forum I read that larger deviations may require a higher Z-axis acceleration setting so that the printer can move up or down fast enough between probed points while printing. If that's true, then I'd guess that it shouldn't be a problem unless your Z-axis mechanics aren't suited for big velocity changes because of backlash in the z-carriage, etc.

@taconite Happy to see this project alive and well!

@supahobnobba

Great to hear from you and thanks for sharing your experience with it. The method you described is what I ended up doing, and it has worked well for us. I still want to try the optical endstop + M585 route when I find some time. I salvaged the optical sensors from a decommissioned piece of equipment.
I even designed a mount for all three sensors. No Idea if it will work, though. Especially with the very small contact point on the z-axis switch in the middle.

Thanks again!

@phaedrux Thanks for the reply. I'll give this a try and update with what happens.

Some of the tips are straight, but others deviate across their length by 1mm, sometimes more or less. But they are inexpensive, which is a plus.

@fredcailloux

I used to work on a machine similar to what you're describing.

In the end, we decided to use a standalone motor driver which could accept the encoder signals and perform the closed-loop control on its own (separate from the Duet). The Duet would then just send step/direction signals to the driver, like you mentioned. Since the Duet will be uninvolved with the close-loop control, you may be able to configure your servo drive to send an alarm signal to the Duet to pause the print if the position control has an error. Without that feedback, the Duet will not know if there has been a fault.

No Duet board can accept encoder signals for closed-loop control, but there is a forthcoming add-on board that can do this for Stepper motors (see DC42's messages).

https://forum.duet3d.com/topic/22243/closed-loop-nema-17-23-driver-controller-for-duet-3-6hc-board/31

Once that board is available, I think, in theory, you could continue with your current servo drive, send the encoder signals to the duet closed-loop board, and send the step/direction signals to the drive. You'd just need to make sure your existing encoder is compatible with the duet encoder board when the specifications become available.

I've turned an E3D Toolchanger into a Syringe dispensing printer. I'm dispensing materials with viscosities similar to silicone caulking.

One major difference between my printer and an FFF printer is that nozzle changes are frequent - typically before each print to ensure reliable dispensing.

Does anyone think automatic tool offsets can be done using optical endstops for X, Y and a physical endstop for Z? I have several of these, which I've confirmed to work on 3.3V:
https://www.ia.omron.com/product/item/2263/

Z is the most straight forward, since I can just mount a switch somewhere on the buildplate and have the tool tip actuate it.

For X and Y, one commercial syringe printer uses a "LASER Beam Break" sensor. The nozzle is automatically jogged to break the x-axis sensor beam, same for the y-axis, and then the nozzle center is calculated. This gave me the idea of using the optical endstops.

For implementing in firmware, is M585 a good place for me to start?
https://duet3d.dozuki.com/Wiki/Gcode#Section_M585_Probe_Tool

Here's how the syringe tips look:

I've tried TAMV, and I use it for my FDM printer, but it proved to be unreliable for the syringe tips which are different sizes and colors, and the camera I use can't detect the nozzle center reliably.

Firmware: V3.3 on Duet 2 Ethernet

I appreciate any feedback!

@fcwilt @Alex-cr

Points well taken, thanks.

I've been using Lulzbots recently and they automatically home when you turn on the power.

I think that's kinda cool. Is there a way to do this in RRF?

@sindarius said in 3D GCode Viewer integrated with DWC:

I’ll need to look i believe the code currently uses the machine position and not the tool position which could be the issue.

@sindarius Did you have a chance to look into this?

I was working on someone else's E3D tool-changer today and experienced the same thing, so I wanted to check in.

DWC & Firmware Version: 3.3

@phaedrux Thanks!

@alankilian

Thank you all for the help.

I used M571 "e0heat" Qxx Sxx and it's working now. Also upgraded to 3.3 as @Phaedrux recommended.

@dc42 I'll admit, I have a specific use case that requires multiple components to turn on when extrusion (syringe) is active. No idea if it's feasible, but I would love to see multiple M571 commands supported so that each external component can have a dedicated output.

For now, my workaround is to define a M571 in tpreX.g for each tool. All my external components use 24v input, so I'll just connect all of them to the needed output and turn them on simultaneously.