CoreXYUVWA - 3rd gantry homing SOLVED

JoergS5

@deckingman I had one more idea: in robotics or helicopters one wants to balance out by counter movements. This is similar to your problem, where you want to even out a movement (the vibration). So a different approach is installing sensors (gyro) which analyze the vibrations and use your counterweights to diminish them. This would solve the problem that you can react to time delays which may occur, also.

deckingman

@joergs5 If you can, then definitely install the machine on a sound base - concrete would be ideal. I can't do that with mine because it sits in an upstairs bedroom.

I don't see the point of adding a gyro to analyse the vibrations. It's an added layer of complexity to what is essentially a simple problem. Its just a matter of applying an equal and opposite force so that one cancels out the other. So a gantry moving a mass at the same speed and acceleration but in the opposite direction is all that's required.

As the cancelling mass will be higher than the print head and extruder mass then there will be a leverage effect, so the only tuning will be to find the correct mass needed. This is easily done. I can measure the deflection at the top of the printer with a dial gauge, then gradually add mass while running the print head and extruders back and forth at high speed/high accelerations until the deflection is zero. I plan to use lead shot for the mass.

Most of the mechanical design is now done and I'll start printing parts and ordering motors and aluminium extrusion. It's a simplified CoreXY gantry with a single X rail. The X carriage is a hollow cuboid into which I can add the lead shot. I'm not too worried about the gantry sagging or really precise positional accuracy - it's just a lump of mass being moved around so as long as it's free to move and travel the correct distance, that's all that is required.

I did consider using axis that were half the length, doubling the mass and halving the steps per mm for those motors. It would be more compact, but it's hard to fit without a fairly major re-design of the printer.

I'll need some help getting the two additional external stepper drivers interfaced but @wilriker has said he can help me with that.

I'll do a write up on my blog when it's all done and report the findings (good or bad).

JoergS5

@deckingman

The concrete socket is at the optimal timing, as I installed an underfloor heating in the workshop and not finished the laminate yet. I will do it this way, adding a socket for the 3d printer also.

I am curious how your project is going!

P.S. vibrations can cause a fall (unexpected ones!), so please attach a security rope at the ceiling.

wilriker

@dc42 I looked into the CoreXYUVKinematics.(h|cpp) and it will be easy to extend/copy-paste this to CoreXYUVWA (I will also add CoreXYUVW if you think it makes sense).

I found something in your BugList.txt that is very relevant to this

M569 command to allow selection of smart/dumb driver [...] also allow all 12 drivers to be smart

Can you tell me more about that especially the second half? What do you plan there? And what needs to be done? Did you think about TMC2660-BOB when writing this? If that is not to be more public you can of course email me. I can keep secrets.

RCarlyle

@deckingman can you fill me in on why you need separate controlled axes and not just run multiple drivers off the same step/dir signals? I know stall-homing isn’t great for CoreXY, so why not just manually position the axes where they are supposed to go at startup, home CoreXY with switches like normal, and rely on dead reckoning for the secondary and tertiary gantries?

deckingman

@rcarlyle said in CoreXYUVWA:

@deckingman can you fill me in on why you need separate controlled axes and not just run multiple drivers off the same step/dir signals? I know stall-homing isn’t great for CoreXY, so why not just manually position the axes where they are supposed to go at startup, home CoreXY with switches like normal, and rely on dead reckoning for the secondary and tertiary gantries?

That's what I'll likely end up doing with this third gantry. It's how I started out with the second one too. But when I was working on the machine or just changing filament, I had a habit of inadvertently nudging the extruder gantry and forgetting to line it up again by eye before I did the homing. So I had quite few crashes which became a bit tiresome. I always drop the motor current when homing so it didn't do any damage but it was annoying. I posted the issue on these forums and David kindly implemented CoreXYUV kinematics for the purpose of homing. Now I don't have to worry about knocking one gantry out of alignment with the other.

What happens is that the motors are mapped to XY and UV for homing. Then once homing is completed fr all 4 axes, both pairs of motors are re-mapped to X and Y, and U and V are hidden. So, for printing it's just like a CoreXY which happens to have 2 alpha motors and 2 beta motors.

There is no problem mapping the third gantry motors to X and Y but in this case, I'd just reverse the motor directions in config.g so that the axes do the opposite thing. If I could also home this third gantry independently, it would be nice but it's not a huge issue. It'll work but I'll just have to remember to "eye ball" it before I start the homing sequence. Or as I've said previously, I can build some "slippage" into the system.

I summary, it doesn't need to be CoreXYUVWA to work, but it would be nice if it was possible.

fma

Ian, you could show a popup when homing, and wait for user (you) to put the gantry in the correct position, then click OK...

deckingman

@fma Yes I know. there are all sorts of work arounds and things that I can do.

@all

Sorry if his seems blunt or harsh but getting back to my original post, and the reason I started this thread, all I want to know is would it possible to home an additional WA gantry, given that I currently use CoreXYUV? Or if it isn't currently possible, then could it be possible?

If the answer to that is no, then that's fine. If the answer is yes, then what do I need to do?

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?