From: Scott Dorsey on
In article <97ovp51pf8l1c2icv7p1dvq6oisuvsq7rn(a)4ax.com>,
Dean Dark <dmdrake(a)gmailNOTTHISPART.com> wrote:
>On 16 Mar 2010 15:26:18 -0400, kludge(a)panix.com (Scott Dorsey) wrote:
>
>>>I've been in the computer business since I joined IBM in '65. Seen
>>>untold 1,000's of references to a/the [system] bus, but have never seen
>>>it spelled with 2 esses. To me a "buss" is a kiss. Now to the dictionary...
>>
>>Sure, but IBM always makes up silly words for things that nobody else
>>uses, like IPL and DASD.... but yeah, it was official IBM policy to
>>spell it "bus" and to call an external I/O bus a "channel."
>
>Not just IBM. I've worked in that business since nineteen <mumble>
>canteen and "buss" was only ever used to refer to an electrical
>(power) bus (hence buss fuses), which is quite a different animal. I
>can't think of any computer maker who called his backplane a buss.

Try the original S-100 Buss:
http://www.pldos.pl/bogus/hardware/komputery/mits/pemag0175.htm
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
From: Dean Dark on
On 16 Mar 2010 16:26:25 -0400, kludge(a)panix.com (Scott Dorsey) wrote:

>In article <97ovp51pf8l1c2icv7p1dvq6oisuvsq7rn(a)4ax.com>,
>Dean Dark <dmdrake(a)gmailNOTTHISPART.com> wrote:
>>On 16 Mar 2010 15:26:18 -0400, kludge(a)panix.com (Scott Dorsey) wrote:
>>
>>>>I've been in the computer business since I joined IBM in '65. Seen
>>>>untold 1,000's of references to a/the [system] bus, but have never seen
>>>>it spelled with 2 esses. To me a "buss" is a kiss. Now to the dictionary...
>>>
>>>Sure, but IBM always makes up silly words for things that nobody else
>>>uses, like IPL and DASD.... but yeah, it was official IBM policy to
>>>spell it "bus" and to call an external I/O bus a "channel."
>>
>>Not just IBM. I've worked in that business since nineteen <mumble>
>>canteen and "buss" was only ever used to refer to an electrical
>>(power) bus (hence buss fuses), which is quite a different animal. I
>>can't think of any computer maker who called his backplane a buss.
>
>Try the original S-100 Buss:
>http://www.pldos.pl/bogus/hardware/komputery/mits/pemag0175.htm
>--scott

That's a Plopular Mecanicks article, and they can't even spell
"Altair." The 8080 was a decent chip in its day, but Intel didn't
call its communication system a buss, it was a bus. People who wrote
about it may have called it a buss, but Intel didn't. Sorry, try
again.
From: Paul Hovnanian P.E. on
jim beam wrote:
>
> On 03/15/2010 03:39 PM, Paul Hovnanian P.E. wrote:
> > jim beam wrote:
> >>
> >> if you buy all this fear-mongering idiocy that electronic throttle is a
> >> problem, and that brakes, transmissions and ignition kill switches can
> >> all simultaneously fail causing a driver to lose control, it might be
> >> worth auto manufacturers of all stripes to adopt a slightly different
> >> implementation of electronic throttle [e.t.] - if not for mechanical
> >> reasons, but to shut the idiots up.
> >>
> >> first, lets understand e.t. functionality:
> >>
> >> 1. open the throttle when demanded
> >> 2. close throttle when demanded
> >> 3. allow "demand" to account for additional requirements like
> >> a. de-throttle on shifting for automatics,
> >> b. throttle appropriate to load at high demand [eg. full throttle at
> >> low rpms can choke an engine and significantly reduce output - thus
> >> de-throttle until revs support full open]
> >>
> >> if we analyze the above [which is not exhaustive, but representative],
> >> we find that in almost all situations, an e.t. needs to be more closed
> >> than demanded, but seldom, if ever, more open.
> >
> > I can think of two exceptions: Cruise control
>
> yes, cruise would be the facer.
>
> > and idle control
>
> have to revert o idle air control valves.
>
> > (for
> > engine loads like air conditioning). In addition, mechanical throttles
> > are often equipped with dash pots or other overrides to keep them from
> > slamming shut too fast.
> >
> > The idea behind electronic throttles is that with one actuator, all of
> > these functions can be implemented in software.
>
> i got that. the problem is the political dimension of how to implement it.

Not political, economic.

Doing all this stuff in software is cheap compared to even the simplest
mechanical implementation. Fine tuning and revising the system's
behavior is much easier if its all done in a chip as well.

