Searching \ for 'From Engine to Caboose, What's in the train?' in subject line. ()
Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=engine+caboose+whats
Search entire site for: 'From Engine to Caboose, What's in the train?'.

Truncated match.
'From Engine to Caboose, What's in the train?'
1999\10\12@094826 by

I would appreciate any input from the more experienced PIC users out
there on the best way to tackle the following problem:

Imagine you had a train, with a PIC chip (in this case a 16C505) in each
car.  Each car has a value, say a number assigned to it. The train is an
indeterminate length and the goal is to find out what the value of each car
is and what order they are in.  This all needs to be processed in the
Engine.

My solution was for the engine to act as a master chip to run the show.
It would start by asking the car behind it if there was a car attached
behind it. This would continue down the train, one car asking the next until
it came to the caboose.  At that point the caboose would take it's value and
transmit it to the car infront of it, which would append it's value to the
caboose's and trasnmit that. This would continue until it reaches the engine
where it would parse this giant string and then have the value of each car
and their order relative to it.

I was planning to do this all with two serial ports per car,
input/output on each side of the car to determine a left and right side.  If
anything is blatently wrong or could be done much better some other way I'm
open to suggestions and input.

Thank you

-Stu

Hej Azrael. Tack fšr ditt meddelande 09:45 1999-10-12 -0400 enligt nedan:
>     I would appreciate any input from the more experienced PIC users out
>there on the best way to tackle the following problem:
>
>     Imagine you had a train, with a PIC chip (in this case a 16C505) in each
>car.  Each car has a value, say a number assigned to it. The train is an
>indeterminate length and the goal is to find out what the value of each car
>is and what order they are in.  This all needs to be processed in the
>Engine.

One long shift register:

Each car has a parallel->serial shift register that can be loaded with value from DIP switches.

The serial output from the last car is connected to serial input of the next, etc.  Inputs also have pulldown resistors so unconnected input allways get zeroes in.

The engine drives one line that is directly connected between the cars.
In each car only a simple timer is needed for decoding:
Long pulse=Reload shift register from switches.
Short pulse=serial clock

Rule: each car must have at least one bit set; zero bit set=end of train.

The timer and shift register etc can be made of a 16C505, or a HC165 and i.e a quad NAND scmitt-trigger

Remember the heavy protection needed on the lines between cars!!
Probably you do not need high speed so that is easy; use pretty high resistor values, and cap and diode clamps.
The clock line from the engine is to be connected direcltly between cars, and from that bus thrpugh protection to the decoders.  The engine line driver needs to be strong, driving all train length wire and all car clock input protections.

Regards
/Morgan
Morgans Reglerteknik, HŠllekŒs, 277 35 KIVIK, SWEDEN
tel +46(0)414-446620, fax -70331,   mrtiname.com

What about using the dallas 1 wire serial numbers, using the 1-wire serial
search protocol? Then you only have the one wire to worry about, and I would
like to see some PIC code to do it.  I am trying to hook up a 1921 ibutton
to a PIC.

cya,    Andrew...

> {Original Message removed}
The only concerns that I see are:
1) A train with multiple engines
2) So many cars that eventually a PIC down the line couldn't hold the
resulting string before sending it along.

A method could be for the master to send a number down the line, and
each pic that gets it sends it along with a second number decremented
through each PIC.  When a PIC receives the two numbers with the second
one being zero, it sends it's address back as the first number.  Thus it
knows which place it is in, and the address could define what type of
car it was on:

Master sends 0 0
Next PIC returns (address) 0 0

Master sends 1 1
Next pic sends 1 0

etc.

A method to determine master status is to first test to see if their are
PICs on either side of you.  If there are both, then you are a slave
(nyah nyah!).  If only one exists, send a "I AM MASTER, HEAR ME ROAR!"
signal with a number starting at zero.  Each pic that gets that signal
increments it.  If a pic gets that signal from two masters (one on each
side) it finds out who was fastest by comparing the numbers, and sending
out two messages, one to the loser "You are a slave now, as lowly as I"
and one to the winner, "Congratulations, you've won the battle of wits."

