Unsolved Mystery. Weird Z0 behavior around build perimeter.

[RegB]

So I finally got my build platform "flat enough" with a max deviation (high-low) of 0.004". I optimized the calibration the best I could and ended up with a range of +0.0015/-0.0025" when the center is at zero. This is opposed to the more natural +0.000"/-0.004" that happens when using the X,Y,Z, center height = 0 calibration only.

It is odd the way I improved it though since I couldn't get any better with software changes or end stop screw settings. I ended up playing with where I put the glass build plate clamps and the size of clamps used. I used two small clamps on either size of the heated bed wiring next to the Z-tower, one large clamp directly inline with both the X and Y towers, and no clamps at all in between towers.

I still don't understand how the height can be correct based on X, Y, and Z-towers, but not based on the same points between the towers with equidistant build plate clamping. On my machine, I was consistently calibrating to zero on the towers and center and it would be 0.003", 0.005", and 0.012" low between all towers (calibrated tower rotations so that no spots were high). For some reason I also couldn't get the spot opposite the Z-tower to not be the lowest point. Just hate having to configure clamps on the bed to get it level rather than being able to get it correct in software.

Oh Ohh...
That sounds familiar.
1) At one point I had TWELVE small binder clips around the plate and things got a bit weird.
Long story short, I misplaced one of the original six and the easy way to buy one was to buy a dozen - it SEEMED like a good idea to use them all in an attempt to clamp that glass down FLAT.
2) The O/P of this thread posted a procedure for leveling and shimming the snowflake BEFORE clamping the glass to it.

Now, I do KNOW (from other "life experience") that glass is "kinda bendy" (a technical term meaning flexible) so I wonder if we are dealing with bed flatness or if we are trying to "follow the bend(s) in the glass".

I am tending toward "shim the snowflake first" - - I am also thinking that measuring for "flatness" with the glass merely ON the snowflake, not clamped, would be worth while.

I have another variable, a thin sheet of aluminum as a heat spreader.
I looks flat, but I suspect that there are stresses in it from having been in a roll when I bought it.

[Jimustanguitar]

On mine, forcing the bed to the tolerance that I wanted with aluminum foil shims did the trick. Whether it flattened the bed or warped it to match the movement of the effector depends on who you ask

I leveled my endstops against the frame itself before installing the snowflake and bed.
Installed snowflake, bed, and BORO glass.
Measured with an indicator and shimmed under the bed (between the snowflake and bed) to tolerance.

I've been using 6 clips (used to only use 3), slid clockwise until the fully inserted clip grazes the side of the snowflake's screw flange in all 6 positions. Since doing this, I've been printing like crazy. Finished a whole spool from start to finish actually, which I hadn't done in the whole year and a half that I've had the machine before.

[626Pilot]

I've been using friction-fit clips to keep my glass in place, but it's an actual 280mm tempered glass disc I had custom cut for about $30, not the ~300mm wide thing SeeMe sells. The clips slide over the edge of the Onyx (friction fit, with a little added stickiness from hairspray) and merely press on the glass from the side, rather than clamping it.

lordblinky, can you explain some of the math you used? I haven't done anything with curve-fitting. Also, have you done anything with adjusting tower angles rather than radii?

[lbarger]

My RoMax V2 also seems incapable of to printing much outside the triangle defined by the towers. I started a thread about the unusual variations in the brim of a part I tried the print here...
http://forum.seemecnc.com/viewtopic.php?f=37&t=6680" onclick="window.open(this.href);return false;

I found part of my issue was my calibration was not as tight I thought. However, upon dialing in the horizontal radius and end stops, my hot end still lifts about .5mm going to the perimeter opposite each tower. It seems fairly consistent in the lift between each tower pair which makes me think it is not an offset tower (unless they are all off equally). Wondering if it is a math issue in the firmware. I've poked around in there a little and saw they do some shortcuts to speed up certain functions. Can someone point me to where X, Y and Z coordinates are translated in to the skate position on the tower? I'm wondering how robust the simplified math is when an arm approaches horizontal.

Earlier in this thread it was suggested to tweak the end stop on the tower opposite where the head lifts off. This seems very counter intuitive. The arm going to that tower nears horizontal. Minor changes in that skate's position would have very little effect on the height of the head as it is moving nearly perpendicular to the arm. My intent is to not dispute the results, just seeking better understanding.

