Core XYU or XYUV

  • @curlypaul Another thought. Maybe it is a motor mapping thing and one pair of motors never moves as expected. But when you reduce the motor current (as you do for homing) the holding current isn't enough to hold them in position. So it looks like you get correct movement and without angry noises but that's just because the lower holding current is masking the problem with stationary motors. That would be easy to test - just leave out that final M913 X100 Y100 from home Y.

    Try that - Home Y but leave the motor current reduced. Then try moving Y. If Y them moves without angry noises, we know it's a motor mapping/motor direction thing.

  • I thought you were onto something there !

    But alas.. the UV motors are still not moving after homing, motor current is definitely reduced as now 'x' carriage twitches as I try to move Y

  • @curlypaul I'll have to sleep on it. I can't get my head around why it all works fine during homing but after homing, the exact same commands as used in homing make things go haywire. Just doesn't make any sense........

  • @deckingman - No 😞
    I've had enough for today anyway ! 😥

  • @curlypaul said in Core XYU or XYUV:


    .. the UV motors are still not moving after homing, motor current is definitely reduced as now 'x' carriage twitches as I try to move Y

    seems to me like my dual gantry CoreXYUV. Where "normal movement" is with multiple motors mapped to axes. But to home them I map individual motors to individual axes, home them, then re-combine them.

    So my config.g starts with this (actually it's CoreXYUVAB - just ignore the AB)
    M584 X3.2:0.0:0.2 Y3.1:0.1:0.3 Z3.0 U0.0 V0.1 A0.2 B0.3 E1.0:1.1:1.2:2.0:2.1:2.2 P7
    I also use M669 with custom matrix for the AB gantry but that's of no concern here.

    It's also RRF 3 so the motors are defined by Board:Position (3.2 means driver2 on expansion board 3).

    As you can see, it start with U and A also mapped to X, and V and B mapped to Y.

    Then at the start of my home all, to home X and Y I do this:
    M584 X3.2 Y3.1; temporarily map X3.2 and Y to 3.1 only

    That removes the U and A from X and the V and B from Y.
    So then I home X,Y U,V A and B individually.

    Then I recombine U and A with X, and V and B with Y and hide those other axes using this.
    M584 X3.2:0.0:0.2 Y3.1:0.1:0.3 P3

    So I'm pretty sure you need to do something long those lines for your V and Y axis. But your X and U need to run independently and I don't know how to handle that combination.

    Maybe it isn't CoreXYUV in the true sense and you need to use M669 with some weird matrix (but then DC said it was CoreXYUV).

    Not sure if I need sleep now or caffeine 🙂

  • Some progress today 🙂

    Update on previous first though, Adding actual endstops make no difference
    My issue still appears that in CoreXYUV - M669 K8 - After homing X,Y, and U My 'V' axis motors do not move when Y is commanded. As a note though the UV Motors do move and correctly when homing Y

    So, clutching at my last remaining straws, I tried CoreXYU/K5 mode, It's working as it should

    I'm baffled - I'm going with it for the time being to move onto wiring it all up

    I've atttached files, just in case anyone can see something blindingly obvious, as I still can't

    homey.g homex.g homeu.g config.g

  • @curlypaul It makes sense to me, because you don't have a separate "V" axis. That is to say, Y and V are one and the same thing. So logic would dictate that it ought to be CoreXYU. But DC said it should be CoreXYUV and he wrote the firmware so he should know (unless he just didn't look closely enough to spot your common gantry? ). I don't enough about the kinematics matrices to make any sort of informed judgement.

    User @wilriker told me what command to use in my CoreXYUVAB which is this:
    M669 K8 A0:0:0:0:0:1:1 B0:0:0:0:0:1:-1

    ........but I have no idea how he arrived at the values for A and B - I just put in what he told me and it works. Not that any of this is relevant to your situation.......

  • Quick update.. All running on well on 2.02 for some strange reason, but have managed a couple of dual colour prints..!

    Few things to sort out, but getting there bit by bit 🙂

  • @curlypaul Congrats! Those prints don't look to scruffy at all!.

  • @deckingman - Thankyou 🙂

    Not too bad - bit of tuning required i'll admit, but very happy so far

Log in to reply