Of course, in this case you'd need control characters (1 byte to precede
all communications)
One control says pass this data on, decrement and if it is zero reply.
One control says pass this data on without changes
One says pass this master contention on and increment the data
One says pass this message on, "you are master"
One says pass this message on, "you are not a master"

But there are infinetly many other ways.  The drawback with this one is
the longer the train, the longer it takes to get all the info for the
cars, much longer than your suggested method.

Azrael wrote:
{Quote hidden}

>    My solution was for the engine to act as a master chip to run the show.
>It would start by asking the car behind it if there was a car attached
>behind it. This would continue down the train, one car asking the next until
>it came to the caboose.  At that point the caboose would take it's value and

IMHO, the better way to do this is to ask the caboose "Who is in front of you?"

The caboose (and each car) when it receives this message, asks the same of
the one in front of it.

Each car replies with "Here is who is in front of me:"  which includes a
list of all prior cars, because each car concatenates it's name at the end
of the response IT got before returning the reply toward the caboose.

The tender (you DO run a steam train, I hope) would ask the Engine, which
would return a null string (if it were the first engine).

Think recursion.  The only limitation is that each car needs to be able to
store a message which is sufficiently long to hold all cars in the train.

This is, in a way of thinking, what the "trace route" function does in a
network.

Oh, wait a second...  This is assuming you have a multi-drop connection.
If you are using two serial ports on each device, it isn't quite as nice.
The same idea applies though, because a device _could_ be programmed to
simply forward a message not addressed to itself.

Andy

==================================================================
Eternity is only a heartbeat away - are you ready?  Ask me how!
------------------------------------------------------------------
andyrc-hydros.com      http://www.rc-hydros.com     - Race Boats
==================================================================

The following url is a piece of text I wrote long ago to help someone,
while waiting to convert it a better looking page.  I hope it can help
you somehow.

http://www.ustr.net/8051pc/8051pc.shtml and select "serial"

Wagner

The "cars" are wired in a chain output to input as described before,
and in in the opposite direction as well.  This would require
three lines: ground, data out, data return.

-----     -----     -----     -----     -----     -----
|   |---->|   |---->|   |---->|   |---->|   |---->|   |
|ENG|     |CAR|     |CAR|     |CAR|     |CAR|     |CAR|
|   |<----|   |<----|   |<----|   |<----|   |<----|   |
-----     -----     -----     -----     -----     -----

Each car has a unique address.

The engine sends out each possible address and waits for a reply.

Each car checks the address passing through it.  If it matches, then
it somehow marks the address by setting a bit or even several bits
indicating its car type / status.  If the address returns to the engine
without being marked, then the car addressed is not present.

This eliminates the growing message length problem, but introduces
the problem of having a potentially large number of addresses to try.

Another approach using the same topology would to have the engine
send out a single command requesting that each car identify itself.

If car received this message then it transmits its address back up
the chain, then passes it on to the next car.  If a car receives
a message from a car farther down the chain which is heading back
toward the engine, then it just passes it along.  The caboose
would have some kind of flag to indicate that it is the last car
and the engine can stop listening for replies.

I may have repeated someone else's reply here, but I hope that
my own perspective contributes somehow.

Dan

On Tue, 12 Oct 1999 11:09:47 -0400, Andy Kunz wrote:

{Quote hidden}

The first problem I see is what happens when one wagon gets coupled up the
opposite way round to what it is used to. this is solved by having the PICs in
the cars listen on both sides, and the first side which sees a communication is
the one towards the master end. transfer query message to other side, and when
message comes back through, add my own ID on the end.

