Could do with some help with sensorless homing on a CoreXY
-
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.
-
@deckingman I never learn it: don't reply to a complex topic when in a hurry.
What I tried to showcase in my workaround was
a way to (temporarily) map end stops to axes.
I am going to explain again, what I meant because I think the brevity in this case was not a sake but a curse. Forget about all the parts where I talked about getting rid of CoreXYUV and homing
U|V
with my workaround.End stops are assigned to the axes in the order they are specified in
M584
but still from first to last end stop. New axes added by additionalM584
commands will get the next end stop that is not yet used. You can exploit this behavior to assign a specific end stop to an axis by adjusting the order of definitions inM584
. This is the first part.Now, part two is that - as you stated already multiple times -
A|B
will be treated as Cartesian rather than CoreXY and therefore move in the wrong way. You also said the gantry behaves correctly if you assign the steppers toU|V
instead. This leads me to the conclusion that any additional axes (additional in the sense of not part of the kinematics type) will be treated as Cartesian. In your case with CoreXYUV kinematics you have two gantries specified as CoreXY kinematics. To get to properly behaveA|B
as CoreXY also it would require a new kinematics type.So much for the background. Now to my workaround/solution/exploit (however you wanna call it):
We established so far that when steppers are assigned toX|Y
orU|V
they behave correctly. And I explained how to assign end stops to certain axes. What you could do now as part of homing is to temporarily assign the steppers of the top most gantry to axesX|Y
. This is internally just a naming convention but this will assure they are treated as CoreXY kinematics. After homing you will reassign the steppers to anotherA|B
again untilX|Y|U|V
are homed (which needs to happen in one operation as you explained above).This would look a little bit like the following
homeall.g
:; Home top most gantry M584 A0 B1 Z2 U3 V4 X6 Y9 E5:7:8 P3 ; temporarily assign axes names(!) X and Y to steppers of top most gantry to have them act like CoreXY and also use end stops E2 and E3 ; ; Here do your regular homing steps like reducing currents, speed, accel, movement but use X and Y as axes names for it ; ; Home extruder and hotend gantry M584 X0 Y1 Z2 U3 V4 A6 B9 E5:7:8 P5 ; Return to regular axes mappings ; ; Here do your regular CoreXYUV homing ; M584 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
I hope this is clearer now.
-
@wilriker I think I understand.
I think what you are saying is that endstops are assigned to axes whenever M584 is run, and not just when config.g is run. Also, I think you are saying that endstops are assigned to axes in the order that they are created from left to right in that M584 command. I had always assumed that what David meant by end stops being assigned to axes in the order they are created as being in Alphabetical order.
So, if you are correct, then a "simple" printer would have an M584 line like M584 X0 Y1 Z2 E3.
But if the form M584 Y1 X0 Z2 E3 was used, then the Y axis would use the X endstop and the X axis would use the Y endstop.
Is that correct?
-
@deckingman I checked source code again. This is a really tricky part as it is distributed across the sources and end stop assignment is implicit based on axes order and comments use (at least for me) non-intuitive nomenclature. David will understand this perfectly right, just me, I'm having a hard time to tie all those ends together.
You understood David mostly correct. It is not left-to-right order as I posted above but also it is not alphabetical order but XYZUVWABC (totally independent of the order they were given in
M584
). Multiple things are special about it:- X, Y and Z are hard-coded to the first three end stops
- It will map the remaining end stops in the above order to the axes and letters missing will just be skipped, i.e. if you have an
M584 X0 Y1 Z2 C3 E4
it will assign end stop 3 (E0) to axis C - All uses of
M584
kind of accumulate but still use this order. This means existing axes will keep the end stop they have been assigned to the first time they were defined. So if e.g. inconfig.g
you have the odd commandM584 X0 Y1 Z2 A3 B4 E5
then A will be on E0 end stop and B on E1 end stop. If later there is aM584 U6 V7
they will be assigned end stops E2 and E3 and not be inserted in between Z and A.
In conclusion order still matters but it is the order of
M584
commands that matter. Or better: first time an axis is defined it will be assigned an end stop and it will keep this assignment.EDIT: This sadly means my workaround does not work.
EDIT2: This also means it comes down to CoreXYUVAB.
-
@wilriker Thanks for taking the time Manuel. If someone like you is struggling to work out how this all works, then and guy like me stands no chance.
From what I can understand, the entire assigning of end stop to axes seems a bit complicated and somewhat inflexible. I guess there must be reasons for it. Maybe it's just "evolved" into what we have now from the early days of RepRap firmware.
@dc42 I appreciate that mine is a unique usage case - to the best of my knowledge, nobody has attempted to use 7 axes in conjunction with 5 extruders. So I can understand that you have more important things to do. But in case you get time...
To fix this, the ability to change the assignments of end stops to axes would be the easiest solution from a user point of view. If I could temporarily change the assignment of the X and Y end stops from X and Y to Enn and E nn+1 whilst mapping alternative drives to X and Y, I could home these "AB" axis without any need to create them. Alternatively, if there was some mechanism that allowed additional axes could be created as CoreXY on a CoreXY machine, rather than Cartesian, this would also be a solution (from a user point of view).
-
@deckingman i am sure David will answer soon however i know the ability to assign endstops to various axis in part of the work plan.
-
@t3p3tony said in Could do with some help with sensorless homing on a CoreXY:
@deckingman i am sure David will answer soon however i know the ability to assign endstops to various axis in part of the work plan.
That's good news. Thanks Tony.
For now, I have created a pop up message like so:
M291 P"Now move top gantry slowly to far right" R"manually home upper gantry" S2So I have a homing mechanism of sorts, albeit somewhat manual.