--
Paul Hovnanian mailto:Paul(a)Hovnanian.com
------------------------------------------------------------------
Windows tip #248: add BUGS=OFF to your registry.
From: Tony Harding on
On 03/15/10 12:22, Rodan wrote:
> "jim beam"<me(a)privacy.net> wrote;
>
> dude, you're utterly clueless. this is about control systems.
> diesels have had control systems from day one.
> have you any idea /why/ they're always used?
> what would you have us do to them?
> ______________________________________________________________
>
> Please ask an experienced diesel mechanic that question.
> Surely he/she will tell you that diesels have no throttle
> plate to control, therefore no use for a throttle plate cable.
>
> As you gain experience as a devil's advocate, please try
> to keep your demurrals related to the subject at hand,
> lest your sincere postings be mistaken for trolling.
>
> Rodan.

Hm, you seem very thoughtful.

From: Dillon Pyron on
Thus spake jim beam <me(a)privacy.net> :

>On 03/11/2010 06:04 PM, Dillon Pyron wrote:
>> Thus spake Bill Putney<bptn(a)kinez.net> :
>>
>>> jim beam wrote:
>>>> if you buy all this fear-mongering idiocy that electronic throttle is a
>>>> problem, and that brakes, transmissions and ignition kill switches can
>>>> all simultaneously fail causing a driver to lose control, it might be
>>>> worth auto manufacturers of all stripes to adopt a slightly different
>>>> implementation of electronic throttle [e.t.] - if not for mechanical
>>>> reasons, but to shut the idiots up...
>>>
>>> The lawyers, politicians, and news media can convince the public of the
>>> impossible (failure even a totally fail safe system) any time they
>>> decide to do it depending on political or monetary motivation. IOW -
>>> the people and companies who do a good job of designing are going to get
>>> punished anyway (unless they know how to play the game in a corrupt
>>> system). There are people in our society whose life goal is to make
>>> sure that that happens.
>>
>> The people who are pushing this issue have no idea about complex
>> software systems. You can not test for all of the potential
>> combinations of events.
>
>dude, the numbers of inputs for a car is not only finite, it's actually
>quite small. it's also very well mapped. the "combinations of events
>is" therefore very testable.

The combination? Let's say we have air temperature, humidity, air
speed (all at some position in the inlet system), throttle position,
vehicle speed, gear selected, engine speed. Temperature, humidity and
speed all are used to calculate air mass. Okay, we have 7 inputs.
Small number. How many potential combinations of input numbers do we
have? Air temp = 0C. Humidity = 50%. Air speed = 100 m/s. Throttle
position = 35%. Gear = 4 (out of 5). Engine speed = 3500 rpm. That's
one. Air temp = 35C. Humidity = 75%. Air speed = 100 m/s. Throttle
position = 55%. Gear = 2. Engine speed = 4800 rpm. Two, shall we go
on?

Any selection of the above may result in an out of bounds situation
whcih the software may handle in any one of a variety of well defined
conditions. Or it may fail. I've been involved in the development of
a number of "fault tolerant" systems where we had an out that said
that the system might fail or behave erratically in the event of
"multiple simultaneous failures". In the one of these systems, the
number of inputs was only 12 and the number of permitted failures was
3 (more than 3 = MSF). Customer throw 800 different scenarios with
more than 3 failures. We found another 1500. Customer wanted to go
to 5 permitted failures. We told customer "write us a check for
another $175 million". Said system currently lives on 3 failures. Oh,
of the 2300 potentilal failures, none have occured. But the system
has collapesed three times due to other combinations of events that
none of us could have predicted.


>
>
>>
>> Backing off on the throtle while getting airborn at the crest of a
>> hill with the brakes gently applied and the A/C on? I can come up
>> with hundreds and hundreds more. And everyone her can probbly match
>> those numbers without a repeat.
>>
>> The EE who hacked a failure is an academic, not a real world person.
>
>he shorted two wires. any car would react in some way to that.

Yes. But was that considered to be one of the testable parameters?
Here's the magical part of this. The software guys can only test for
situations that are in the realistic to marginally realistic range.
The hardware guys had a very, very high level of confidence that the
event that he demonstrated would not happen. And his effort required
significant work on his part to effect.

Have you ever been involved in complex systems development?
>
>
>> You have to apply the 20-80 rule. 20% of the problems will generte
>> 80% of the failures. You are more likely to grind a brake pad to
>> metal than to have the concotted failure he caused. Much more.
--

- dillon I am not invalid

You know, I can't think of nothing finer than a fine
naked woman holding a gun. And you got all kinds of
fine going on.

Frankie Figs