This also assumes that there will also be a caboose on the end to act as end of
train marker.  I would have a timeout so that if an echo from the caboose end
did not happen within a timescale of (say) 5 message transit times for the
longest train, then send urgent message to master end (here I assume loco) that
the train is broken, and the Westinghouse brakes should go into failsafe mode!

It appears to me that you have a linked list (a real one!). If you are
designing from scratch, then treat it as such and there are a bazillion
algorithms to solve the problem.   Your solution would work.  I have
included a slight change to it (I think):

(abstract stuff coming up):

// set
current=engine;

// traverse

while(current->next != NULL)
{
visit node (send serial upstream)
current=current->next; (contact the next car in line)
}
report NULL found after the current car

// reset
current=engine;

The engine will trigger the request, it will be echoed down line and serial
numbers will be echoed back ending with a NULL broadcast.

All the above will translate to a connection scheme that emulates a linked
list.  You can add cars on and take them off, the result will always work if
you start at the head of the list and work back.  No assumptions are made
about car type (caboose, engine, or other). Use two one wire interfaces (one
forward, one back).

Possible problems include slow configuration reporting for very long chains.

Dan

{Original Message removed}
You don't need to store the message to curse down the train.

On seeing a "who are you" message, the car first transmits it's
own number, then asks it's trailing
car "who are you?" , and retransmits each byte as it comes in.

You have an additional complication or two here.
1. the cars can be turned around, and won't know their orientation
in the train.

2. if this is a model train powered by blocks, or going over switches,
or on dirty track,
the ground path will occasionally be interrupted for a few mSec.

Here's another scheme.

Engine transmits a "who are you" message, along with a byte that indicates
which car in the sequence is to respond.  The first car looks at the byte, and
if it isn't zero, decrements it and passes it on.  This repeats until a car sees
a zero, and then responds.  End-of-train detection could either be by
timeout, or by a message returned by the last car when it doesn't see any
handshaking when it attempts to talk to the next car.  All cars retransmit
messages on the opposite end from which the message was received, thus
resolving the problem with cars being connected the wrong way.
Addressing for any other messages to specific cars could then be done
either by using the responses to the "who are you" query (these would have
to be unique for this) or you could continue to use the "decrement and pass
it on" method to address them by their position.

An advantage of this scheme is that the engine can query cars at will rather
than having to keep up with a flood of incoming data.  It would also be
possible for the engine to perform this on both a front and rear port so that it
can be located anywhere in the train.  It still assumes only one engine
though.  For multiple engine trains you'd have to implement some kind of
arbitration, or just put a switch on each engine to select master or slave
mode.

{Quote hidden}

---
Peace,
William Kitchen
billiglobal.net

The future is ours to create.

Stu,
Another way to do the same thing would be to have the Master
send out a query code to the car behind it. As each car receives
this query, it *first* sends its own ID code back up the chain
towards the Master, and then it passes the query code on to
the car behind it.

Each car keeps looking for the returned ID codes and simply
passes them on up the chain until they ultimately all reach the
Master. Whenever a car passes a query code down the chain and
it can assume that it is the last car, and then it would
*also* send an END-OF-CHAIN ID code, such as 0x0.

Cars further up the chain would pass this END-OF-CHAIN ID code
up the chain just like all the other ID codes they have received.
Once a car has passed along the END-OF-CHAIN ID code, it no
longer needs to look at the data coming from behind it.

Note that the Master must also detect an END-OF-CHAIN condition
when it sends out a query and gets no answer within a reasonable
period of time.

The method outlined above will return the ID codes in the
order in which the cars are connected, and each car is only
dealing with one returned code at a time.

Fr. Tom McGahee

{Original Message removed}
Had a similar problem once with connecting data loggers on trash trucks
which might be up to three trailers long--and came up with a very similar
solution.  Only problem was that the client went belly-up before we could
implement it.  Your real problem will be wiring the whole thing
together--Industrial connectors and cable suitable for rail applications
will probably cost several orders of magnitude more than the ID device with
the PIC.  Your serial number will also have to be large enough to uniquely
identify every rail car that may ever be connected together.

