Could do with some help with sensorless homing on a CoreXY
-
@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.
-
I am still surprised that you didn't get stall detection homing to work when the machine was temporarily configured as Cartesian. What motors are you using, and how many teeth on the motor pulley? Have you tried calling the axes A and B in M584, enabling stall detection on them, and homing them together? It should at least stop one of the motors.
-
@dc42 said in Could do with some help with sensorless homing on a CoreXY:
I am still surprised that you didn't get stall detection homing to work when the machine was temporarily configured as Cartesian. What motors are you using, and how many teeth on the motor pulley? Have you tried calling the axes A and B in M584, enabling stall detection on them, and homing them together? It should at least stop one of the motors.
Hi David. Yes I think I tried that but TBH, I've been through so many combinations that I can't be 100% sure. I'll double check that when I get chance but I'm in the middle of an extensive test programme for some other stuff right now.
Motor specs are as per my post 3 Oct 2018 10:25 but I'll copy and paste them here again......
Voltage (VOC) 2.80
Amps/Phase (2.00
Resistance/Phase (Ohms @25degC) 1.4+_ 10%
Inductance/Phase(mH@1KHz) 3.00+_20%
Holding Torque (Nm) 0.59
Step angle 1.8
Rotor Inertia (g-cm) 82.00Pulley teeth are as per my post 2 Oct 2018 19:48 when I said.....
" My steps per mm and pulley are exactly as the example in the wiki which indicates that the speed should be at least 2400mm/min and I'm using 3000. Just tried 4,000 to no avail"
For info, I tried upping the homing motor current from 200mA that I was using to 500mA. Still no stall detected (but that may, or may not, have been using CoreXY kinematics - can't be sure). I don't think I bent the frame doing that but it looked like a close run thing - scary to watch.
-
@deckingman, thanks for that. I'm using a tablet (as I usually am at each end of the day), so scrolling up to look at earlier posts when replying isn't possible.
Your motors have about 50% more torque than the ones in my delta and a little less inductance. I am able to use stall endstops on my delta.
I suspect the key is being able to set a current that allows reliable homing but produces low enough torque so that the belt can't jump off the pulley when the carriage reaches the physical endstop. This may require use of higher belt tension, or perhaps an idler pulley on the back of the belt to hold it against the motor pulley. Or possibly larger pulleys?
-
@dc42 Hi David,
The belts don't jump. I thought they did because that's what it sounded like when I first tried it, but when I looked closely, it's just the motors vibrating harshly. That's what they do. When they stall, should they literally just stop? Because I can't get them to do that - they just vibrate harshly.
Could it be due to the relatively huge mass that I move? I'm thinking along the lines that the difference in current between moving a small mass and hitting a hard stop will be greater and therefore easier to detect than the difference in current between moving a heavy mass and hitting a hard stop.
-
David, don't spend any more time on this. To cuts a long story short, although this gantry does a wonderful job of stabilising the printer, the effects on print quality are minimal. In fact. I'd go as far as saying that even with extreme torture tests to induce high levels of "rocking", I can't see any difference in print quality, with and without the stabiliser.
So, it's been a useful but largely fruitless exercise and I'll likely just take it off.