Feature request. Rev limit based on sensors.

[aidandj]

Similar to the CLT rev limit. Would it be possible to implement something that could take oil pressure and say shut off the engine below a certain pressure? Or set a rev limit if oil temp goes too high, or AFRs too lean, or EGT too high?

Looking at Limp mode it seems like it is more for malfunctioning sensors.

[Matt Cramer]

The limp mode can be triggered by sensors malfunctioning OR by the sensor reading exceeding a threshold.

[krisr]

Limp mode for any sensor (including generic inputs) would be sweet.

Example: Oil pressure - well... no explanation needed. Coolant pressure - lifted a head, get off the gas ASAP! I'd pay money for these sorts of safety features to work their way into the code as they could save me many thousands down the track.

[jsmcortina]

There's already oil pressure monitoring.

James

[krisr]

There's already oil pressure monitoring.

Yep, and i've setup a 0-100PSI transducer input and the D15 with a piezzo buzzer inside the case to trigger as the oil pressure warning output as a noise is sometimes easier to pick-up on than a light BUT to compliment a warning, having the ECU react after a detected failure would IMO be a better approach than to rely on the driver. Same for coolant pressure/lifted cylinder head - hence limp or rev limit based on any sensor input would be a feature i'd really love to see. Not having a go, just some feedback of some practical things i've made notes on as i've been capturing some data from extra sensors i'm datalogging now (TH400 trans line pressure, trans temp, oil temps, etc..).

[aidandj]

Exactly. A failsafe system that doesn't rely on the driver. Can limp mode be used for generic sensors?

I dug around the code and think I figured out how to implement it. I'll play with it this winter. Are there any timing constraints on the revlimit section of code. I saw it checks the CLT, but is there a limit on how many parameters it can check?

[Reverant]

+1 for failsafes based on generic sensors (ie oil pressure, oil temp, trans temp, diff temp, coolant pressure, EGTs, etc).

Right now, we have only 1 actual failsafe - the lean AFR limiter.

[dontz125]

The various 'limp' sensors and oil pressure trigger an output pin (if selected). In addition to turning on a lamp, buzzer, air raid siren etc, you could add a transistor to ground out the WBO2 signal, thus tripping the AFR safety system.

[aidandj]

The various 'limp' sensors and oil pressure trigger an output pin (if selected). In addition to turning on a lamp, buzzer, air raid siren etc, you could add a transistor to ground out the WBO2 signal, thus tripping the AFR safety system.

I could rube goldberg it. But I would rather have a proper software solution.

[piledriver]

The various 'limp' sensors and oil pressure trigger an output pin (if selected). In addition to turning on a lamp, buzzer, air raid siren etc, you could add a transistor to ground out the WBO2 signal, thus tripping the AFR safety system.

I could rube goldberg it. But I would rather have a proper software solution.

I like hardware interlock solutions.
Theres nothing quite like building a crowbar circuit using an actual crowbar.
(Think radar power supply shorting bar)

[aidandj]

Its hijacking another system. The infrastructure is there to add more rev limits.

If the devs don't agree then I will find a hardware solution.

[krisr]

Hypothetically, how would you do a hardware solution with the MS3Pro? - If you had told me that I needed to crack open a sealed "pro" series ECU to jump wires around to get a safety feature to work, I'll have a Haltech in the car the very next day.

Hardware solutions IMO are bandaids and not very user friendly. Safety features should be in the software and should be scalable and flexible (think like the general purpose outputs) and I think (again, not having a go at anyone) should be on the very top of any TODO list vs the "cool funky race stuff" which may get used by a handful of people, if that. With the IO of these ECU's now plus if you're running an IOX on the CANBUS with an MS3X, we can get so much value out of datalogging the whole drive train but consider the monetary value if it could actually do something about it and prevent a block/gearbox tear up, hence why I saw the value in running trans line pressure sensors, coolant pressure sensors and this thread popping up now is good timing for me.

[dontz125]

Hypothetically, how would you do a hardware solution with the MS3Pro?

Both the AFR signal and the warning signal are available at the wiring. The entire point of the warning signal is that it leaves the box and travels to the dash; since the vast majority of the MS3-Pro's outputs are ground-switching, a simple Schottky diode from the WBO2 wire to the warning signal wire would do the job nicely. It would also be easy to remove if so desired when / if this function is added to the code.

[piledriver]

Hardware interlocks are what you should (really, MUST) use if actual safety is involved.

Software is great, but sensors can lie and code can have ...unintended features.