Also, if there is an IN and OUT serial port on each car--which assumes each
PIC must receive and retransmit any data going down the sequence--then ANY
failure of any PIC will kill the whole system.  Multi-drop would solve
this, but give no way of identifying the sequence of the cars.

Add some monitoring for 'Hot Box" problems, temperature in refrigerated
cars, etc., and the project might be economically feasible and very
marketable.

I thought rail cars had bar codes painted on the sides these days, along
with track-side monitoring units that would report to some-one who in turn
could notify the engineer on the train??

kelly

At 09:45 AM 10/12/99 -0400, you wrote:
{Quote hidden}

William K. Borsum, P.E. -- OEM Dataloggers and Instrumentation Systems
<borsumdascor.com> & <http://www.dascor.com>San Diego, California, USA

The CSMA model of Ethernet comes to mind.  One could have a
data line and a return, possibly through the track but not
necessarily.  The Caboose could have a pull-up resistor and everything
else including the engine would look for a +5-V signal on the network
to know the train was complete.  The engine or master would send some
sort of start signal which would cause all the other PIC's to start
timers whose count-down values were based on their ID numbers so that
no two would try to start transmitting simultaneously.

The timer with the lowest value would time out first and
transmit its ID number.  As long as it was transmitting, the other
PIC's would notice this and keep resetting their timers.  When the
talker finished, the timer with the next shortest seed value would
time out and send its ID.  This would go on until all timers had fully
timed out and caused their ID numbers to be sent.

The engine would actually record each number.  The rest of the
cars would only have to sense that data were on the bus and that they
should keep resetting their timers.

This is a simple idea and there are a couple of things that
are wrong.  A car with a defective ID'er would not necessarily cause
anything unusual to happen.  It would just not be heard from each
time.

The engine and Caboose must always be at the beginning and end
of the train in order to prevent the possibility of segments becoming
disconnected without causing any kind of indication.

The main advantage to this kind of setup is that each PIC
would not have to relay or make note of any information other than
whether or not the network was presently occupied.

Martin McCormick WB5AGZ  Stillwater, OK
OSU Center for Computing and Information Services Data Communications Group

>I thought rail cars had bar codes painted on the sides these days, along
>with track-side monitoring units that would report to some-one who in turn
>could notify the engineer on the train??

There are track side units that look for dragging equipment and hot
bearings.
They don't ID the car (they just say how many axles back in the train it
is).

Cars once had colored stripes called "ACI labels" , but the system was never
reliable and was discontinued - basicly a case of being ahead of the curve.
Recently a similar system's been reintroduced, with a transponder instead of
the label.

You mentioned other things the PIC could do. The most important would be
actuating the air brakes. Electropneumatic air brakes have been a dream of
RR people for years. If you have a mile long freight and you open the train
pipe
that runs the length of the train, it'll take some time (during which the
train is bearing
down on a school bus) to empty the air from the rear car.
Unfortunately, the difficulty of making a reliable electrical connection
that won't
be a maintainence nightmare for the approximately one million RR cars out
there
has proved beyond solution.

The problem with any multi-drop method is that there is no
way of knowing the physical ordering of the cars, since
the physical electrical structure is parallel, not serial.

A hybrid approach might work, though. A multidrop line
would be used by each car to communicate with the Master.
In addition, a single serial type connection (from A to B to
C, etc) would be implemented as a SHIFT line function.

The Master would initiate things by sending a code out on
the multidrop line to inform all cars that a SHIFT is in
progress. The Master would then pulse the SHIFT line. When
the first car sees the SHIFT pulse, it would answer by
first sending it's ID out on the multidrop, and *then*
sending a SHIFT pulse to the NEXT car down the chain.
This car would do the same: send its ID, and then send a
pulse on the OUT SHIFT line. A delay equal to the
SHIFT pulse width would effectively separate each ID as
it appeared on the multidrop line. Eventually there would
be no more cars responding, and the Master would know
this because after a known amount of time the expected
ID codes would cease coming in.

