Are acceleration and jerk applied to homing moves?
-
Is there any reason for this? I assume in case someone has the acceleration set so low as to cause the axis to over-extend the switch. IMO, that's the case which should configure their setup differently.
I would think that when we set acceleration and jerk, they are always respected. If the firmware is purposely commanding immediate stops, there is a potential for hardware damage. Whereas, if the risk is merely for users whose axis would over-extend the switch, the same care of lowering the speed is the answer.
By applying jerk and accel to home moves, it seems we optimize the behaviour for the most common scenarios, no?
-
@bot Apart from what David has said, if you think about it, when homing the firmware doesn't know when the end of the move will be because it doesn't know where the start point is and so it doesn't know how long the move will be (hence the need to establish a datum by homing). So acceleration (or more precisely deceleration) cannot be applied to the end of a homing move because until the printer has been homed, there is no way that the firmware can anticipate when the switch will be triggered. Once the switch triggers, the motion immediately stops by necessity, so jerk is irrelevant and the end of such a move.
-
@deckingman In my mind, the end of the move is triggered by the end stop, and deceleration begins until the jerk speed.
In most cases, this will be around 0.2 mm. Only edge cases will need to make sure they aren't over-extending their endstops.
Another edge case I can imagine is a probe which has an instant response and no allowable travel distance at all, like some kind of electrical continuity contact probe.
I would much prefer to at least have the option to home z to max at a reasonable speed, a speed which doesn't over-extend the switch if accel/jerk are applied, than to home the entire axis at a ludicrously slow speed to accommodate a rare(?) edge case where it would cause problems if we don't command the axis to an abrupt halt.
-
@bot The thought of doing a homing move until a switch triggers and then continuing beyond that point in order to allow a deceleration phase simply fills me with horror.
It is ludicrously easy to do a course home at reasonable speed, followed by backing off a few mm then doing a fine home at a lower speed as David pointed out. What is your objection to doing this?. -
I'm surprised that purposely commanding an axis to a dead stop from an unknown speed doesn't fill you with horror.
Endstops are NOT used in these cases to prevent axes from travelling too far in case of emergency... the end stops are simply used to set a known position. Almost all endstops on printers have enough travel to allow the safe deceleration of an axis...
-
@bot But we aren't stopping from an unknown speed. It's a controlled speed. It's the speed that we define.
And we'll just have to disagree on the matter of allowing movement past an endstop purely for the purpose of allowing a deceleration phase. It would certainly cause complete havoc on my printer with the potential damage or destruction of various components, including my expensive Metrol precision positions switched. -
It's the same argument both ways. You say it will cause destruction to decelerate -- but that means you haven't set your homing speeds and deceleration properly to stop before destruction.
You're saying I shouldn't home without adjusting my homing speeds to avoid destruction from the instant halt of an axis. Since there is no way to prevent this instant halt, we must home at the jerk rate of the axis, even for the slow time, if we want to avoid commanding a halt above the jerk rate.
Why not force users to perform homing at the jerk rate? This is what the current scenario effectively does. Whereas, if we at least had the option to decelerate properly, we could home faster than the jerk rate and also avoid commanding instant halts above the set jerk rate.
Why force all users to do it one way, when with a simple modification all users could have it their way?
Also, calculate the deceleration time and distance for your homing speeds. I'd bet your axes would stop before bottoming out your fancy switches. If not, then maybe your acceleration settings are not aggressive enough, or it's YOU who is homing "too fast."
*not actually a robot
-
Hi,
Just for fun I have been experimenting with dual Z endstop sensors, a "normal" one and a "early warning" one.
My current two printers have moving beds on the Z axis and the beds have quite a bit of mass. To avoid possibly slamming into the endstop switch (or end of travel) and possibly causing damage I have tended, in the past, to home at a "safe" speed.
But when I noticed that in firmware 203 that you can specify which physical endstop input to use it occurred to me that it might be possible to change the active endstop input while homing. Short answer - it is.
So I installed two endstop sensors about 30mm apart. Just to be safe, for this test, I used IR sensors which involved no physical contact. I fit a "beam break blade" to the bed that spanned the 30mm so both sensors, when homed, would be activated.
Homing consists of selecting the lower of the IR sensors and moving at a higher than "safe" rate until that sensor is activated. The bed does indeed come to an abrupt and somewhat startling halt.
Now the upper IR sensor is selected and the "normal" home operation is performed at a nice safe rate and the actual home operation is completed.
Now starting homing when the sensors are already activated is a bit different. The lower sensor is selected AND inverted so it is possible for a "pre homing" command to move DOWN, away from home, until the lower sensor is no longer activated. Then the two "normal" homing commands are issued.
When the lower sensor is already cleared the "pre homing" command doesn't have any effect so there is no downward movement at all.
The same could be done with micro-switches with a somewhat different physical arrangement.
So for the effort of adding an extra endstop sensor and setting them up so they function as described I get high speed Z homing with no wasted motion.
Now I need to see what the long term reliability of this approach is.
Frederick
-
Those are some good ideas, and I'm glad you've got them working. I for a brief moment considered thinking about some arrangement like that too, but for now I will just live with a slower homing on Z and a light clunk at the point the axis is halted abruptly. I hope this doesn't cause any damage to the balls in the ball nut. I know this can cause pitting and wear on the running surfaces so I wish to minimize it.
Also, I keep bringing up Jerk rate here but it seems it does not ever apply to moves from or to a standstill anyway. It seems like we could use some documentation outlining the intended behaviour of all the motion control system, because for those of us who are not coders, we have no way of knowing except by asking people who can parse the source code.
-
@bot I'm sorry but we'll just have to agree to disagree.
An end stop is by definition an end stop - not some arbitrary position beyond which carriages can move by some further amount. Many people use contact probes such as Piezo sensors. I'm sure they will all be delighted if David changes the firmware so that axis movement carries on beyond the point where the Piezo triggers and wrecks the Piezo and/or damages the print surface when the nozzle crashes into it.
And what will your proposed change achieve? Simply allow you to home at a really fast speed. But if you home before a print and start the homing at a "normal" or even slow speed, then the entire sequence will be completed well within the time it takes to heat the bed and or the hot end. So you still have to wait for some period of time after homing and you will achieve nothing.
I have a very heavy 400mm x 400mm 10 mm thick bed and 750 mm travel in Z. I do a "fast" home at 600mm/min (10mm/sec) so the very worst case is that it takes 75 seconds to travel full distance. Then I back off 5mm and re-home at 180mm/sec. So it all happens well within the time it takes the hot end to reach temperature, let alone the bed.
-
@deckingman the proposed changes would allow people to command their (usually) stepper motor driven axes without abruptly stopping them ON PURPOSE.
I wonder what industrial CNC machines do when homing. I have a strong sense that they do not abruptly stop unless the endstop is being used as an emergency stop.
We shouldn't even really use the term "endstop." It's a homing switch. Unless you specifically set it up as a trigger to perform an emergency stop, it ain't ever gonna stop your stuff from crashing.
We use stepper motors. They are torque limiting devices, but abruptly stopping them with all their force can damage ball screws. Having an OPTION, like a flag on the homing move command to allow deceleration is all that I'm asking for.
Your view is, IMO, opposite of what should be best practices. Best practices should be to ALWAYS respect the limits set in the config.g. IMO, the jerk rate is a limit. MAXIMUM INSTANTANEOUS SPEED CHANGE. That is a lie if we allow homing above the set "jerk" rate.
*not actually a robot
-
@bot said in Are acceleration and jerk applied to homing moves?:
Why not force users to perform homing at the jerk rate? This is what the current scenario effectively does.
The difference is that when printing, the jerk rate must be low enough to avoid the risk of the motors skipping steps. Whereas during course homing, skipped steps don't matter.
If you are worried about damage, you can use the M913 command to reduce motor currents while homing, which will allow the motors to skip steps with less force.
I think you will find that all open source softwares for 3D printing and CNC control stop homing moves abruptly. Let me know if you find one that doesn't.
-
@bot There is no need to start shouting which is what your use of capitals indicates. We can have this discussion in a dignified and civilised manner.
But taking the points you raise above. Firstly, if you take a look at the Duet board and all the documentation, you'll see that everything refers to "end stops" and not "homing switches". So "end stop" is indeed the correct terminology.
Secondly, I don't think anybody is talking about stopping stepper motors with all their force. I certainly didn't mention it. You do mention best practice and it is best practice to reduce the motor currents during homing.
Thirdly you mention that quote .."Best practices should be to ALWAYS respect the limits set in the config.g.". IMO that includes axis limits, yet what you propose would allow movement beyond the axes minima that are set in config.g.
And to put all this into perspective, taking a speed of say 60 mm/sec that's 216,000 mm/hour which is 216 metres/hour which is 0.216 km/hr. That's about 20 times slower than a brisk walking pace so even if you used full power on the motors, coming to a sudden stop is hardly likely to do any damage.
-
I have a CR-10S with dual Z, setup as independent axis (Z & U), as well as a BL-Touch.
My homing routine for Z runs the bed down (towards home for me) until both Z endstop switches activate, then up a bit and final Z home with BL-Touch. This compensates for a very slight X carriage tilt that occurs when the right Z motor is released, an inherent problem in a lot of CR-10S's, and ensures a level X & bed.
I haven't implemented it yet (always other projects ... LOL) but I intend to setup an "Emergency Stop" if the Z switches ever actuate during BL-Touch homing, in case of sensor failure.
The BL-Touch's plastic probe is always exposed. On a failed print you can get plastic strings that can catch it and bend it (ask me how I know ...), which can cause the nozzle to smash into the glass if homed with a bend pin.
@bot Interesting thought,
and it's always cool to discuss these things, it's how the software advances, but I must disagree.Endstops are ENDstops, and should be respected. Compensating for Accell & Jerk during homing is an entertaining theoretical discussion but never gets off the ground in the real world. As @dc42 points out, every software out there does the same, including multiple million dollar machines.
The amount of force needed to damage the ball screws when stopping would require a very high rate of speed. Running at such speed past the endstops would cause a heck of a lot more damage than simply stopping the motor would create to the ball screw!
If this was a real problem, we would be seeing wear being reported by the hundreds of print farms that run dozens of machines 24/7, demanding a fix. We don't.
Endstop = Edge of World = Beyond here lie Monsters.
Endstop.
{Giggle} Love to know you're thinking about things, keep it up!!
-
Larger CNC machines respect acceleration during homing moves, but homing typically involves moving past the home switch (sometimes by a considerable margin) then backing up to the nearest encoder index.
In larger CNC machines switches can never be crushed by over-travel, they activate and allow the axis to pass. Axis travel is typically limited by rubber bumpers. Here's a small linear stage with a representative arrangement:
As the machine gets heavier you need to think of endstops as more of a notification that something is wrong than an actual travel stop. Any fault should de-energize the axis drives, after which inertia will take over and allow the machine to coast (or smash) to a stop as physics dictates.
Homing is expected to overshoot the homing switch (which is not necessarily the limit switch). There is a very detailed overview of how homing and limit switches can be placed and configured starting page 88 here: https://www.parkermotion.com/manuals/Digiplan/ViX-IH_UG_7-03.pdf
That being said, this kind of setup is far more complicated than you want in a hobby 3d printer and rigid z-probes pretty much necessitate an immediate stop.
-
@puterpro said in Are acceleration and jerk applied to homing moves?:
...
The amount of force needed to damage the ball screws when stopping would require a very high rate of speed. Running at such speed past the endstops would cause a heck of a lot more damage than simply stopping the motor would create to the ball screw!
...
This isn't exactly the case. The problem with ball screws is that there are lots of tiny, precise, hard balls running along precise, hard grooves. When they experience repeated excitation at high energy levels, they can develop pits in the raceways or on the balls themselves. Essentially, any repeated motion in the same part of the screw that is slamming it stopped at full force can cause wear. It's not an individual hit that will damage the screw, it's the constant hitting of the screw in the same way at the same point of travel that will cause damage.
Interesting discussion. It seems I'm not making headway, so I'll just accept the norm we adopted from ancient firmwares.
-
@691175002 - Thanks! I'm CERTAINLY not a CNC expert, that's great info, Thx!
@bot - LOL! Sometime stopping hitting your head on a wall feels SSooooo good. LOL
I see what you're saying, but don't the balls have a tiny bit of movement during operation, or are they totally captive in position? One (well I) would think they'd shift a bit during long moves.
I'm pondering a linear rail setup on my CR-10S (well it started as a 10S ....).
-
There may be some small amount of movement, but this is exactly what causes the problems. The same thing happens with helicopter rotor bearings (or any other extreme application of bearings). The blades slightly change pitch during their motion, and those bearings that allow that slight movement are exposed to lots of vibration and sometimes shock loading. This causes lines to develop on the inner race surface, where the needles of the bearing rested at the common positions of the blade pitch, that need to be taken out by hand when rebuilding the rotor.
Bearings, exposed to vibration = premature bearing wear. If those are shock loads, the risk is even greater.
BTW, my z stepper was not stalling when commanding the abrupt halt -- this is the problem. The stepper is able to slam the axis stopped and hold the position -- causing the most potential damage to the screw.
Yeah, yeah, it's my responsibility to control the speeds.
I thought I did -- it's called "Max instantaneous speed change." 
-
@bot said in Are acceleration and jerk applied to homing moves?:
I thought I did -- it's called "Max instantaneous speed change."
Smartass. LOL
Good info, thx!
