To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.org.ca.rtltorontoOpen lugnet.org.ca.rtltoronto in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Organizations / Canada / rtlToronto / 788
787  |  789
Subject: 
Re: Train1 Reversing loop
Newsgroups: 
lugnet.org.ca.rtltoronto
Date: 
Sat, 28 Apr 2001 23:24:13 GMT
Viewed: 
605 times
  
If you weren't already aware, your reversing loop needs to be
electrically isolated from the main line. The idea is that before the
train enters the loop, the reversing line is given the same polarity
(at it's start) as the main line so the train continues on. Once in
the reverse loop, the main line polarity is changed to match the
reverse loop's polarity at it's exit so that the train will continue
uninterrupted. Standard model railroading practice.
For the sake of clarity, I don't know what else to call it so I'll use
the name "drop zone" to refer to the area through which cargo is
loaded into the car by means of  being dropped from an overhead bin,
falling off a conveyor or being thrown from a catapult (assuming
you're a closet castle fan with a lot of patience).

On the issue of loading the hopper: I would suggest a light sensor and
two Lego lamps:

  The light sensor is placed parallel to, or one plate above the top
of the hopper and 1/2 a hopper-car-length from the drop zone.

   On the other side of the track and below the hopper is light #1
(I'll call this the "positioning light" and it could probably just be
powered by the rails since it only need to be seen when the train is
running). The positioning light is on continuously (when the train is
moving) and disappears to signal the start (or appears to signal the
end, depending on direction of travel) of a vehicle.  Your programming
has to take into account the direction of travel to determine if the
car is properly placed when it first blocks the positioning light
(i.e.. passes under the loading zone first) or when the positioning
light becomes visible again (passes by the light first). The program
must also take into account whether the engine will be pushing the
cars or pulling them although this would probably not be necessary
since the engine is almost guaranteed to be taller than the hopper
cars - which brings us to light #2....
   Light #2 (I'll call this the load light which could, possibly be
connected to the conveyor motor - see below) is positioned parallel
to, or one plate above the top of the hopper car and 1/2 a
hopper-car-length away from the drop zone in the direction opposite
that of the light sensor. This means that for the light sensor to see
it, the light from the load light must travel diagonally from corner
to corner across the hopper and through the drop zone. If the load
light is not visible, then it's an engine, boxcar, tanker (anything
other than a flatbed) or even an already full hopper. In this case
spot the next car. If the load light is visible, the car isn't full,
(or you have a flatbed - oops) so keep loading. It should be
intermittent because cargo will be falling in front of it. If you
don't see an intermittent reading, you probably either ran out of load
or you have a jam (either way - time for the hand of god). When the
sensor disappears entirely, you have a full load. On to the next car.
There are several advantages to this method. It handles trains of any
length. It handles all types of cars (except flatbeds). Heck, you
could even use mixed passenger and freight since the load light and
light sensor are not directly across from each other (passenger cars
usually have windows located directly across from each other). It
should be able to detect jams and/or out of cargo conditions.

Some thoughts on connections:

   Connecting the positioning light to the rail power supply is
probably a good idea. It's only going to give you meaningful
information when the train is running anyway and since the train will
be stopped when the car is being loaded, the positioning light won't
interfere with the load light's visibility which should make it
possible to detect a falling load as a varying light level.

   Connecting the load light to the conveyor motor would only be a
good idea if there was a fair bit of inertia in the conveyor. Granted,
it only takes a few 1/10's of a second to flash the light when a car
is spotted to check if it is an empty hopper car or something taller,
but if this jogs the conveyor each time, it will result in a few
pieces of cargo being dumped where it doesn't belong. There is a
solution though: run the motor backwards. Cargo will go down the
conveyor instead (no harm done) but the light will still light. This
reverse-the-motor idea might also work if you are using an overhead
bin loading scheme, depending on the design of the release mechanism.

A last comment: I would dump the mining operation idea completely -
too complicated. Instead, build a Toys-R-Us and have the conveyor
positioned at the warehouse door offloading Mega-Bloks to be taken to
a plastics factory and turned into something useful.

Matthias Jetleb
VA3-MWJ

P.S.: Given that Lego is relatively lightweight and the that the
friction between moving parts is fairly high you will have the
following problems with other methods:

    A scale made with Lego will invariably involve moving levers. The
friction will make accurate load measuring (of an already lightweight
cargo) very difficult. We all know how much an over-tight bushing can
affect a delicate mechanism's performance, add to that the added
complexity of coupling and uncoupling a car and making sure it is
centered over the scale (off-center loads make a difference) and the
fact that you would be limited to loading cars of the same
construction (i.e. identical weights vs. volume) and it looks
increasingly less practical.
    Your reference to humping a car (and you were right, it is called
a "hump") doesn't even work in real life let alone with Lego. In real
life, the mass of a car compared to it's friction is very high. Even
at 20Km/h initial speed a car can coast hundreds of meters. In Lego,
the car is quite light and the friction fairly high and quite variable
from car to car (even if they are of identical designs). Accurate
positioning would be extremely difficult. In real life, by the way,
variations in car designs/masses/friction make it difficult too. A
real life hump is followed by one or more mechanical brakes (metal
bars that squeeze the flanges of the wheels between themselves and the
rail). How long they squeeze depends on how much you need to slow the
car down. How much they squeeze depends on how much the car has slowed
down since it left the hump, from which a computer calculates the
car's individual rate of deceleration and adds to it as necessary. You
could do this in Lego, but I wouldn't want to be the one to try it.



Message has 1 Reply:
  Re: Train1 Reversing loop
 
Thanks Matthias, for your involved answer! Let's see: I've got the reversing loop working now, but there's still a question of what "Main" means in terms of "main line"... My reversing loop will be off my own section of the layout (call it the (...) (23 years ago, 30-Apr-01, to lugnet.org.ca.rtltoronto)

Message is in Reply To:
  Train1 Reversing loop
 
Hi folks, I thought I'd mention that in my chunk of the train1 layout I intend to provide a reversing loop (If S@H delivers my points fast enough) The basic idea here is that with the reversing loop and a tiny amount of training about how to throw (...) (23 years ago, 25-Apr-01, to lugnet.org.ca.rtltoronto)

6 Messages in This Thread:




Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact

This Message and its Replies on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR