CoreXYUVWA - 3rd gantry homing SOLVED

deckingman

OK, So I think I've figured out a way to home all these axes and gantries without needing any changes to firmware but I need DC42s input when he gets time (no hurry).

To save any confusion, on a Corexy, both X and Y motors contribute to motion so it's better to all them Alpha and Beta.

At the moment, the XY part of the CoreXY has two alpha motors and 2 beta motors for normal printing. Axes U and V are for homing only and are otherwise hidden. When homing, one Alpha motor and 1 Beta motor are assigned to the XY axes and the second Alpha and Beta motors are re-assigned to UV.

The idea I have is to add the third pair of motors to XY for normal printing, so there would be 3 Alpha motors and 3 Beta motors (instead of 2). I would home XYUV as I do now. Then I could map the third pair of motors to UV (instead of the second pair), re-assign the end stop switches for the third gantry to UV, then repeat XYUV homing (but this time it would do gantries 1 and 3 instead of gantries 1 and 2). Finally assign the end stop switches back to the default UV gantry, re-assign all 3 alpha and beta motors back to XY. This would all take place within the homing macros for homex, homey and homeall.

It's a bit complex but I think it would work. Have I missed anything?

In config.g M584 is currently X0:3 Y1:4 Z2 U10 V11 E5:6:7:8:9. This would need to change to something like M584 X0:3:10 Y1:4:11 Z2 E5:6:7:8:9 U12:13 V14:15 or some such.

Then for homing first pass it would be as now i.e M584 X0 U3 Y1 V4 P5

For homing second pass (the 3rd gantry) they get re-mapped to
M584 X0 U10 Y1 V11 P5

Then at the end of homing, they get mapped back to where we started.

Need your input David (DC42) - I appreciate you are busy getting ready for the TCT show etc, so as and when......

wilriker

@deckingman I am not David but basically it might work like this except for a small hiccup in your second M584 definition

M584 X0:3:10 Y1:4:11 Z2 E5:6:7:8:9 U12:13 V14:15

because there you assign 16 drivers to all axes. It probably would rather look like

M584 X0:3:5 Y1:4:6 Z2 E7:8:9:10:11 U3:5 V4:6

Note that I remapped some of your drivers here on purpose because I just stumbled across something that might be a problem. Documentation of M584 states

On the Duet WiFi and Duet Ethernet, if you configure multiple drivers for an axis, either all of them must be TMC2660 drivers on the Duet or a Duet expansion board, or none of them must be. This is to facilitate dynamic microstepping and other features of the TMC2660.

I don't know if E counts as an axis here. If so this won't be possible until the aforementioned plan to make all 12 drivers "smart" has been completed.

deckingman

@wilriker With my current CoreXYUV, the U and V motors have to be assigned to unused axes in config.g. That's what David told me anyway so that's what I use. I'm fairly sure that you can't double up and assign the same drive to multiple axes as you have it. "E" also count as axes.

So you are right, and it sounds like I'll have to wait until all 12 drivers can be smart. Maybe this upgrade might have to wait for Gen3 Duet

wilriker

@deckingman said in CoreXYUVWA:

I'm fairly sure that you can't double up and assign the same drive to multiple axes as you have it.

You can, I just tried. I added a U axis which shares the same driver as the Z axis. This is because with M584 you map drivers to axes and not the other way round. And this limits you to a max value of 11 (12 zero-based). Trying to use M584 <XYZUVWABC>12 or any number above will return an error.

"E" also count as axes.
So you are right, and it sounds like I'll have to wait until all 12 drivers can be smart. Maybe this upgrade might have to wait for Gen3 Duet

Might be. Or you limit yourself to your 3 color Diamond. It would work then.
But I have not yet given up. @dc42 put this point in his todo list so there is a path that can make this adventure possible without replacing all the electronics.

deckingman

@wilriker So why did David tell me to map unused drives to U and V I wonder? For whatever reason, I have to use M584 X0:3 Y1:4 Z2 U10 V11 E5:6:7:8:9 P3
in my existing config.g. Then re-map U to 3 and V to 4 when homing. Using M584 X0:3 Y1:4 Z2 U3 V4 E5:6:7:8:9 would make a lot more sense but for whatever reason, it won't work. Unless something has recently changed in firmware.......

wilriker

