Block detection and computer-run trains

Vince Guarna , In a message on Sat, 01 Oct 2005 10:46:15 -0500, wrote :

VG> I'm building a DCC-based railroad. In addition to the usual "invite a VG> bunch of friends over and have an operating session" control, I'd also VG> like to have the ability to have a computer do some things. One movement VG> in particular that I thought I would want to do is to automatically have VG> an off-layout freight come from hidden staging into the arrival tracks of VG> my major classification yard. After thinking about this for a few VG> minutes, it occurred to me that I would probably need three blocks for VG> each arrival track that would receive a train. These would consist of one VG> major block in the middle for general occupancy detection for that track VG> and two small blocks, one at each end, to determine when to stop the VG> train. For example, the arrival track would look like: VG> VG> ===== ========================================== ===== VG> (Blk1) (Blk2) (Blk3) VG> VG> VG> When a train entered the track, say, from the left, I would know to stop VG> the train when either Blk3 was entered (point engine hit it) or Blk1 was VG> vacated (caboose cleared it). Of course, I'm assuming somewhere else I VG> figured out the track was long enough.... VG> VG> So, now my question: Is this necessary? This is a lot of blocks. Seems VG> like you have similar problems in staging and also at junctions where VG> meets will occur. You'd sort of like the waiting train to wait at the VG> signal, not just somewhere in the block. That implies another short block VG> near the signal to detect and stop the train. VG> VG> The only other possibility I can think of is to do it based on timing. VG> With back-EMF decoders and some additional software, you can probably get VG> there from here, but I'm not sure how reliable/repeatable that solution VG> would be. VG> VG> Anybody else have other approaches?

Yes. You use a current-based block detection. Then you *add* an optically-based position detection. You would install a photo-resistor just before the signal (allowing for a stopping distance). The computer uses the current-based block detection as the basis for signal aspects and to 'decide' if a train should stop at a signal. The optically-based position detection is used to decide if/when to send a 'train stop' DCC message. If this is in a 'dark' place (unlighted staging areas, tunnels, etc.) you can 'light up' the photo-resistor's location with an IR LED.

VG> VG> thanx, VG> VG> V VG>

\/ Robert Heller ||InterNet: snipped-for-privacy@cs.umass.edu

|| snipped-for-privacy@deepsoft.com /\FidoNet: 1:321/153

Photocells.

Place a small infra-red LED on one side of the track and a detector on the other side. Do this at each end of each track near the clearance point. When the beam is broken the current shuts off and the train stops. In the case of DCC, you don't need to shut off the current, just send a STOP signal to that loco. Actually, there are two ways to do this. One way is to locate the transmitter and receiver. side-by-side very close to the detected object's path and detect the reflected beam, the other is to place them facing each other such that the detected object must pass between, and detect the broken beam. This requires very little in the way of cash outlay compared to the multi-block method. Since you already have a computer to use, you only have to write the software such that the detectors "know" which way the train is supposed to be going; e.g., north or south, and will enable the proper detector. When you want to run the train, a software over-ride removes the detector from the circuit.

It's not a "walk in the park", but it is mostly an intellectual exercise that requires comparatively little expenditure of funds and comparatively little accumulation of hardware and complex wiring. A single block detector or two tells you that the train is in the yard and reduces speed accordingly.

If you only ever run a single loco on a train, and never run MUed locos with multiple decoders there is an even simpler way of doing it.

Froggy,

What Robert is saying is that you use block detection to determine/track the general location of a train, and optical detection to determine the precise location of that train. You use the strengths of each type of detection.

The programming is fairly easy if the train only goes in one direction. If it can enter and leave from both ends, it gets more complicated since the computer has to know which spot detector to ignore and which to obey.

Mike Tennent "IronPenguin"

Gentlemen:

Cave man approach: figure out the route the automatic train takes. Have the computer set that route at the right time and set red signals (and maybe short de-energized blocks) to protect it. Don't use a decoder in the auto-train; wire the motor through a couple of diodes so it will operate at normal speed on the AC track supply. Have a section of track specially controlled so the computer can stop the engine in the yard. When it reaches that section, whether it takes a minute or

3 days, control goes back to normal. No need to detect train position or anything except that once...what do you think?

Cordially yours, Gerard P.

It will work, but requires that the equipment used to pull the train be dedicated to that function only. If you run several trains automatically when you are home alone, but have operating sessions with other operators at other times, then you have the expense of having two sets of motive power for the same job. Not that it isn't a good and workable idea, but I wouldn't want to do it that way. Froggy,

Froggy@thepond..com picked at his banjo, and sang:

Dear Sir:

Hmm, expenses are bad. Could the engine perhaps be equipped with a switch to cut out the decoder and cut in the diodes, so it would be useful for either purpose?

Cordially yours, Gerard P.

Use two optical detectors an inch or so apart - then it's reasonably simple (software wise) to determine direction.

So long as you provide route interlocking so that no train conflicts can occur, that approach should work ok.

A decoder fitted loco will run on normal analogue DC, so I don't see a problem.

home alone,

Mr. Procter:

Well, the problem is that my suggestion was kind of a hack...you wouldn't actually control the train, just turn it loose to run on the AC track supply until it hit the stop block. If the decoder works fine on DC, though, all you would need is a switch to short out the diodes when you wanted to run on DCC.

Cordially yours: Gerard P.

dedicated to

are home alone,

Ok, I shouldn't jump in without reading the whole thread! Sure, if you stick a diode in series with the motor you're going to get an analogue loco that runs at half speed in _one_ direction only. Isolate about two loco lengths from the stop block to minimise the bump! Alternatively, use the DCC "zero" address to drive the unmodified analogue loco. (which should be something like an Athearn loco with a BIG motor and metal chassis to disipate the heat generated.

analogue loco that

loco. (which should

I am going to take a gamble here and say that I ~think~ Digitrax is the only major DCC manufacturer that uses zero-stretching to run an analog loco. If not, I bet I find out pretty soon. Since the whole group here in these parts uses Digitrax, I have been lax in researching the other brands. I will do that directly via the I-net.

At any rate, what I was really going to say is that zero-stretching is a poor way to run an analog loco on DCC. It consumes system resources and can interfere with other DCC equipped locos that may be operating. No one in my operating group has analog engines and the modular group that I sometimes interact with has zero-stretching disabled so that locos not equipped with decoders cannot be run. This was done over objections and much wailing and gnashing of teeth by those who did not want to equip their locos with decoders, but the problems were to bothersome to be allowed to continue. No analog locos. Zero-stretching works great in the marketing area, doesn't work worth a flip in real life. Froggy,

Well, the zero-stretching was invented by Lenz, so they have it too.

We run digital and analog on modular layouts, but do it by maintaining separate lines. The major problem with running analog locos on digital lines using zero stretching is that the higher the throttle setting for the analog loco, the more response delay is introduced to the digital commands. This is most obvious when you've got the analog address turned up all the way, and turn lights on and off in a large MUd train. Of course, the same delay applies to direction changes as well, which makes switching a bit of a challenge...

So, you CAN run both analog and digital at shows, but you have to keep the lines electrically isolated.

analogue loco that

loco. (which should

disipate the heat

I have Ma/Arnold and MRC DCC systems in my collection, they both allow zero stretching for analogue operation.

Any loco or accessory operating is going to consume system resources! ;-)

I only burned one motor out before I gave up. (It was an Nscale motor)

Regards, Greg.P.