Like others, I do not consider warping the build surface to match the motion of the head is a real solution. I will soon need to print a part that measures roughly 230x110mm (that's a diagonal of 255mm) which this printer *should* be able to handle.

[teoman]

I have partially read this thread (still reading...) so my excuses if this has been asked / answered before.

I losened the towers and i want to adjust the so that they are completely vertical to the build surface which would make them all parallel. Measuring them with a square tool i notice that they are all lean inwards.

Geometrically the only way that is possible is if the top plate (or its holes) are smaller than the bottom plate.

[bot]

The top plates are physically bigger than the bottom plates, for certain, by about a few mm. The perimeter outline of them, that is. The tower channels line up precisely. (on the revision of the laser cut templates circa Sept 25 2014)

There is a noticeable amount of slack in the u-joint positions on the stock setup. I added some 11" cable ties to add tension to all the arms near the u-joints. It has stiffened up the effector tremendously. Where the effector used to slop and jiggle around before, now it is put firmly in place with no slop. The cable ties bind slightly at times, so a more forgiving solution like rubber straps might be better. (not to say that this is the cause of the "bermuda triangle" effect, but thought you might be interested in removing that as a factor)

[teoman]

Do you mean bind the 2 arms together?

[bdjohns1]

The top plates are physically bigger than the bottom plates, for certain, by about a few mm. The perimeter outline of them, that is. The tower channels line up precisely. (on the revision of the laser cut templates circa Sept 25 2014)

There is a noticeable amount of slack in the u-joint positions on the stock setup. I added some 11" cable ties to add tension to all the arms near the u-joints. It has stiffened up the effector tremendously. Where the effector used to slop and jiggle around before, now it is put firmly in place with no slop. The cable ties bind slightly at times, so a more forgiving solution like rubber straps might be better. (not to say that this is the cause of the "bermuda triangle" effect, but thought you might be interested in removing that as a factor)

This is exactly what you get when you buy the tricklaser arms. Rubber tubing bands top and bottom of each arm to take out any play.

[bot]

Yes that's where I got the idea. Should have mentioned that. But it is quite obvious that the arms need help in stayin. Parellel.

[626Pilot]

Earlier in this thread it was suggested to tweak the end stop on the tower opposite where the head lifts off. This seems very counter intuitive. The arm going to that tower nears horizontal. Minor changes in that skate's position would have very little effect on the height of the head as it is moving nearly perpendicular to the arm. My intent is to not dispute the results, just seeking better understanding.

The printer needs to know the center of its own coordinate system, and it has to assume the effector is exactly centered after it homes. All the math - ALL of it - is done relative to where the effector is after homing. To the degree the endstops are off, so is the printer's knowledge of where its center is. Regarding the tower-opposite point, the carriage moves faster the further the effector is away from it in order to compensate for its reduced effect, so it still matters.

Wondering if it is a math issue in the firmware. I've poked around in there a little and saw they do some shortcuts to speed up certain functions. Can someone point me to where X, Y and Z coordinates are translated in to the skate position on the tower?

The inverse kinematics for these machines are very simple, and I don't think machine epsilon is a big factor because plenty of people don't have this problem. This is the version that comes with Smoothie, customized to support individual arm lengths:

Code: Select all

// Inverse kinematics (translates Cartesian XYZ coordinates for the effector, into carriage positions)
void LinearDeltaSolution::cartesian_to_actuator( float cartesian_mm[], float actuator_mm[] ) {

    actuator_mm[ALPHA_STEPPER] = sqrtf(this->arm_length_squared_1
                                       - SQ(delta_tower1_x - cartesian_mm[X_AXIS])
                                       - SQ(delta_tower1_y - cartesian_mm[Y_AXIS])
                                      ) + cartesian_mm[Z_AXIS];
    actuator_mm[BETA_STEPPER ] = sqrtf(this->arm_length_squared_2
                                       - SQ(delta_tower2_x - cartesian_mm[X_AXIS])
                                       - SQ(delta_tower2_y - cartesian_mm[Y_AXIS])
                                      ) + cartesian_mm[Z_AXIS];
    actuator_mm[GAMMA_STEPPER] = sqrtf(this->arm_length_squared_3
                                       - SQ(delta_tower3_x - cartesian_mm[X_AXIS])
                                       - SQ(delta_tower3_y - cartesian_mm[Y_AXIS])
                                      ) + cartesian_mm[Z_AXIS];
}

[626Pilot]

This is exactly what you get when you buy the tricklaser arms. Rubber tubing bands top and bottom of each arm to take out any play.

That's the best way to go. I would not use zip ties. Theoretically the arms should always be exactly parallel and the same distance from one another, and if zip-ties were two-dimensional, it would be fine. But - zip ties have a height. If the arms are perfectly in front of the towers, that height means the zip tie will be fully in contact with both arms. But what happens if you move the effector right or left relative to the tower? Now, the top of the zip tie's "wall" will touch one arm and the bottom of it will touch the other. Move it to the opposite side and the effect is reversed. The zip tie has no give, so it will force the arms to bend inward instead. That will shorten them proportional to how far right or left they are relative to the tower. A rubber band will stretch freely to accommodate this effect.

Trick Laser arms ship with some kind of rubber tubing that's held in place with laser-cut barbs. I lost one of them and just tied a rubber band to itself in its place, being careful to avoid too much tightness. It was tricky, but I've been tying my shoes for a long time so it wasn't THAT difficult. I like the TL solution but really, as long as you have some rubber bands that can be tied up without exerting too much pressure (and you really only need a SMALL amount) you're good to go.

It's important to put whatever solution you use as close to the hinges as physically possible. Rubber bands will give, but they will still try to pull the arms together, and you DON'T want to give them leverage! I make sure to secure mine around the hard plastic of the Traxxas joints rather than the flexible carbon fiber arms. DON'T let your rubber bands exert ANY pressure on the arms if you can avoid it!

[geneb]

It might even be worth it to use a 4" wire tie placed to prevent the TL rubber bands from "walking" up the tube over time. I can take a pic if that makes no sense. (Blue MAX uses the TL arms, but I don't have the bands installed)

g.

[bot]

There is enough "slack" in the cable ties to allow it to "slip" into place. It sounds like the ridges on the edges of the tie bind slightly on the plastic of the arm as it slides, but it seems to consistently move when it needs to. I was worried of the effect you speak of, pilot. The cable ties were simply an experiment. The issue of the binding only comes about during "extreme" moves, ie, not near the center of the build plate. I haven't yet tested the extremities of the build plate, but for prints remaining in the center the cable ties improved print quality noticeably.

On larger prints, if I notice the binding causing artifacts, I'll look into another solution. For the time being they seem to work great. Like I said, it tightened up the movement of the hot end effector considerably. There is no slop in its placement. It also raised the effector slightly, requiring me to increase the z height. This seems to indicate that the radius HAS been affected, as well (I had to tweak that, too) The cable ties are surprisingly consistent in where they sit. The curve of the arms, combined with the shape of the ends, with one arm's curve protruding from the surface of the length near the end, gives the cable tie a place to sit firmly when in the "centered" position (the position it was in when I installed and tensioned the ties). When it "walks" up and down the arm, it always finds itself in the same place at the end, not riding up the arm like I feared.

Further testing is required, but it seems to be adequate for now to remove the slack. Also, I have nothing to link this to the problem described in this thread, but it seemed relevant.

[lbarger]

Getting a little closer...

I found a screw on my z skate that I failed to tighten during the build. It was on the Y tower side of the Z tower and at the top of the skate near the arm's u-joint. Getting the hidden screw tight was the start of getting consistent (but not yet perfect) results. Before the head would be low at the Y tower if approached from the X tower, but high at the Y tower if approached from the Z tower. Makes it impossible to set the end stop.

I currently have the four main calibration points (each tower and center) within 0.05mm. However, within the triangle defined by the towers I still have an overall variation of 0.1mm between the lowest point on my test print and the highest. My test print is a six pointed star with 18 post at 1.95mm height, 15 are within the triangle and three are opposite the towers. (see attached) Going outside the triangle still causes the end effector to rise. It was raising by as much as 0.4mm and its now down to 0.25mm. In case you can't read it, the outer circle radius is 129mm.

If anyone would like to take a look at the attached image I would appreciate any feedback one what I might change. I will try a slight decrease in the horizontal radius to raise the end effector at the center and I might bump the z end stop just a touch. After that, I'm wondering if I need to check out tower rotation and if so, how to best do that.

[626Pilot]

I'm still working on heuristic calibration stuff for Smoothie. Latest rev is here: https://github.com/626Pilot/Smoothieware" onclick="window.open(this.href);return false;

That code is, of course, highly experimental and useless unless 1) you have a Smoothieboard or Azteeg X5 and 2) you're a coder or at least know enough to download a repository, build and upload it to your card.