Each car would need a SHIFT IN, a SHIFT OUT, and a
MULTIDROP IN/OUT line. Flexibility could be achieved
by making both SHIFT lines IN/OUT and initially an
INPUT. Upon reception of a SHIFT pulse on one line, it
would use the other line to SHIFT OUT, and then return
to input mode.

**** HOWEVER....
I think that you could do the WHOLE thing with just two
bi-directional lines. See my earlier post for
the general idea: Master sends request down chain. Cars
respond by sending back their ID and passing the request
down the chain. Each Car then passes back the IDs as
they are sent back up the chain. Eventually the last car
in the chain determines that it is last, and it sends
back the 0x0 ID that means End-Of-Chain.

Note that this setup works even if the Master is in the
middle of the chain segments.

Fr. Tom McGahee

{Original Message removed}
For turning cars around, we need some kind of hermaphrodite connectors.
Connections can be arranged so serial shift register would work, IMHO
/Morgan
Morgans Reglerteknik, HŠllekŒs, 277 35 KIVIK, SWEDEN
tel +46(0)414-446620, fax -70331,   mrtiname.com

At 17:20 12/10/99 +0100, you wrote:
>The first problem I see is what happens when one wagon gets coupled up the
>opposite way round to what it is used to. this is solved by having the
PICs in
>the cars listen on both sides, and the first side which sees a
communication is
>the one towards the master end. transfer query message to other side, and
when
>message comes back through, add my own ID on the end.
>
>This also assumes that there will also be a caboose on the end to act as
end of
>train marker.  I would have a timeout so that if an echo from the caboose end
>did not happen within a timescale of (say) 5 message transit times for the
>longest train, then send urgent message to master end (here I assume loco)
that
>the train is broken, and the Westinghouse brakes should go into failsafe
mode!
>
>

The brake will be in failsafe mode as there will be no backpressure, lost
of sparks on the wheels of the trailing carriges! <G> (Kids love doing this
too)

Dennis

Anne Ogborn wrote:
{Quote hidden}

Why make an electrical connection?  (Assuming you have power on each car
- use a small solar cell to top off a small Lead-Acid battery pack,
would probably work rather well.)  Use IR for connections, with an IR
I/O port on the front and rear of each car/engine/caboose, right next to
the coupler - have a simple shutter that opens when the couplers lock
together, and you're probably set.  Photodiodes & LED's are pretty
low-maintenance.  Shutter could be pretty easy to make, actuated off the
coupler's movement...  I suspect the same location could be used for
electrical connections, also, using a large spring-loaded plunger for
each contact, possibly.)  If the shutter's closed, have it connect the
In and Out pins together, so you know you're at the end of the train.

Mark

At 18:03 12/10/99 -0700, you wrote:
>Anne Ogborn wrote:
>>
>> >I thought rail cars had bar codes painted on the sides these days, along
>> >with track-side monitoring units that would report to some-one who in turn
>> >could notify the engineer on the train??
>>
>> There are track side units that look for dragging equipment and hot
>> bearings.
>> They don't ID the car (they just say how many axles back in the train it
>> is).
>>
>> Cars once had colored stripes called "ACI labels" , but the system was
never
>> reliable and was discontinued - basicly a case of being ahead of the curve.
>> Recently a similar system's been reintroduced, with a transponder
{Quote hidden}

You have never worked on rail have you <G> How long before the solar cell
and the battery is knocked off? How long before it is broken

Both around 3 days!

Dennis

Dennis Plunkett wrote:
{Quote hidden}