@deckingman I don't know. I just tried it and mapped driver 0 and 1 to a new and additional U axis, i.e. the same motors as X and Y. I can use all three axes individually and as one would expect. I did not go as far as creating a homeu.g but only disabled unhomed movement blocking and could jog them around. X and Y of course only moving the respective axis and U moving both axes at the same time.

So it might very well be that there was some change in the firmware recently.

Also I would rather configure the individual axes in config.g (i.e. M584 X0 Y1 Z2 U3 V4 E5:6:7:8:9) and would do the combining of the motors in my start code. Hm, now that I think of it. Maybe he said you should map these axes to unused drivers to not accidentally jog them around and get them out of sync somehow. If you would print after that without rehoming everything the axes could crash. But that is just an idea.

deckingman

@wilriker Perhaps there is a clue in the CoreXYUV kinematics class that DC created? I don't know - he must have done it for a reason and I guess he knows the firmware better than anyone.

I definitely don't like the idea of leaving the combination of axes to the start gcode. What if just want to move the head and extruders out of the way for any reason? If they aren't combined by default and the head moves independently of the extruders, I could end up tearing all the Bowden tubes out of either the extruders or the heat sinks. They must move in sync at all times apart from the fine homing. Even for course homing, they must move together or the Bowden tubes will get torn out.

Anyway, we're just second guessing everything here so unless and until DC42 comments, there dosn't seem much point in trying to pursue this further.

I'm starting to lose the will to live so I think I give up on the idea. I never thought that asking a simple question would lead to so much discussion and confusion.

wilriker

@deckingman I'm sorry if I added to the confusion. That wasn't intended. Best forget about my comments on drive mappings because you are right here that @dc42 surely had his reasons to tell you to do so. I will check the source code again before making any more uneducated guesses about why that is - and if I don't understand the source code so then no more guesses either.

I am still very willing to help you with this on firmware side as well as (external) driver setup.

streamliner

@deckingman You got my attention. We should talk about this. What's your schedule in the next 10 hours?

--David

deckingman

@streamliner said in CoreXYUVWA:

@deckingman You got my attention. We should talk about this. What's your schedule in the next 10 hours?

--David

Same as ever - I'm always open to emails but rarely in a position to drop whatever I'm doing and join a chat session.

dc42

I'm not sure you need new kinematics or even additional axes. How about this:

Home the existing axes as normal, with just the original XY motors assigned to X and Y
To home the new motors, temporarily assign them to the XY axes instead of the other motors (M584), switch to using motor stall detection for X and Y (M574), and home them (you will need to have the new motors connected to the internal drivers to use stall detection - perhaps the UV motors can use the CONN_LCD connector)
Then assign both the original and the new motors to X and Y.

deckingman

@dc42 said in CoreXYUVWA:

I'm not sure you need new kinematics or even additional axes. How about this:

Home the existing axes as normal, with just the original XY motors assigned to X and Y

To home the new motors, temporarily assign them to the XY axes instead of the other motors (M584), switch to using motor stall detection for X and Y (M574), and home them (you will need to have the new motors connected to the internal drivers to use stall detection - perhaps the UV motors can use the CONN_LCD connector)

Then assign both the original and the new motors to X and Y.

Thanks for taking the time David - I appreciate that you must be really busy right now. What you propose sounds like a variation of what I came up with but using stall detection instead of reconfiguring end stops. See post about 10 up from here, date and time 3 Sep 2018 15:19

It just leaves the question of connecting external drives to the Conn-LCD connector. Other than for homing, U and V are normally mapped to XY so would they still work if connected to Conn-LCD? I'd plan on using the same drivers (TMC 2660) because @wilriker came across a note saying that all drivers must be TMC2660 or none of them. Are there any other "gotchas" to look out for?

Edit. If we can do this with the third gantry, why did we need CoreXYUV in order to home the second gantry? Is that because they need to move in sync when doing the course home but in this case, it won't be necessary?

dc42

@deckingman said in CoreXYUVWA:

If we can do this with the third gantry, why did we need CoreXYUV in order to home the second gantry? Is that because they need to move in sync when doing the course home but in this case, it won't be necessary?

Correct.

deckingman

One other thought. Do I need to even bother with stall detection? I don't need precise positional accuracy - just to prevent hard crashes in the event that this gantry gets knocked out of position when the power is off. So I'm thinking that if I just set physical stops at the axes minima, stet motor currents really low, then do a long slow move so that the gantry will always hit the stops no matter where it started from, and simply let the motor stall and stayed stalled for as long as it takes to complete the move. Would that harm the motor or driver?