What I have so far works great with my Z-probe. Config is in ConfigSamples/AzteegX5mini.delta/config - you want to port lines 31-52. They have new variables that cover a lot of stuff I've added.

The Z-probe architecture itself has been upgraded in several places. It now PROPERLY decelerates the probe on trigger AND has runout prevention, so that if your speed/accel combo would cause your probe to run out of "throw," it will immediately abort. If you want to improve repeatability, you can use probe priming (run the probe several times before recording a sample) and/or smoothing (take several samples and return the average).

As for calibration, G29 runs a pretty good probe calibration routine that you can use to dial in your probe settings. With probe deceleration and probe priming, I have managed to achieve a repeatability that's within one step for my Z-probe - and sometimes zero. Standard deviation is usually 0.5 steps or less. (Before smooth deceleration and priming, it was more like 1.5 to 3, and rarely less than 1.0.) It will tell you the standard deviation and keep track of the winning setting, which it announces after every test, so you can try different stuff for half an hour and always see the best one immediately.

After your probe settings are dialed in, you can run G31. Right now it doesn't do anything but level the endstops and calibrate delta radius. Three interesting things, though:

• It converges the endstops and delta radius at the same time.
• It runs A LOT quicker than leveling the endstops and calibrating delta radius as separate steps, and produces a better result, because - dig this - as soon as you mess with delta radius, your endstops become less leveled.
• Four iterations (which totaled about three minutes altogether) were enough to get BOTH the endstops and delta radius calibrated to LESS THAN TEN MICRONS, or ~0.4 thou, on my Z-probe, which is slightly loose!