No, I haven't;  I've built stuff for the Arctic, where the Caribou & the
Polar bears try to nibble anything they see, just in case it might have
calories <G>  They don't much like PVC sleeving, with a filler of grease
around the Urethane cable, and same thing solves the Frost Heaving
problem...  I figure a nice, solid unit COULD be made, and I like a
challenge <G>  (I joke about making a company, "Monolithic Engineering",
sometimes, we've made a couple housings that I don't think you could
break short of using a shaped charge.  OTOH, "Never dare a SysOp", or an
engineer, to break something; as a matter of fact, they *would* do so!
<G>)

Instead of Solar, you could power these off a wind generator, or by the
"Motorcycle Alternator" principle, spin a generator off a wheel to
charge the battery up, or have the wheel magnetized & energize a coil,
etc...  Make the housing of 3/8" steel, bent (to pre-stress it) and
welded, if necessary, and the shutter of 1/8" steel, that'd be pretty
tough to break off "by accident".  Cover the solar panel with SAR
plastic, perhaps.

Mark

Mark,

Where I live, all the train cars come from coal mines. There are red cars,
grey cars and black cars, and all have a giant CPR logo on them, yet at the
same time, they are all black (dust). The shutters would work for the first
week, then they would be plugged with dust, and the solar panels coated with
dust (Most likely smashed to pieces too!). Go into an office 'on the hill'
with an open pit mine. Open up anything (photocopier, computer, etc.) and
you will find coal dust.

Have a look beside a coal train track in winter. Have you ever seen black
snow?

Also, I imagine there would be people that would be happy to 'liberate' all
those solar panels and batteries :)

- Keelan Lightfoot

{Quote hidden}

I think the main thread got lost.

I believe that Azrael's post using the train example, was just to help
him to explain his necessity to attach several (undefined quantity)
devices with different (unknown) addresses to a communication network,
as we do with ethernet cards in a Local Area Network. I understand that
it has nothing to do really with a train composition.

If you read again his original post, he says:  "Imagine you had a train,
with a PIC chip ...", it sounds clearly to me just as a way to show the
idea.

Even that any technical discussion is healthy and should be encouraged,
I believe he has not a train, and not even a railroad.  If yes, do you
already saw a car engaging at the composition? what kind of "small and
tinny" connector would you use to connect this communication link
between two cars? this is at least a crazy idea, as to use an elephant
foot to help to position a SOIC device over the PCB....:)

I am following this thread, since I worked all my life in data
communication. I saw some suggestions and want to clarify some points:

First of all lets read again his words:
"The train is an indeterminate length and the goal is to find out what
the value of each car
is and what order they are in.  This all needs to be processed in the
Engine.

1) Indeterminate length means from one to somehow 50 billion modules or
more, so forget any solution that will try to "scan" all possible

2) "What Order they are in", means that the communication *SHOULD BE* in
request in the order they are installed at the network (and received the
request). Just forget any "multi-drop" or parallel network.  It is
impossible to identify which is in front or at the rear without using a
sequenced connection. Also forget about to use cable distance
propagation delays (in a short distance multidrop), you would need an
expensive system to identify it.

3) The easiest way to think about it is just "passing a guest book" to
be signed by a line of people, everyone just write down his name, that's
it, simple.   The book just need to be signed by one person at time and
passed ahead, the last one just return the book to the house owner,
closing the loop.

4) A simple and efficient communication ring is the answer. Of course,
if the next person in the line is missing, the book will be delivered...
to the floor, so the last signee person needs to extend his arm and
reach the next person available in the line. It means that a missing (or
defective) station should be bypassed by a relay contact that was not
activated by the "good station status port pin".  So in real, the ring
is composed by a bunch of relays, that opens its contacts and insert a
station when it is plugged in and is available to communicate.

This connector can also supplies power to the stations, as well a
delayed "power-on-reset".

...but if Azrael gets a train, and is dealing with nice and heavy tools,
I apologize to y'all... :) and *if it is real* for that task he should
use those just released V.I.D.'s (Vehicle Identification Devices) with
10 miles range (2 Watts) GHz uWave communication (64kbps and TCP/IP)
everything incorporated in the SOIC 9 pins chip (does not need
antenna)... http://www.vid.com or http://www.iAMKIdd.ing/VID.html ;)
will ya? oh my, how many already clicked the url?

