Could do with some help with sensorless homing on a CoreXY
-
@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.