I have also been studying Rich Cattell's delta calibration code from Marlin to figure out (his idea of) what miscalibrations cause what effects:

• Delta radius: Tower heights vs. center height
• Arm length: Tower heights vs. opposite heights
• Tower radii: For each tower, subtract tower height from opposite height. This is the "diagonal". If a tower's neighbors have very close diagonals, but that tower's diagonal is unacceptably different from both of its neighbors', it needs adjustment.
• Tower angles: Calculate difference between neighboring towers' opposites, e.g.: X = oppY - oppZ; Y = oppZ - oppX; Z = oppX - oppY. (Order is important - sign determines direction of correction.) That difference tells you how much to rotate the towers.

He has no code for adjusting individual arm length, but that's alright. Arm length changes cause only tiny changes so I would try to mess with that last, after everything else runs.

If you want to try letting the code calibrate endstops/delta radius, you can play with the tower radii, angles, and arm lengths using M665 and letter codes that are printed right at the start of running G32. I will be writing some calibration heuristics that will try to do that for you in the coming week, but I don't know if I'll run into something that makes it take longer. If Rich C's methods are not good enough, I'll have to write a delta simulator for one of the open source Mathematica-alikes and figure out what's really going on.

Oh yeah - I'm abandoning the curve fitting thing. I don't understand the math well enough to turn it into something that can run by itself and not require humans to think about weird nonlinear delta behavior. (If I did, I'd love to use it.) I think these heuristics will lead to the same result.

[bdjohns1]

I'm still working on heuristic calibration stuff for Smoothie. Latest rev is here: https://github.com/626Pilot/Smoothieware" onclick="window.open(this.href);return false;

That code is, of course, highly experimental and useless unless 1) you have a Smoothieboard or Azteeg X5 and 2) you're a coder or at least know enough to download a repository, build and upload it to your card.

What I have so far works great with my Z-probe. Config is in ConfigSamples/AzteegX5mini.delta/config - you want to port lines 31-52. They have new variables that cover a lot of stuff I've added.

The Z-probe architecture itself has been upgraded in several places. It now PROPERLY decelerates the probe on trigger AND has runout prevention, so that if your speed/accel combo would cause your probe to run out of "throw," it will immediately abort. If you want to improve repeatability, you can use probe priming (run the probe several times before recording a sample) and/or smoothing (take several samples and return the average).