Overpressure or overtemp switches that literally are designed to blow the fuse (crowbar) in event of a failure are examples.
You probably don't want that when crossing a busy intersection or merging onto a freeway though.

Software solutions are never considered enough, require extensive proof and redundancy as to actual safety items.

[dontz125]

For a hard engine cut, yes - it's hard to beat hardware. But I thought the topic was to limit operation if something dodgy is detected; how is that done -other- than code? What fuses would be crowbarred by a coolant pressure switch upon detecting (what is probably) a blown head gasket?

(Fuse that releases a solenoid-triggered throttle stop that limits opening, and cuts out the boost solenoid? Another fuse that cuts out half the spark plugs?)

[krisr]

Both the AFR signal and the warning signal are available at the wiring. The entire point of the warning signal is that it leaves the box and travels to the dash; since the vast majority of the MS3-Pro's outputs are ground-switching, a simple Schottky diode from the WBO2 wire to the warning signal wire would do the job nicely. It would also be easy to remove if so desired when / if this function is added to the code.

Ahh yeah that's true. But then you'd need to replicate the warning signal (general purpose output?) per input sensor condition you'd want an action for, which is where it's not user-friendly and is a combination of extra hardware and software plus in some cases you wouldn't need or want to completely cut the engine out especially on a freeway @ 60mph or in front of another vehicle that may cause a side impact. The question of sensor reliability is still called into question (we're talking any sensor, not just one tapped into the oil pressure line) for either hardware or software but the action from software can potentially deliver a more desired outcome if configured that way, i.e. have the ability to have it rev limit the motor in order to nurse the car/bike to the side of the road/breakdown bay.

I just feel (strongly) that this discussion around safety could really help someone or all users. Even though software safety may not be considered as "enough", it's still better than nothing when you're looking outside of AFR. Extending the AFR safety feature to be a more generic safety feature for any input condition coupled with the work already done for CEL flashcodes/warning outputs/etc might be a good platform to consolidate the existing work into 1 theme, i'm just struggling to understand the resistance? Again, not having a go but trying to keep the discussion flowing

[piledriver]

Resistance is probably too strong a word, it's closer to "inertia".
Mostly we are just trying to get you where you want to be, now, with what you have.

My HW interlock rant was more or less in response to

Safety features should be in the software and should be scalable and flexible (think like the general purpose outputs)

No. They. Shouldn't. Not real "safety" features.

Very few folks actually contribute code, so those that do get to choose, and they have plenty of "external input" constantly.

Picking and choosing what they want to tackle next is probably a major drag.

[dontz125]

The problem and differences of opinion I think comes in with varying definitions of "safety". Theoretically, any critical engine malfunction would trip the safety system to hard-cut the engine *NOW*, preventing the con-rods from taking a constitutional around the inside of your engine bay. In the Real World (tm), there are often circumstances where eating a valve is preferable to, say, eating an 18-wheeler. Leaving the engine running, and possibly inflicting $$ in damage to the internals, may as noted in an earlier post be the difference between pulling off to the side of a busy expressway and becoming a chicane in the middle of that highway. I once had the engine in my old POS K-car conk out on the 401 in heavy Toronto traffic; gliding off to the shoulder with increasingly alarming speed differentials was NOT fun ...

[Reverant]

So ejecting a rod, spilling all the oil and coolant on the road is safe, but shutting down the engine is not?

Losing oil pressure or overheating to the point where the pistons seize in the cylinder *with the car in motion* is safe but shutting down the engine before that happens is not?

And of course, these ECUs are never installed on road cars, right? They are only for use on off-road vehicles.

Engine safety is not just for engine safety alone. Shutting down the engine before the damage happens will still allow you to use the brakes and steering, etc.

[piledriver]

So ejecting a rod, spilling all the oil and coolant on the road is safe, but shutting down the engine is not?

Losing oil pressure or overheating to the point where the pistons seize in the cylinder *with the car in motion* is safe but shutting down the engine before that happens is not?

And of course, these ECUs are never installed on road cars, right? They are only for use on off-road vehicles.

Engine safety is not just for engine safety alone. Shutting down the engine before the damage happens will still allow you to use the brakes and steering, etc.

Sometimes it will be.
Sometimes it won't.

You might want to get outta the way of the train or semi first.

Volunteering to write the code for that godlike software decision that determines who is the windscreen or bug, and when, that must work correctly, always?

The existing firmware allows you to make that call already, (in a great many cases, memory has hard limits for adding options) as described.
You can shut things down as hard as you like, via several methods.