Wagner.

PS: Come on, today was the children's day in Brazil.

----- Original Message -----
To: <PICLISTMITVMA.MIT.EDU>
Sent: Tuesday, October 12, 1999 7:42 PM
Subject: Re: From Engine to Caboose, What's in the train?
> ...but if Azrael gets a train, and is dealing with nice and heavy tools,
> I apologize to y'all... :) and *if it is real* for that task he should
> use those just released V.I.D.'s (Vehicle Identification Devices) with
> 10 miles range (2 Watts) GHz uWave communication (64kbps and TCP/IP)
> everything incorporated in the SOIC 9 pins chip (does not need
> antenna)... http://www.vid.com or http://www.iAMKIdd.ing/VID.html ;)
> will ya? oh my, how many already clicked the url?

Duh, I clicked it.

> Imagine you had a train, with a PIC chip (in this case a 16C505)
> in each car.  Each car has a value, say a number assigned to it.
> The train is an indeterminate length and the goal is to find out
> what the value of each car is and what order they are in.  This
> all needs to be processed in the Engine.

Assuming that each unit has 2 serial-like interfaces, you can
have the engine poll both forwards and backwards from itself.

Algorithm in each car watches both serial port receivers.  An
address field is in each packet.  I'd make it big enough to hold
4 or 8 times the longest expected train.  When a packet is

Assume a packet is received on arbitrary interface A.

If the decremented address field is 0, it formats a message
containing it's own unique ID, plus any additional information
desired, and transmits it back out interface A (the same one

If the decremented address field is greater than zero, the unit
transmits the modified packet (decremented address field but
otherwise unchanged) out the other port (i.e. interface B).

Depending on inter-car protocol details, car (n) may be able
to quickly determine if another car is hooked to that other
port and is operating.  This can be used for error checking
and correction.  Car (n) can also use the absense of a "next
car" to create a special message packet to send back out the
originating port that the "next car" is not responding.

This method prevents a packet from getting too large for a
PIC's buffer memory.  It also allows the units to be hooked
up any which way.  Requiring that one specific interface be
hooked to the "engine" side and the other to the "caboose"
side is guaranteed to cause problems in the field.

Downside is that the master unit in the engine has to poll.

I'd also use a highly noise-resistant electrical interface.
Maybe use optical coupled interfaces if practical; depends
on power distribution between cars and to units.

Lee Jones

>Why make an electrical connection?  (Assuming you have power on each car
>- use a small solar cell to top off a small Lead-Acid battery pack,
>would probably work rather well.)  Use IR for connections, with an IR
>I/O port on the front and rear of each car/engine/caboose, right next to
>the coupler - have a simple shutter that opens when the couplers lock
>together, and you're probably set.  Photodiodes & LED's are pretty
>low-maintenance.  Shutter could be pretty easy to make, actuated off the
>coupler's movement...  I suspect the same location could be used for
>electrical connections, also, using a large spring-loaded plunger for
>each contact, possibly.)  If the shutter's closed, have it connect the
>In and Out pins together, so you know you're at the end of the train.
>
>  Mark
>

Environment:
Severe vibration, repeat 50G shock loads, vandalism, severe dust, impact
water immersion, snow immersion, steam spray, grit spray, dirt immersion,
chemical
exposure to multiple, random chemicals, corn syrup immersion, acid gas
exposure,
bombardment by material thrown up from wheels (sand, etc. on tracks, bits of
brake lining)
temp of -40 to 120F, pennies fired from under wheels at high speed, gunfire,
molten metal
spray,  installation by unskilled personnel, industrial sabotage by workers
looking for a way to halt work or
mess with coworkers, impacts from crane hooks, whipped with released slings,
poling pressure (RR cars are sometimes pushed with a truck or a loco with a
pole - yes
Virginia, it still happens - A car can weigh 100tons, and they might choose
to push), knife attacks on sensor opening (who knows why, but it happens),
employees who
fear change (yep, real consideration), impacts from gladhands, ....

