CoreXYUVWA - 3rd gantry homing SOLVED

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.

wilriker

This post is deleted!

deckingman

@fma Moving the centre of gravity downwards inherently helps with stability, making the machine less top heavy and reducing it's tendency to "sway". I'm also moving the mass away from the centre line towards the sides. And I'm reducing the overall height of the machine. As well as aiding stability, moving some of the mass lower down will also reduce any flexing of the upper part of the frame, compared to having more mass at the top.

Don't forget that once it starts to "sway" the entire machine becomes a moving mass and is no longer static. So moving some of that mass lower to the floor will reduce it's tendency to sway.

What you describe with the nuts on a threaded rod and tightrope walkers applies when the contact point (tightrope or finger) moves. In this case, the floor doesn't move, so maybe a better analogy would be a low centre of gravity car vs a high sided SUV. Which one do you think can go faster round corners before it rolls over?

fma

About the height of the machine, only the distance from the floor to the moving mass matters. If the moving mass is still at the same height, total height does not matter.

And moving rolls lower will make them easier to energize, so what you gain on one side is lost on the other.

This is not a trivial problem!

Good luck

PS: your car example is different, and the maths are much easier (this is more or less a static problem).

deckingman

@fma The car example is just fine. Take two vehicles of the same mass, with the same friction and apply the same force. The one with the high centre of gravity will roll more and topple more easily than the one with the low centre of gravity. But I'm not going to argue. If you think that raising the centre of gravity makes a more stable structure than lowering it, that's fine by me. You believe whatever you want. I'll do what I normally do and ignore the people who say it won't work and build it anyway. It's been a pretty good strategy so far.

fma

I don't say that the car with the lower center of gravity is better in this case (of course it is not!), but this is not the same problem with your printer. In the printer case, this is a mode excitation problem; in the car example, this is a static problem.

What you really need to do, is ensure your rolls don't move (except turning). If they do, you will have troubles, whatever the position you put them.

Another (and I hope) better example: a door. Is it easier to push it close to the lids, or close to the handle? Changing the position where you push it is the same as moving the mass away from the point where you push.

The only issue of all this is resonances: you need to stay away from them, whatever you do.

And putting a mass at the rotation center (bottom of the printer) don't help at all regarding the rotation!

You believe whatever you want.

It work in both directions. I'm just trying to point some common problems with excitation and mass positions, that's all. I also have a tall printer, and I already experimented this. And tightrope walkers too.