This sounds awesome. Once I get a probe built, I'll give it a try.

[626Pilot]

I had a flash of insight yesterday that has lead me to try out a whole new calibration method, and I've spent the day writing some test code.

The normal way to do a heuristic delta calibration is to have the printer slowly wander from a bad calibration to a good one. Dozens to hundreds of tests are run, with Z-probing going on in between, and the code relies on the programmer's understanding of how numerous variables that are all deeply interconnected behave, including n-th order effects, when the calibration is off.

Well, here's a crazy idea: Let's just probe the bed ONCE, and then use brute-force computation to simulate EVERY possible miscalibration within some reasonable range.

For each possible combination of endstop offsets, delta radius, tower angles, tower radii, and arm lengths in a given range - and there can be thousands, hundreds of thousands, even MILLIONS depending on how fine-grained we want to get - we do the following:

• Set printer to existing settings (before the test was started)
• Run each test point's coordinates (x/y/depth) through INVERSE kinematics to get the axis (carriage) positions. This tells us where they should be on a printer that PERFECTLY matches the existing settings.
• Set printer to current iteration's settings, which are offset from the existing settings by some amount.
• Run the axis positions through FORWARD kinematics to get the effector's coordinates for the current test case. This tells us where the effector would be on a printer with a physical setup identical to the test case.
• Calculate difference between what we fed into the inverse kinematics (perfect setup), and what we get out of the forward kinematics (test setup).
• Is this difference lower than any previously calculated difference? If so, mark these settings as best-so-far.

After we go through all the iterations, the best-so-far iteration - that which most closely fits the MEASURED depths out of all of them - wins. This should correct for not only errors in Z, but in X and Y as well!

The old "try and probe" way can take over an hour to run a few dozen tests. This method can run millions of tests IN SECONDS. Moreover, it's not prone to errors introduced by how well I do or don't understand the effects of various miscalibrations on the measured depths because it tests every possible combination.

What I've discovered so far is that Smoothie's linear delta forward kinematics, which are not actually used by anything else, don't work. Whatever coordinates you feed into it, the output coordinates are all NaN ("not a number"). If I can get that fixed, the rest should be "easy."

[teoman]

Well.

If you want to do offline calibration. I would recommend printing a calibration grid and manually bring the hotend to the coordinates and record.


Stack a couple of glass plates on and repeat.

[bdjohns1]

Well, here's a crazy idea: Let's just probe the bed ONCE, and then use brute-force computation to simulate EVERY possible miscalibration within some reasonable range.

For each possible combination of endstop offsets, delta radius, tower angles, tower radii, and arm lengths in a given range - and there can be thousands, hundreds of thousands, even MILLIONS depending on how fine-grained we want to get - we do the following:

What I've discovered so far is that Smoothie's linear delta forward kinematics, which are not actually used by anything else, don't work. Whatever coordinates you feed into it, the output coordinates are all NaN ("not a number"). If I can get that fixed, the rest should be "easy."

Sometimes the sledgehammer approach to computation is the way to go.

Here's a wild-ass thought - would doing something like that be easier if you actually had real position feedback from above the bed?

Say, a cheap Harbor Freight dial indicator that was hacked to give you actual position versus expected position?

http://hackaday.io/project/511-digital- ... face-probe" onclick="window.open(this.href);return false;

Or, even better since we all have spare Arduinos laying around, it seems like: http://forum.arduino.cc/index.php/topic,8472.0.html" onclick="window.open(this.href);return false; - just take one of those guys and interface it with the Smoothie?

[Jimustanguitar]

You're hitting on something that I think is the next big thing in home CNC... Closed loop positioning. It's starting with ZProbes, but eventually I think we'll have it on all movement. Could switch to servo motors instead of steppers.

[Hinkenstein]

Hey I know I'm still new to the forum, but I've been wrestling with this issue myself, and I'm scratching my head at this point. I've squared my towers as best as I can considering the frame design provides no way to adjust or fine tune the tower alignment, and all towers are square within .2 degrees. I've used a dial indicator to perform the bed calibration as described in the manual, though I've changed the points from 90mm from bed center to 120mm, in order to adjust the tower with it's arms as vertical as possible. Next I checked 3 points 120mm from bed center angled between each tower, and 60mm from bed center along the same lines. The towers and bed center are perfect (+- .5 mil), but the other points vary wildly. I know this thread is concerned zeroing close to the build perimeter, but do my measurements appear to be the same issue or a separate one? Measurements are relative to the center of the bed.