oh, yes, and this is a high reliability environment - at1 failure per 1
million
device-days you cost the RR's \$1.8 million/yr  (\$5000 per failure)

Annie

At 10:27 PM 10/12/99 -0700, you wrote:
>temp of -40 to 120F, pennies fired from under wheels at high speed, gunfire,

LOL! The great penny menace!

Sean

|
| Sean Breheny
| Electrical Engineering Student
\--------------=----------------
Save lives, please look at http://www.all.org
Personal page: http://www.people.cornell.edu/pages/shb7
shb7cornell.edu ICQ #: 3329174

At 12:23 PM 10/12/99 -0700, you wrote:
>actuating the air brakes. Electropneumatic air brakes have been a dream of
>RR people for years. If you have a mile long freight and you open the train
>pipe
>that runs the length of the train, it'll take some time (during which the
>train is bearing
>down on a school bus) to empty the air from the rear car.
>Unfortunately, the difficulty of making a reliable electrical connection
>that won't
>be a maintainence nightmare for the approximately one million RR cars out
>there
>has proved beyond solution.
>

This is going to sound like a really odd idea, but I will throw it out
there anyway ;-)

I always wondered why no-one tried (or maybe they have?) to develop some
kind of breaking system for RR cars that didn't depend on the wheels (for
example, solid-fuel rocket motor) that could be used in an extreme
emergency to stop the train QUICKLY. I realize that this is changing the
subject slightly from the safety concern you mentioned, but it made me
think of it.

Sean

|
| Sean Breheny
| Electrical Engineering Student
\--------------=----------------
Save lives, please look at http://www.all.org
Personal page: http://www.people.cornell.edu/pages/shb7
shb7cornell.edu ICQ #: 3329174

> I always wondered why no-one tried (or maybe they have?) to develop some
> kind of breaking system for RR cars that didn't depend on the wheels (for
> example, solid-fuel rocket motor) that could be used in an extreme
> emergency to stop the train QUICKLY. I realize that this is changing the
> subject slightly from the safety concern you mentioned, but it made me
> think of it.

It's a problem of getting rid of the energy. You could maybe do something
that drops down and digs up the trackbed, but rockets would be a BAD idea.
Barbecueing railroad workers at random would probably upset the union, and
after a derailment, it would be an interesting task to get in there with
rocket motors live in the mix.

I wouldn't mind getting some spares after the project was scrapped though,
that would be at least an S class motor, probably more like V.. :)

<x-flowed>anderson power poles are genderless

At 10:38 PM 10/12/99 +0200, you wrote:
>For turning cars around, we need some kind of hermaphrodite connectors.
>Connections can be arranged so serial shift register would work, IMHO
>/Morgan
>Morgans Reglerteknik, HŠllekŒs, 277 35 KIVIK, SWEDEN
>    tel +46(0)414-446620, fax -70331,   mrtiname.com

Wes
kd4rdbusa.net
Stupidity should be painful
__________________________________________
NetZero - Defenders of the Free World
Get your FREE Internet Access and Email at

</x-flowed>
Sorry I'm a little behind in my reading, but this thread piqued my interest
a bit.  Many railroads are going to RFID tags on each car.  While visiting
the Norfolk Southern yard in Chattanooga (I work for WABCO, the inventor of
the automatic air brake, and I get to play with trains a bit), I got to see
some of this equipment.  While there were no Pics to be seen, it was neat to
see the wayside equipment call the office and download the list of cars in
the train to the computer.  There was also a synthesized voice that came
over the radio after a train passed and announced the time, date, and number
of cars that had just passed.

{Original Message removed}

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...