I'd do this first with only those motors mapped to XY, then do the "normal" XYUV homing as I do now then assign all 3 motors to XY. Then put all the motor currents back up.

wilriker

@dc42 said in CoreXYUVWA:

I'm not sure you need new kinematics or even additional axes. How about this:

Home the existing axes as normal, with just the original XY motors assigned to X and Y

To home the new motors, temporarily assign them to the XY axes instead of the other motors (M584), switch to using motor stall detection for X and Y (M574), and home them (you will need to have the new motors connected to the internal drivers to use stall detection - perhaps the UV motors can use the CONN_LCD connector)

Then assign both the original and the new motors to X and Y.

What I don't see here is how to get around the limitation stated in documentation of M584

On the Duet WiFi and Duet Ethernet, if you configure multiple drivers for an axis, either all of them must be TMC2660 drivers on the Duet or a Duet expansion board, or none of them must be. This is to facilitate dynamic microstepping and other features of the TMC2660.

Because at print time the X and Y axis would have to be combined of three motors each (real X/Y axis, U/V for extruders plus W/A for counter-weight). Plus Z and 5 extruders this would use all 12 available steppers but at least two of them would not be on Duet or DueX5 but on CONN_LCD. What am I missing?

dc42

The problem with mixing TMC2660 and other drivers on the same axis is that any M350, M906, M913 or M915 you send for that axis would be rejected. Also, external drivers need extended step pulse timing, which isn't ideal if you want high speeds and/or high microstepping.

The best bet may be to use the 2 external drivers for extruders. Or talk to us nicely about beta testing the next generation Duet a few months from now

wilriker

@dc42 said in CoreXYUVWA:

The problem with mixing TMC2660 and other drivers on the same axis is that any M350, M906, M913 or M915 you send for that axis would be rejected. Also, external drivers need extended step pulse timing, which isn't ideal if you want high speeds and/or high microstepping.

If these external drivers are TMC2660-BOB (breakout boards), would that work? I think they would have to be integrated via SPI but then this should work better than arbitrary other drivers, shouldn't it?

The best bet may be to use the 2 external drivers for extruders. Or talk to us nicely about beta testing the next generation Duet a few months from now

@deckingman Time to polish up your flirting.

deckingman

@dc42 said in CoreXYUVWA:

The best bet may be to use the 2 external drivers for extruders. Or talk to us nicely about beta testing the next generation Duet a few months from now

CoreXYUV with 5 extruders and a mixing hot end is sitting here ready and waiting. By that time it will have this additional gantry too. (And possibly the other thing that I have mentioned). In a reciprocal arrangement, if you talk to me nicely, I might even convert it from 3 lead screws with a single Z motor, to 3 independently driven screws. Oh, and why not 5 filament monitors as well.

deckingman

I have a plan.

For now, and to get this up and running I'll just drop back to the 3 colour Diamond and wait for the Gen 3 duet to go back to 5 (or more) colour. Then I can use 2 of the existing E motors to drive this additional gantry. If I'm desperate to use the 5 colour, I can always swap the 2 sets of stepper wires and change the configuration back to what it s now.

Also, although not particularly related to this thread, I'm redesigning the top section so that the filament spools will sit on the sides, rather than the top. So this extra gantry can sit more or less where the top of the printer is now without having to extend the height significantly. This also shifts the weight of the spools (up to about 6Kgs depending on how full they are) down by about 300mm, so lowering the centre of gravity, which will help with stability.

fma

@deckingman said in CoreXYUVWA:

This also shifts the weight of the spools (up to about 6Kgs depending on how full they are) down by about 300mm, so lowering the centre of gravity, which will help with stability.

I don't think so. The moving mass should be as low as possible (ie close to the ground, which can be seen as the pivot of your 'shaking' machine), but static mass should be as far as your can from this pivot. This way, you increase the moment of inertia, and it becomes more difficult to move (shake) the machine

This is how tightrope walkers don't fall: they use a large stick, to increase their moment of inertia. Same, it is easier to keep a stick standing on your finger if it has a mass on its top. You can make the test with a simple M8x300mm threaded rod. With and without nuts at the top. You'll easily see the difference.