Interested in using two Z axes

[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

[droftarts]

@tom_lauerman

M584 X0 Y1 Z2:7 U2 V7 E3:4:5:6                                   ; set drive mapping						
M584 P5          						 ; show all drives (XYZUV)
M350 X16 Y16 Z16 E16:16:16:16 I1                                 ; configure microstepping with interpolation
M92 X400.00 Y400.00 Z400.00 E30000.00:13000.00:30000.00:13000.00 ; set steps per mm
M566 X900.00 Y900.00 Z12.00 E120.00:120.00:120.00:120.00         ; set maximum instantaneous speed changes (mm/min)
M203 X6000.00 Y6000.00 Z180.00 E1200.00:1200.00:1200.00:1200.00  ; set maximum speeds (mm/min)
M201 X20.00 Y20.00 Z250.00 E250.00:250.00:250.00:250.00          ; set accelerations (mm/s^2)
M906 X2000 Y2000 Z2000 E2000:2000:2000:2000 I30                  ; set motor currents (mA) and motor idle factor in per cent
M84 S30                                                          ; Set idle timeout

You haven't put motor speeds in for U and V axes, so it will be using the defaults, which won't reflect the speeds you want. For each line of the above, add in a value for U and V that's the same as Z, eg:

M566 X900.00 Y900.00 Z12.00 U12.00 V12.00 E120.00:120.00:120.00:120.00         ; set maximum instantaneous speed changes (mm/min)

Ian

[tom_lauerman]

@droftarts Well, that's working much better. Sorry, seems like a noob-ish mistake on my part. I assumed U and V would somehow inherit those settings from Z. Many thanks again, moving on to the next challenge.

[deckingman]

@tom_lauerman I haven't looked at your config g because I'm a long way from home and only have my 'phone with me but following on from what the other Ian said, anything in your config.g which has parameters for Z should also have parameters for U and V. As well as speeds "jerk" and acceleration, that also included axes limits. HTH.

[tom_lauerman]

@deckingman Many thanks to all of you Ians for getting this sorted. The printer is moving just the way I was hoping it would, with the teeter totter effect. Now I've got to load material, do some printing, and make lots of tests and adjustments, etc. I'll post some images when I've made some more progress, hopefully soon. This forum is really great!