Core XYU or XYUV
-
Endeavoured to make a video of whats going on..
This is with carriages swapped from original - as mentioned in previous post
-
@curlypaul Sorry for the delay - had a power outage here. Did you try sending G1 H2 Ynn to see if that works, then G1 Ynn (without the H2)?
Then maybe try G1 H2 Vnn. If V goes the opposite way, then that might explain why Y (which is Y and V) goes haywire.
-
@curlypaul Also, after homing, try sending M584 P3 to see if that makes any difference.
-
@curlypaul Edit - to attempt to home V you'll need to use M584 P5 to make it visible.
-
@deckingman - No worries - i Had to walk away from it for a bit anyway !
So I tried the H2 and without - I just what can only be described a machine gun noise - mostly from the 'x' carriage
After the M584 P5, the 'U' carriage just twitches
-
Right - Think spotted something !?
after homing x,y and u - it appears to me that the lower pair of 'U' axis motors aren't moving when I try to move Y -
@curlypaul That's weird. Because a G1 H2 Ynn move is what you have in your homing file and you say that homing file works fine (in fact your video shows it working fine). So I really can't understand why sending exactly the same command outside of homeY doesn't work. If you were re-mapping motors or some such I could understand it, but you aren't doing that. The only thing you do at the end of homeY is restore the motor currents and change the endstop settings but none of that should make any difference.
I've really run out of ideas - we need DC42 or someone else equally knowledgeable to look at this. Clutching at straws but maybe try removing the final M574 at the end of homeY. I really don;t see why that should make any difference but it's the only thing (apart from motor currents) that gets changed after Y has been homed.
-
@curlypaul said in Core XYU or XYUV:
Right - Think spotted something !?
after homing x,y and u - it appears to me that the lower pair of 'U' axis motors aren't moving when I try to move YYes I figured something like that was happening - hence the "angry noises". The question is why (when they all move as expected during homing). And why again, when you send G1 Ynn H2 which is exactly the same thing as your homing move.
-
@deckingman - I'm going to try to add switches instead of the sensorless see if that makes a difference ?
-
@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:
This
.. 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 onlyThat 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 P3So 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 YSo, 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
-
@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
-
Hi, very good job, and very beautiful aluminium parts.
