I don't know if you're trolling or if there's a genuine misunderstanding.
All recent (as in 1-2 decades old) cars on the market have rev limiters. Thus you won't destroy them by over-revving them by applying accelerator alone.
When you shift into neutral, and the revs go to wherever the limiter keeps them at, there's no more engine torque applied to the wheels -- you should be able to apply the brakes and stop within a couple of seconds (assuming it's safe to stop).
You then turn of the screaming engine and no damage has been done. If you care about heat soak, you can then try and restart the engine to keep the water pump running for a bit -- perhaps it won't be stuck at WOT anymore.
I can test it that way today, no biggie, and even though Feynman would probably look funny at me for having entrenched expectations, I fully expect that nothing bad will happen solely due to this experiment. If something bad did in fact happen -- well, I guess the baby room remodel can wait then./me ducks and runs
I wish I had money to buy some of their stock on the recent 247 dip. Would have got a nice 3% reward today. Methinks you got it backwards: those who bought the stock in the last 3 days probably are all in the green now.
Anecdotal evidence: I have used RedHat/Fedora on the home and work desktop since RH 4, until KDE 4 came out on Fedora Core. This was such a step back, that I simply went to the store, bought a long-needed replacement for the home PC and it was an iMac. Half a year later my Compaq laptop with Fedora and XP-in-a-VM on it got replaced by a MBP. I have no big complaints so far -- not anything out of the ordinary. Stuff gets design mistakes all the time, Apple aren't the only ones to mess up.
1. It "simply works" implying "... when the hardware works" -- I think this is what people mean. I find this to be quite true about Apple products I'm using (an iMac and Macbook Pro, both with Core 2 Duo CPUs with DDR2 RAM, with Snow Leopard).
2. It "simply works" implying "... all the time no matter what" -- I can't really speak to that. My own anecdotal evidence is inconclusive. In the last 3 years I've had the motherboard replaced on the iMac since the 2nd RAM slot would not work; the iMac also had the superdrive replaced; the MBP is due for a magsafe replacement (failing plug). But then I have a bunch of dead PC hardware at work, too, including a flaky Dell motherboard, a bunch of dead optical drives, a smoked power supply or two...
ABS is designed specifically to fail safe in presence of single and double faults. It'd be quite a coincidence for the ABS to fail such that the hydraulic circuits are isolated, and the throttle to WOT at the same time.
Probably I was wrong in my assumption that the ABS box on Toyota hybrids works the same as a regular ABS box. What I now think is that they changed it in '04 Prius.
The ultimate test would be to cut the power to the all the ECUs while the car is slowly moving -- perhaps in a big parking lot at night somewhere? I presume there's a fuse that would kill the ECUs, maybe it can be pulled from inside. A static test would also work: park on an incline, apply brakes, have someone pull the ECU fuse(s), see what happens. Do it safely (DUH).
I would really like to see some first-hand evidence, so if you spend time to do the actual tests I'd love to hear the results. One learns something every day. I guess I was too fast with condemning your opinion;)
I'd say that you're overestimating how good the spouted "facts" are. My expectation is that the "facts" will be 100% crap, not 90% crap, and when talking to certain people I usually blindly assume that they are wrong on everything they say, and check myself after the fact. I can always recant stuff in a follow-up discussion. This works quite well in general, and with certain people it's a slam dunk -- it never fails. They always spew crap, and while I may not be able to pin-point immediately why they are wrong, the assumption that they are wrong turns out always to be right.
I agree with you on everything else. It's hard to discuss in things in person without sitting in front of a web browser, ideally while being logged in to a university's VPN or library proxy so that you can access source material.
I don't think you understood what I said. "tell me how your engine did not get destroyed". I disagreed with clone53421 who claimed that it would destroy the engine. I claimed the only thing he will tell me is how nothing bad happened.
There is a continuous hydraulic circuit between the brake pedal and the brake actuators in Toyota hybrids. This circuits includes series electronically-controlled valves, just like in any ABS systems. Those valves can disable hydraulic brake function, of course, just like in any non-hybrid cars, and this functionality is also re-used for regenerative braking.
Blahblah. If you are a good driver and you know what you're doing, you can "win" with the engine using brakes. But you have to apply substantial braking force, and you must do it very quickly and decisively. Namely, you must know WTF you're doing. A little old lady won't "win" with a WOT on a modern car. Just google around, it has been shown rather conclusively.
If you apply too little braking force, the brakes will overheat, lose effectiveness, and from that point onwards will prevent you from stopping under WOT even if you suddenly realized what your mistake was. You'd have to wait for the brakes to cool down first, and hope that the pads aren't glazed over.
1. Back to reality please -- have you ever looked at a Fine Electrical Diagram of a modern car?
ABS/dynamic stability control systems are typically self-contained in the sense that they may be able to override 4WD power splitters and lower engine torque, but that's it. They run on their own CPU or two, and are a unit that's separate from the ECU, usually also manufactured by a different company than the ECU. They can't increase engine torque, absent synergistic bugs in the ECU firmware. And worst that can happen is that the brake function will be lost completely, but this is easy to feel: the brake pedal is pushed back up against your foot.
On an automatic transmission, the transmission will be in a gear that generates enough torque to overcome the parking brake, until you run out of engine's powerband, and that'd usually happen when you exceed 65mph anyway.
You see, when you drive an automatic, the only driver input to the engine system in this case is accelerator. You want to go faster, you depress it more -- that's a control loop in your brain. If you hold it down deep enough, the transmission will not upshift. And there's the end to your story.
I have not ever been a car that could not be brought up to 65mph with parking brake cable adjusted to manufacturer specs, and the brake fully engaged. No matter how "wimpy" the car was. This includes an old late 80s Honda Civic, various Volvo models (940, S40 mitsu, S80), various late model rental cars (2005-2009 models) and a European Daewoo model with manual transmission. Probably a dozen models in all.
1. Get in a car. Any car manufactured in the last 2 decades. Drive around for a bit to warm it up. 2. Park the car. Put transmission in neutral or park. 3. Floor the accelerator. 4. Tell me how your engine did not get destroyed.
See, this is a trivial experiment. Very trivial experiment, that everyone can perform. Yet you spread lies. Shame on you. Please stop.
It's the dreaded magic computer again, isn't it? Hopefully I can show that it's no magic, and that a lot of what you write is based on common misconceptions.
Saying "logging the data after it's been through the computer" is a strawman -- in a digital control system, all inputs and outputs are digital, and they are converted to/from analog signals. This is hardly a problem. The only way to log the data before it enters "the computer" is to, literally, get an analog tape recorder, or a chart recorder. There's no other way. A commonplace multitrack FM analog recorder weighs 100+ lb, and you may have problems fitting it on the passenger's seat. I have a few of those -- they use 1" tape, same as good old AMPEX helical scan video decks, and they are so bulky you need two people to move them.
The way the logging is likely to be implemented is quite simple. There will be a point in the control software where an input sample -- multiple channels' value from some time instant are in a nice vector. Quite likely a simple C struct of things. This vector is copied to a circular logging buffer, and the pointer is incremented. That's it. To save on logging space, the data may be decimated. That's about it. There can hardly be any "inaccuracies" in the logging application, unless it processes the data somehow -- perhaps they want to avoid aliasing in decimated data, and feed the data via a low-pass antialiasing filter. Of course if that filter is buggy, it'll corrupt the data, but that is rather easy to test for.
To detect subsequent data corruption in the log, each data sample may have a CRC attached to it when it's inserted into the buffer. That way you know that whatever is in the log is exactly what the digital controller saw.
Toyota is really using very non-technical speak when they "admit" that the recorder is not very robust. What they most likely mean is that because the data is stored in ECU's RAM, if you lose power the data will be lost. The ECU may have a supercap or somesuch to protect this RAM's contents during short power glitches, but that's about it.
To understand how it can all be rather so simple, you have to know how typical digital control software is designed. There is some input and output code, that collects data from various data sources (CAN bus, A/D converters, discrete inputs) and puts it into a nice input structure (think C struct or C++ class), and similarly takes the output structure and pushes the data out to the devices (CAN bus, D/A converters, discrete outputs). Those two parts can be well separated out, and usually are testable on their own. There may also be some networking and other housekeeping code that runs in the background, of course.
Then comes the actual digital controller, which maintains some internal state. The processing can be thought of as being done by a C function with following prototype (said function having only automatic variable declarations, and calling no other functions):
To say that there are "issue with the computer" then is just meaningless. If the computer hardware has problems, they will likely affect everything, and would be likely to result in a "crash", and the watchdog will do an automated reboot. The computer software can have many types of problems, and they can be squarely separated into two areas: the controller(...) function, and everything else -- we'll call it Housekeeping
Slashdot Mirror
Sigh, I agree...
I don't know if you're trolling or if there's a genuine misunderstanding.
All recent (as in 1-2 decades old) cars on the market have rev limiters. Thus you won't destroy them by over-revving them by applying accelerator alone.
When you shift into neutral, and the revs go to wherever the limiter keeps them at, there's no more engine torque applied to the wheels -- you should be able to apply the brakes and stop within a couple of seconds (assuming it's safe to stop).
You then turn of the screaming engine and no damage has been done. If you care about heat soak, you can then try and restart the engine to keep the water pump running for a bit -- perhaps it won't be stuck at WOT anymore.
I can test it that way today, no biggie, and even though Feynman would probably look funny at me for having entrenched expectations, I fully expect that nothing bad will happen solely due to this experiment. If something bad did in fact happen -- well, I guess the baby room remodel can wait then. /me ducks and runs
I wish I had money to buy some of their stock on the recent 247 dip. Would have got a nice 3% reward today. Methinks you got it backwards: those who bought the stock in the last 3 days probably are all in the green now.
Anecdotal evidence: I have used RedHat/Fedora on the home and work desktop since RH 4, until KDE 4 came out on Fedora Core. This was such a step back, that I simply went to the store, bought a long-needed replacement for the home PC and it was an iMac. Half a year later my Compaq laptop with Fedora and XP-in-a-VM on it got replaced by a MBP. I have no big complaints so far -- not anything out of the ordinary. Stuff gets design mistakes all the time, Apple aren't the only ones to mess up.
And that changes as we speak -- Slashdot effect? It's 255 now.
I guess there are two sides to this:
1. It "simply works" implying "... when the hardware works" -- I think this is what people mean. I find this to be quite true about Apple products I'm using (an iMac and Macbook Pro, both with Core 2 Duo CPUs with DDR2 RAM, with Snow Leopard).
2. It "simply works" implying "... all the time no matter what" -- I can't really speak to that. My own anecdotal evidence is inconclusive. In the last 3 years I've had the motherboard replaced on the iMac since the 2nd RAM slot would not work; the iMac also had the superdrive replaced; the MBP is due for a magsafe replacement (failing plug). But then I have a bunch of dead PC hardware at work, too, including a flaky Dell motherboard, a bunch of dead optical drives, a smoked power supply or two...
ABS is designed specifically to fail safe in presence of single and double faults. It'd be quite a coincidence for the ABS to fail such that the hydraulic circuits are isolated, and the throttle to WOT at the same time.
Probably I was wrong in my assumption that the ABS box on Toyota hybrids works the same as a regular ABS box. What I now think is that they changed it in '04 Prius.
The ultimate test would be to cut the power to the all the ECUs while the car is slowly moving -- perhaps in a big parking lot at night somewhere? I presume there's a fuse that would kill the ECUs, maybe it can be pulled from inside. A static test would also work: park on an incline, apply brakes, have someone pull the ECU fuse(s), see what happens. Do it safely (DUH).
I would really like to see some first-hand evidence, so if you spend time to do the actual tests I'd love to hear the results. One learns something every day. I guess I was too fast with condemning your opinion ;)
I'd say that you're overestimating how good the spouted "facts" are. My expectation is that the "facts" will be 100% crap, not 90% crap, and when talking to certain people I usually blindly assume that they are wrong on everything they say, and check myself after the fact. I can always recant stuff in a follow-up discussion. This works quite well in general, and with certain people it's a slam dunk -- it never fails. They always spew crap, and while I may not be able to pin-point immediately why they are wrong, the assumption that they are wrong turns out always to be right.
I agree with you on everything else. It's hard to discuss in things in person without sitting in front of a web browser, ideally while being logged in to a university's VPN or library proxy so that you can access source material.
Hmm, someone care to experimentally verify it. My wife is currently pregnant, so I can't test it out myself ;)
I don't think you understood what I said. "tell me how your engine did not get destroyed". I disagreed with clone53421 who claimed that it would destroy the engine. I claimed the only thing he will tell me is how nothing bad happened.
You don't have to read the manual. Do the experiment. Trace the fine hydraulic circuit yourself, with your own finger. It's not that hard.
Mod parent up!
Volvo S80 at least has had electronic throttle since release (in 1999).
And pigs fly. You missed where it said "during a tornado". Is it so hard to google stuff up?
See this Toyota Technical Training.
There is a continuous hydraulic circuit between the brake pedal and the brake actuators in Toyota hybrids. This circuits includes series electronically-controlled valves, just like in any ABS systems. Those valves can disable hydraulic brake function, of course, just like in any non-hybrid cars, and this functionality is also re-used for regenerative braking.
Blahblah. If you are a good driver and you know what you're doing, you can "win" with the engine using brakes. But you have to apply substantial braking force, and you must do it very quickly and decisively. Namely, you must know WTF you're doing. A little old lady won't "win" with a WOT on a modern car. Just google around, it has been shown rather conclusively.
If you apply too little braking force, the brakes will overheat, lose effectiveness, and from that point onwards will prevent you from stopping under WOT even if you suddenly realized what your mistake was. You'd have to wait for the brakes to cool down first, and hope that the pads aren't glazed over.
The fishiness is what's otherwise known as crowd mentality. No, I don't drive a Toyota nor do I work for them.
1. Back to reality please -- have you ever looked at a Fine Electrical Diagram of a modern car?
ABS/dynamic stability control systems are typically self-contained in the sense that they may be able to override 4WD power splitters and lower engine torque, but that's it. They run on their own CPU or two, and are a unit that's separate from the ECU, usually also manufactured by a different company than the ECU. They can't increase engine torque, absent synergistic bugs in the ECU firmware. And worst that can happen is that the brake function will be lost completely, but this is easy to feel: the brake pedal is pushed back up against your foot.
2. Agree.
On an automatic transmission, the transmission will be in a gear that generates enough torque to overcome the parking brake, until you run out of engine's powerband, and that'd usually happen when you exceed 65mph anyway.
You see, when you drive an automatic, the only driver input to the engine system in this case is accelerator. You want to go faster, you depress it more -- that's a control loop in your brain. If you hold it down deep enough, the transmission will not upshift. And there's the end to your story.
I have not ever been a car that could not be brought up to 65mph with parking brake cable adjusted to manufacturer specs, and the brake fully engaged. No matter how "wimpy" the car was. This includes an old late 80s Honda Civic, various Volvo models (940, S40 mitsu, S80), various late model rental cars (2005-2009 models) and a European Daewoo model with manual transmission. Probably a dozen models in all.
1. Get in a car. Any car manufactured in the last 2 decades. Drive around for a bit to warm it up.
2. Park the car. Put transmission in neutral or park.
3. Floor the accelerator.
4. Tell me how your engine did not get destroyed.
See, this is a trivial experiment. Very trivial experiment, that everyone can perform. Yet you spread lies. Shame on you. Please stop.
This is on a car with mechanical brakes. The brakes will leave behind evidence of having worked even if the ECU ignores them.
It's the dreaded magic computer again, isn't it? Hopefully I can show that it's no magic, and that a lot of what you write is based on common misconceptions.
Saying "logging the data after it's been through the computer" is a strawman -- in a digital control system, all inputs and outputs are digital, and they are converted to/from analog signals. This is hardly a problem. The only way to log the data before it enters "the computer" is to, literally, get an analog tape recorder, or a chart recorder. There's no other way. A commonplace multitrack FM analog recorder weighs 100+ lb, and you may have problems fitting it on the passenger's seat. I have a few of those -- they use 1" tape, same as good old AMPEX helical scan video decks, and they are so bulky you need two people to move them.
The way the logging is likely to be implemented is quite simple. There will be a point in the control software where an input sample -- multiple channels' value from some time instant are in a nice vector. Quite likely a simple C struct of things. This vector is copied to a circular logging buffer, and the pointer is incremented. That's it. To save on logging space, the data may be decimated. That's about it. There can hardly be any "inaccuracies" in the logging application, unless it processes the data somehow -- perhaps they want to avoid aliasing in decimated data, and feed the data via a low-pass antialiasing filter. Of course if that filter is buggy, it'll corrupt the data, but that is rather easy to test for.
To detect subsequent data corruption in the log, each data sample may have a CRC attached to it when it's inserted into the buffer. That way you know that whatever is in the log is exactly what the digital controller saw.
Toyota is really using very non-technical speak when they "admit" that the recorder is not very robust. What they most likely mean is that because the data is stored in ECU's RAM, if you lose power the data will be lost. The ECU may have a supercap or somesuch to protect this RAM's contents during short power glitches, but that's about it.
To understand how it can all be rather so simple, you have to know how typical digital control software is designed. There is some input and output code, that collects data from various data sources (CAN bus, A/D converters, discrete inputs) and puts it into a nice input structure (think C struct or C++ class), and similarly takes the output structure and pushes the data out to the devices (CAN bus, D/A converters, discrete outputs). Those two parts can be well separated out, and usually are testable on their own. There may also be some networking and other housekeeping code that runs in the background, of course.
Then comes the actual digital controller, which maintains some internal state. The processing can be thought of as being done by a C function with following prototype (said function having only automatic variable declarations, and calling no other functions):
void controller(const struct Input_t * inputs, const struct State_t * input_state, struct Output_t * outputs, struct State_t * output_state);
The previous state (input_state) and inputs are processed, resulting in a new state (output_state) and outputs. There are frameworks for safety critical digital control (say ), and they use exactly that sort of an abstraction. The controller(...) function is typically generated C code, and the code generator has various guarantees as to it being accurate (bug-free). The input and output glue code is simpler, and typically separately tested.
To say that there are "issue with the computer" then is just meaningless. If the computer hardware has problems, they will likely affect everything, and would be likely to result in a "crash", and the watchdog will do an automated reboot. The computer software can have many types of problems, and they can be squarely separated into two areas: the controller(...) function, and everything else -- we'll call it Housekeeping
I missed the part about it being a DSL line. Thought somehow it was a cable connection.
Care to cite the paragraph?