Interested in using two Z axes

SupraGuy

On another note, the clay extruder is brilliant, I love it. I assume that the resultant prints would be kiln fired to make ceramic objects. Do you find that there is any issue with trapped air in between extrusion lines/layers?

At one point, I was looking at trying to extrude paraffin wax in order to do lost wax casting of metal objects, and thought of something like this as an alternative to a pellet hopper extruder which just doesn't seem to work tot he same kind of tolerances that I'd like.

tom_lauerman

@supraguy Many thanks! Yes, the pieces get fired, glazed, etc. We use typical clay you might use for pottery making or sculpture from our ceramic studio. The material is incredibly cheap, so we are looking at scaling up a lot. No problems with trapped air - usually those issues in clay have more to do with excessively thick clay that is unable to dry properly. With printing we can be super specific about wall thickness. If you are interested here's a bunch of objects made with this tool: link text . . . and a forum with tons of info on clay printing: link text

Many thanks again!

Phaedrux

Clay printing is so cool. I'd love to get my hands on one. Thanks for the links.

tom_lauerman

@dc42 It has been a year, but I am finally ready to implement this design of a printer in which the bed moves on the X and Y axes and there are two independent Z axes each with an extruder that can move up a bit to get out of the way. I am interested in following your suggestion that:
"using M584 commands in the tool change files. You would assign both motors to Z, also assign the individual motors to U and V axes, but hide the U and V axes using the P parameter in the M584 command. When selecting a tool, un-hide U and V, move U or V down a few mm to lower the tool, then hide U and V again. When freeing a tool, do the same except move U or V up the same distance."
Does this still seem like the best approach?
I'm going to get to work testing this finally, and I'll hopefully be able to share the results of this experiment soon.
Last Spring I experimented a bunch with a dual nozzle clay printer that did not move independently, which was fun - but I believe the nozzles "see-sawing" up and down will improve the quality of the process a lot. If anyone is interested in the fixed nozzle dual color clay experiments, I wrote them up here: https://wikifactory.com/@tom/stories/dual-color-clay-printing-experiences-spring-2019

Danal

Two steppers, each defined as an axis, and g-code to manipulate them is well within the capabilities of Duet/RepRap.

Mechanical swapping between the two extruders based on a single servo or stepper seems a very predictable approach as well.

There is probably no "right" or "wrong", and maybe not even a "better". It is much more a philosophical choice based on what YOU like.

Me, personally, I'd do the two stepper/axis/g-code thing. That's because I am very comfortable with Duet/RepRap configuration in specific and G-Code in general. I can see where a person who was more comfortable with mechanics (than code) would go the other route.

dc42

@tom_lauerman said in Interested in using two Z axes:

Does this still seem like the best approach?
I'm going to get to work testing this finally, and I'll hopefully be able to share the results of this experiment soon.

I think that approach should work well, but I have not tested it.

tom_lauerman

@dc42 Many thanks everyone, I understand how to do this a little better due to the wonderful Duet Gcode documentation available, specifically this and this. I'm travelling for the holidays presently, but hope to test this on the machine I have built with two Z axes very early in the new year. I'll share when I do.

tom_lauerman

A belated Happy New Year!
Happy to say I'm making progress with this build. I've completed designing/constructing the hardware, updated to firmware version 3.0 and I have the two Z axes both moving beautifully in a synchronized fashion. I have also mapped the two Z motors to axes U and V as recommended. What I'm stuck with presently is how to hide the U and V axes. I've read over the documentation on the M584 command, but the U and V axes keep showing up on my web control interface despite a few klutzy attempts to hide them. Wondering if someone can clarify how to hide the U and V. Here is the line I use to set the drives (each tool uses two extruder motors):

M584 X0 Y1 Z2:7 U2 V7 E3:4:5:6 ; set drive mapping

deckingman

@tom_lauerman M584 P3 will show 3 axes so will hide U and V. M584 P5 will bring them back.

tom_lauerman

@deckingman That worked wondefully. Many thanks for your prompt response and suggestion. Now to implement the hiding/unhiding in the tool change process to get the "teeter totter" going . . .

deckingman

