Could do with some help with sensorless homing on a CoreXY
-
@dc42 said in Could do with some help with sensorless homing on a CoreXY:
................................
I'm wondering whether the back emf of those motors is too low at the very low motor current you are using, but I understand why you don't want to use a higher current.HTH David
Hmm. Well I think there is a real risk of some physical damage happening if I try and increase the current.
Maybe sensor less homing isn't an option with these motors and I have to come up with a plan B.
Any ideas? I do have a couple of spare estop connectors on the Duex5 and I could fit a couple of switches easy enough.
-
As a temporary solution, I've made use of M291 in my homing files to prompt me to move the load cancelling gantry to the appropriate position. Along with reducing motor currents, this will hopefully be enough to prevent anything nasty happening - at least until I can come up with a better plan.
-
You could define the two additional motors as axes A and B while homing them, allowing you to use endstop inputs 5 and 6 aka E2 and E3 assuming there is no W axis.
-
@dc42 said in Could do with some help with sensorless homing on a CoreXY:
You could define the two additional motors as axes A and B while homing them, allowing you to use endstop inputs 5 and 6 aka E2 and E3 assuming there is no W axis.
Thanks. I'll give that a go when I get chance. E2 and E3 are currently used for axes maxima and another switch to trigger an emergency stop, but I can move them to E4 and E5 easily enough.
-
@dc42 OK, so I've hooked up a couple of switches but still not having a great deal of success. I get movement in the X direction for axis A but no movement in the Y direction for axis B. Then after "attempting" to home A and B, my homeall.g file then homes XYU and V as it has always done, but after these have been homed, no movement in the X direction is possible for any of the gantries. Homeall. g normally moves to the centre of the bed for Z probing but after doing XYU and V., it only moves in the Y direction. However, movement in Y works fine for all 3 gantries.
It's likely that I have missed or configured something incorrectly but after a few hours, I still can't find my mistake.
My annotated homeall.g is as follows:
; homeall.g
; called to home all axes
; Use This for Dynamic Load Gantry - mapping is different*; start by warming the hot end so that any oozed filamnt is molten
TO; select a tool - any one will do
M104 S140; heat to 140 but don't wait;********** COMMANDS FROM HERE ADDED FOR UPPERMOST (3RD) GANTRY ********
M584 X0:3:6 Y1:4:9 Z2 U10 V11 E5:7:8 P3; make sure mapping is as per config.g to start with
M906 X400 U400 Y400 V400 Z1200 ; reduce motor currents
M584 A6 B9 P7; create A and B axes for upper gantry
M574 A1 B1 S1 ; create end stops E2 and E3 for the new A and B axis
M350 A16 B16 ; configure microstepping for A and B
M92 A80 B80 ; configure steps per mm for A and B
M566 A600 B600; inst speed change
M203 A50000 B50000; max speed
M201 A1000 B1000; accel
M208 A0 B0 S1; axes minima
M208 A380 B380 S0 axes maximaG91 ; set to use relative coordinates
G1 A-380 B-380 F4800 S1 ; move fairly quickly until one of other end stop switches triggers
G1 A-380 S1 ; course home A
G1 A10 F600 ; move back a few mm slowly
G1 A-380 F360 S1 ; fine home A
G1 B-380 F4800 S1; course home B
G1 B10 F600 ; move back a few mm
G1 B-380 F360 S1 ; fine home B
; *****DURING THE ABOVE, THERE IS "A" axis MOVEMENT IN THE X DIRECTION
; *****BUT NO "B" axis MOVEMENT IN THE Y DIRECTION
; ***** AND THE A(X) AXIS SEEMS TO BE IS LOOKING FOR THE B(Y) ENDSTOP; END OF ADDITIONAL COMMANDS*
M584 X0 U3 Y1 V4 P5; temporarily map drives to U and V axes - have to map both axes even thought only U is being used due to both motors being employed per axis
G91 ; set to use relative coordinates
G1 Z5 F600 ; move bed down 5 mm
G1 X-380 U-380 Y-380 V-380 F4800 S1; move all 4 axes fairly quickly until one or other triggers a switch
G1 X-380 U-380 F4800 S1; now move just X and U fairly quickly left until one or other triggers a switch
G1 X-380 S1; course home X
G1 U-380 S1; course home UG1 X10 U10 F600 ; Go back a few mm
G1 X-380 U-380 F360 S1; Move slowly to X and U axis endstops once more and stop when one triggers
G1 X-380 F360 S1 ; fine home X
G1 U-380 F360 S1 ; fine home UG1 Y-380 V-380 F4800 S1; now move Y and V fairly quickly left until one or other triggers a switch
G1 Y-380 S1; course home Y
G1 V-380 S1; course home VG1 Y10 V10 F600; Go back a few mm
G1 Y-380 V-380 F360 S1; Move slowly to Y and V axis endstops once more and stop when one triggers
G1 Y-380 F360 S1 ; fine home Y
G1 V-380 F360 S1 ; fine home VM584 X0:3:6 Y1:4:9 Z2 U10 V11 E5:7:8 P7; add dynamic gantry to XY ; map all 3 gantries to X and Y
G90; set to absolute coordinates
; ******* FROM THIS POINT ON, NO MOVEMENT IN THE X DIRECTION IS POSSIBLE
; ******* JUST NOTHING HAPPENS WHEN ANY X MOVE IS ASKED FOR
; ******* THIS APPLIES TO ALL 3 GANTRIES
; ******* BUT Y DIRECTIONS MOVES WORK FINE FOR ALL 3 GANTRIES AS DOES Z
;******** THIS BEHAVIOUR PERSIST AFTER HOMING AND THE MACHINE HAS TO BE RESET.G1 X180 Y180 F12000; move all 3 gantries to more or less the centre of the bed
; **** AS STATED ABOVE, THE X DIRECTION COORDINATE NO LONGER HAPPENS
M109 S140 ; continue heating bed to 140 but this time wait
G30
G91 ;relative
G1 Z5 F300
G90 ; back to absoluteM906 X1800 U1800 Y1800 V1800 Z1800 ; set motor currents back to defaults
M104 S0; set hot end temp back to zero
-
Above post deleted - me being stupid.
Edit. Post restored, I'm still probably stupid but not for the reasons I thought.
-
Also tried sensor less homing as above with motor currents set to 500mA but still no stall detected. At a bit of a loss as to what to try next.
-
This is just a shot in the dark but it feels odd to me that
M584 X0:3:6 Y1:4:9 Z2 U10 V11 E5:7:8 P3; make sure mapping is as per config.g to start with [...] M584 A6 B9 P7; create A and B axes for upper gantry M574 A1 B1 S1 ; create end stops E2 and E3 for the new A and B axis
this would work as intended. I mean the part where you first do the axes definition and then reassign drives to other axes and assume that E2 and E3 match to these axes. I looked into the source code and even though I did not understand everything I found I think you need to define the new axes in the right order in one command. Something like the following might be more correct:
M584 X0:3 Y1:4 A6 B9 Z2 U10 V11 E5:7:8 P3
I think it needs to be done like this because parsing
M584
does not really care about the letters being in strict XYZUVWABC order anymore but the order they are given is more or less responsible for the endstop-mapping. So in your current setup the endstops would be mapped toU
andV
.At least something to try.
-
@wilriker Thanks for that. It makes sense so I'll give it a try.
-
OK, so I've tried @wilriker's suggestion. Essentially, I've moved the creation of the A and B axes to config.g. So I have in config-g:
M584 X0:3 Y1:4 Z2 A6 B9 U10 V11 E5:7:8 P3;
followed by:
M574 Z0 S0 ; Define active low and unused microswitches
M574 X1 Y1 S1 ; Define active high microswitches
M574 U1 V1 S1 ; active high switches for when temporary U and V axes are employed during homing the upper XY
M574 A1 B1 S1;Then I've set all the other axis related parameters for all 7 axes (M350, M92, M566, M203. M201 etc).
After which I remap drives thus:
M584 X0:3:6 Y1:4:9 Z2 U10 V11 E5:7:8 P3; Remap A and B to X and YThen I've simplified the start of homeall.g so that it starts with this:
M584 X0:3:6 Y1:4:9 Z2 U10 V11 E5:7:8 P3; make sure mapping is as per config.g to start with
M906 X400 U400 Y400 V400 Z1200 ; reduce motor currents
M584 A6 B9 P7 ; RE-Map A and B
G91 ; set to use relative coordinates
;G1 A-380 F4800 S1 ; course home X
;G1 A10 F600 ; move back a few mm slowly
;G1 A-380 F360 S1 ; fine home A
G1 B-380 F4800 S1; course home B
G1 B10 F600 ; move back a few mm
G1 B-380 F360 S1 ; fine home B
This has helped in as much as at the end of homing, all axes now move in both the X and Y directions. However, homing A and B does not work and I've figured out the reason why. Basically I get diagonal movement when asking for pure X or pure Y moves. This was masked in my earlier attempts at homing A and B because I started with a diagonal move in any case. I've now taken that out.
So it seems that when I create A and B in config.g, they are created as Cartesian axes and only move one motor, rather than CoreXY which requires both motors to be moved. Also, A (X) still seems to be looking at B(Y) end stop - actually I think (but can't be sure) that both axes look at the same end stop - I'll check that.
Late thought. I've just noticed that I create U and V before A and B so that might be the end stop issue. I'll swap and report back.....
-
Latest update. Creating axis in the correct order seems to have fixed the end stop recognition issue. So this in config.g works
M584 X0:3 Y1:4 Z2 U10 V11 A6 B9 E5:7:8 P3;
All I'm left with now is that the A and B axes move diagonally using a single motor, rather than in X and Y using both motors. i.e Cartesian rather than CoreXY kinematics. So close....
-
@deckingman What happens if you swap
M584 X0:3 Y1:4 Z2 U10 V11 A6 B9 E5:7:8 P3
by
M584 X0:3 Y1:4 Z2 A6 B9 U10 V11 E5:7:8 P3
(
A
andB
defined beforeU
andV
)? Will this make the extruder gantry act as Cartesian and have the counter-weight gantry move correctly? -
@wilriker That's what had at first - see post one before my last timed at 10:41. I still had the Cartesian axis movement (for A and B) but also, the endstop switches weren't being acted on correctly.
Edit. The extruder gantry (U and V) still acted correctly as CoreXY.
2nd Edit It's kind of coming back to this thread https://forum.duet3d.com/topic/6677/corexyuvwa
Do you think making the axes W and A rather than A and B would help? It used to be necessary to create them in that order but I believe that later firmware doesn't care. Just wondering if there is something in the firmware left over from how it used to be that shouldn't be there.....
-
@deckingman Honestly, I checked the source code again and I have no clue how an endstop is assigned to an axis at all. I found the code where the endstop is setup per axis but I have yet to find the place where it looks for a specific endstop for a given axis.
Anyway, while I am hunting this part down (and I have an idea where to look for) I have another question: I have something in the back of my mind, but not sure anymore. Do you switch at any point (after homing) to CoreXY mode? Also once you assigned all three steppers to X/Y do they move correctly i.e. A/B also act like CoreXY kinematics?
-
@wilriker An endstop code is in Movement\Kinematics\CoreBaseKinematics.cpp
If the drive is shared, in CoreXYKinematics.cpp the method DriveIsShared returns true, which is evaluated in the CoreBase file.
The OnHomingSwitchTriggered method is called from Movement\DDA.cpp line 1595 in the v2-dev branch. It is called when an endstop is hit.
-
@wilriker said in Could do with some help with sensorless homing on a CoreXY:
@deckingman Honestly, I checked the source code again and I have no clue how an endstop is assigned to an axis at all. I found the code where the endstop is setup per axis but I have yet to find the place where it looks for a specific endstop for a given axis.
Anyway, while I am hunting this part down (and I have an idea where to look for) I have another question: I have something in the back of my mind, but not sure anymore. Do you switch at any point (after homing) to CoreXY mode? Also once you assigned all three steppers to X/Y do they move correctly i.e. A/B also act like CoreXY kinematics?
Thanks for taking the time Manuel.
I use M669 K8 near the very start of config.g, before anything related to drives or axes. This sets CoreXYUV mode. I don't use any other commands related to kinematics anywhere else.
Yes, when motors 0, 3 and 6 are assigned to X and motors 1, 4 and 9 are assigned to Y, all three gantries move correctly as a single CoreXY. This works both before and after homing.
(Actually the upper gantry moves in the opposite direction because the motor directions are reversed for 6 and 9 compared to the rest).
I think end stops are working properly now. It's just the motion for AB when it operates as a single gantry.
-
@joergs5 said in Could do with some help with sensorless homing on a CoreXY:
@wilriker An endstop code is in Movement\Kinematics\CoreBaseKinematics.cpp
That's what I meant when I said I have an idea where to look for.
@deckingman Thanks for clarifying your kinematics used. As far as I can see on an earlier post you tried mapping the steppers for the load gantry already to drives X and Y temporarily. But you only tried this with the unsuccessful stallDetection as endstop. Could you try again with end stops but please map them to U/V axis instead of X/Y. If this works I have an idea of what the issue might be.
EDIT: And just for my curiosity: can you please tell me which motor is connected to which port and which endstop to which port? I cannot let this endstop-mapping issue go (even if it now works for you this totally confuses me how this is working at all and I miss the actual wiring info to make sense of it ).
-
@wilriker said in Could do with some help with sensorless homing on a CoreXY:
@joergs5 said in Could do with some help with sensorless homing on a CoreXY:
@wilriker An endstop code is in Movement\Kinematics\CoreBaseKinematics.cpp
That's what I meant when I said I have an idea where to look for.
@deckingman Thanks for clarifying your kinematics used. As far as I can see on an earlier post you tried mapping the steppers for the load gantry already to drives X and Y temporarily. But you only tried this with the unsuccessful stallDetection as endstop. Could you try again with end stops but please map them to U/V axis instead of X/Y. If this works I have an idea of what the issue might be.
EDIT: And just for my curiosity: can you please tell me which motor is connected to which port and which endstop to which port? I cannot let this endstop-mapping issue go (even if it now works for you this totally confuses me how this is working at all and I miss the actual wiring info to make sense of it ).
Well mapping drive 6 (A) to U and drive 9 (B) to V at the start of the homing file kind of works in that the kinematics are correct - I do get pure X and pure Y moves. BUT, it ignores the end steps on the upper (AB) gantry. It uses the end stops on the UV gantry so never triggers (unless I manually trigger the UV end stop switches.
Drives are as follows:
These are on the Duet main board
Drive 0 is X
Drive 1 is Y
Drive 2 is Z
Drive 3 is U (usually mapped to X)
Drive 4 is V (usually mapped to Y)
These are on the Duex5
Drive 5 is the first extruder (E5)
Drive 6 is A (usually mapped to X)
Drive 7 is the second extruder (E7)
Drive 8 is the third extruder (E8)
Drive 9 is B (usually mapped to Y).End stops are normally closed switches connected as follows:
On the Duet main board
X is X,
Y is Y,
Z isn't used
U is E0
V is E1On the Duex5
A is E2
B is E3E4 and E5 are connected to additional switches which are used in conjunction with M584 to trigger emergency stops.
It'd be really handy if we could map end stops to axes but I seem to remember from the time when we were trying to get CoreXYUV homing that this wasn't possible. If I could do that, I wouldn't need to create additional axes. Just map drives and end stops to existing axes.
-
@deckingman said in Could do with some help with sensorless homing on a CoreXY:
Well mapping drive 6 (A) to U and drive 9 (B) to V at the start of the homing file kind of works in that the kinematics are correct - I do get pure X and pure Y moves. BUT, it ignores the end steps on the upper (AB) gantry. It uses the end stops on the UV gantry so never triggers (unless I manually trigger the UV end stop switches.
Finally, this starts to form a picture. To get this working natively you would probably need CoreXYUVAB (or whatever it will be named) BUT...
It'd be really handy if we could map end stops to axes but I seem to remember from the time when we were trying to get CoreXYUV homing that this wasn't possible. If I could do that, I wouldn't need to create additional axes. Just map drives and end stops to existing axes.
...there is a workaround to effectively get what you need.
Some background. Skip below the next paragraph for the solution:
I was confused how it is even possible that your drive mappings inM584
can correspond to the way you have wired your machine. I actually had to note down a small table on my notebook with pencil to figure it out. Usually I would have expected to wire the drives and endstops correspondingly, so that e.g. for drive 9 beingB
also has its endstop on the corresponding endstop port. But that would not work nicely with the interleaving extruders. So a small recommendation: if possible swap axis A to drive 5 (where its endstop sits) and axis B to drive 6 (again where its endstop is plugged in). This is not necessary to work but it will untangle some confusion.Workaround
So, the order in which the you define the axes in
M584
defines which endstop is mapped to an axis. But you have to be complete here everytime for this workaround to work.
UsingM584 A0 B1 Z3 U4 V5 X6 Y9 E5:7:8 P3
will let you home the load gantry as
X|Y
! It will treat the two steppers (actually used forA|B
) as CoreXY kinematics plus it will use end stops 5 and 6 (E2
,E3
). Of course you have to map these back and forth for all the homing steps but it should work.Basically, you could adapt this scheme to also home
U|V
and don't use CoreXYUV kinematics at all. -
@wilriker Thanks for trying. There is a slight flaw in your plan though.
To recap. XY carries the hot end and UV which sits above, carries the extruders. XY and UV are coupled by the Bowden tubes. Which means that only small independent moves of XY or UV are allowable. So if you take a look at my homing file for XYUV, you'll see that all 4 axis move together until any one of the 4 end stops triggers. Only after that event do individual axes move. There is only enough flex in the Bowden tubes to allow about 20 to 30 mm of movement of the UV axes in relation to the XY axes. So XY and UV cannot be homed completely independently. Hence the reason (I think) that David created CoreXYUV kinematics.
There is no physical connection between XYUV and the upper gantry so that one can be homed independently. But I don't really want to mess with the XYUV homing because it took a lot of time and effort to get that working right. Equally, I don't really want to mess with the CoreXYUV mapping in config.g for the same reasons. I don't mind temporarily changing it in homeall.g but I'd rather the initial configuration (of XYUV) stays as is (unless there really is no other alternative).
It used to be that end stops were assigned to axes in the order XYZUVWABC etc. But David changed it in the firmware so that (I think) end stops are mapped to axes in the order that axes are created (alphabetically?).
I think it would all work if AB were created as CoreXY rather than Cartesian. Or better still, if there was a way to (temporarily) map end stops to axes. Then I wouldn't need to create additional axes at all.