The sector between angle Z-C-Y seems to be fairly close and even to the center, but everything else seems to be off significantly. This leads me to believe that most of my error is coming from the X tower, either from the tower's alignment, or the carriage's interface with the tower, or the mounting point of the shaft the arms are attached to. Like I said before though, as best as I can tell, each tower isn't more than .2 or .3 degrees off measured towards the center of the bed, or tangent to the bed.

Any thoughts would be appreciated!

EDIT: In case it helps, I've also gone through a lengthy session of playing with the tower rotation values with no luck, And I have a spreadsheet with those values as well if anyone thinks that data could be useful. Also, what should I be targeting for "Good enough?" Does anyone know how tight of a tolerance all points should be to be considered "level"? I would think 25 microns would be pretty good, but I'm a relative newcomer to this sport.

[Flateric]

You're hitting on something that I think is the next big thing in home CNC... Closed loop positioning. It's starting with ZProbes, but eventually I think we'll have it on all movement. Could switch to servo motors instead of steppers.

I've been pushing this idea for some time now. There seems to be alot of resistance to the idea.

[bdjohns1]

You're hitting on something that I think is the next big thing in home CNC... Closed loop positioning. It's starting with ZProbes, but eventually I think we'll have it on all movement. Could switch to servo motors instead of steppers.

I've been pushing this idea for some time now. There seems to be alot of resistance to the idea.

I think to some extent it's cost driven. By the time you put together a DC motor with decent holding power, a high resolution encoder, and a motor controller, you're looking at something a bit more expensive than a <$20 stepper. This guy did it for a CNC machine (although he's actually still using steppers, just driving them more like a servo) - http://jrkerr.com/lobocnc/index.html" onclick="window.open(this.href);return false; - but that's $450 for 3 axes.

I'm sure one of the "steppers 4 lyfe" crowd would argue that you should just address whatever's causing you to lose steps in most cases, but in the case of bed mapping, some kind of position feedback more detailed than a hall effect switch would be good.

I like the idea of having position feedback overall. I'm not enough of an EE guy to delve too far into it, unfortunately.

[Flateric]

For certain it is a cost driven issue, for exactly the reasons you list plus the fact that there is zero hardware and firmware made for this market as of yet. But for those whom cost is not the only high priority but perhaps on par with there quality priorities it may be worth it. Servo's also offer alot of other pro's as well over stepper based designs.

[626Pilot]

Sometimes the sledgehammer approach to computation is the way to go.

Here's a wild-ass thought - would doing something like that be easier if you actually had real position feedback from above the bed?

Say, a cheap Harbor Freight dial indicator that was hacked to give you actual position versus expected position?

A Z-probe is how I get the depths in the first place, but you've given me a good idea. A person with a dial gauge, but no Z-probe, could simply test all the points by hand and feed the depths into the software via G-code.

As it turns out, there are potentially billions of combinations to test and the loop runs pretty slow. I need to optimize it to see if I can get it to run quicker. I don't think this processor has an FPU, so I may have to use fixed-point math like they did on PCs before everyone had a math coprocessor. (There are tons of squares/square roots in the calculations.)

This problem has things in common with protein folding simulations. (Imagine that you have a spring that's bent in a few places. You add energy to the spring by stretching it. The simulation has to find out the lowest-energy configuration it can assume after you've let it go.) In the case of my simulation, the lowest-energy state is the one where the simulated points are the closest to the measured points. I think simulated annealing may be the right algorithm. The pseudocode for that algorithm makes sense to me, and the randomness of the search (constrained by an ever-decreasing "temperature") seems likely to find an optimal answer more quickly than a brute-force search. I don't have to find *the* global optimum, just whatever falls within a given target. 30 microns should be fine for 0.1mm layer heights.

If the annealing isn't good enough, a depth map should be enough to provide Z correction. Unfortunately it won't correct X or Y, but we should get as close as possible on those from annealing.

Re: servos, I would just put encoders on the steppers to catch if they miss a step. Steppers are already good enough to run for 30+ hours without a printed piece turning into spaghetti. The encoders would help a little with this, but I would use them mostly to shut down should the effector crash into something.