@tom_lauerman Glad to help. It's how I individually home my CoreXYUVAB before combining the axes back to simply CoreXY.

tom_lauerman

OK, so now I've successfully hidden the U and V axes ( thanks @deckingman !), and the machine is switching from tool 0 to tool 1 when expected, but not executing the "teeter totter" effect I am going for in which the tool moves up or down when not in use. For example, I tried using these tool change scripts:

; tpost0.g
; called after tool 0 has been selected
M584 P5 ; unhide U and V axes
G1 H2 U-5 F6000 ; lower U (right tool) -5mm
M584 P3 ; hide U and V axes again

; tfree0.g
; called when tool 0 is freed
M584 P5 ; unhide U and V axes
G1 H2 U5 F6000 ; raise U (right tool) 5mm
M584 P3 ; hide U and V axes again

But the tool did not move up or down, just functioned like a standard (non teeter totter) dual extrusion setup.

Any insights would be much appreciated!

deckingman

@tom_lauerman With all the axes visible, what happens if you nudge U and V via the web interface? Or alternatively, what happens if you send the commands in the tool change macros one line at a time?

tom_lauerman

Thanks for the suggestion @deckingman , I tried the first approach you mentioned, nudging the U and V with all axes visible. This gave some surprising results. It seemed that both U and V were able to move independently, however, not at all at the speed or distances one would expect. So if I tell V to move up 5mm it might only move up 1mm or less. Same with U.

Curiously, with axes unhidden the Z axes no longer functions correctly. I ask it to move up or down and it does not. When I hide the UV again, the Z works fine - tell Z to move 10mm up or down and both axes move up or down 10mm.

I got the sense that the order I tried things in mattered too, that possibly sending a command to U or V had a negative impact on the functioning of Z, but I'm not sure about that.

I was not sure if I needed to input all the information for these "phantom" axes, such as microstepping, motor current, steps per mm, etc. I tried it both ways (with all that info supplied for U and V, and without) with similar results.

dc42

@tom_lauerman said in Interested in using two Z axes:

Curiously, with axes unhidden the Z axes no longer functions correctly. I ask it to move up or down and it does not. When I hide the UV again, the Z works fine - tell Z to move 10mm up or down and both axes move up or down 10mm.

I can understand that. The firmware calculates the positions for the motor in order. So it first calculates the U and V motor positions needed to position Z correctly, then if the U and V axes are not hidden, it recalculates them for the correct U and V positions. However, when U and V are visible, I would expect you to be able to nudge them by the correct amounts, assuming you haven't messed with the Z axis microstepping (because that would reprogram the U and V motor drivers with the new microstepping).

tom_lauerman

Thanks @dc42 . I double checked and confirm that the U and V are moving at different speeds and distances when operated independently versus when moved together as "Z". Also, if I move U and V independently for awhile they no longer move in a synchronized fashion as part of Z.

Of course, before I can move anything I have to Home Z and U and V. Could there be something in the homing routine that causes an issue? I am using a simple G92 Z0 command to set home for Z, and a similar command for U and for V. Without homing first of course nothing will move. I have no endstops or probes setup on these axes at this time.

I put the M584 P5 command on its own line and the Z operation works better with all axes visible - still having the U and V issues mentioned above. Here's how I have it set up presently:

M584 X0 Y1 Z2:7 U2 V7 E3:4:5:6 ; set drive mapping
M584 P5 ; show all drives (XYZUV)

tom_lauerman

This post is deleted!

tom_lauerman

Still sleuthing around, I noticed that the "requested speed" shown on the Duet Web Control interface when moving the U or V axis was 100mm/s, while the requested speed shown when moving the Z axis is 3mm/s. Here is an image showing this for @dc42 @deckingman or anyone else who might have insights. Many thanks in advance for any assistance.

droftarts

@tom_lauerman Can you post your config.g? I'd guess you have different motor settings for U and V, when they should be the same as Z.

Ian

tom_lauerman

@droftarts Certainly, thanks for the suggestion. I have uploaded the file to this reply. Let me know if you'd rather I just cut and paste it into the text of the reply. (I'm not sure what the best practice for this on the forum is). Thanks again! Not sure how much it matters, but I am using the new 3.0 firmware.

config.g