Trains.com

Subscriber & Member Login

Login, or register today to interact in our online community, comment on articles, receive our newsletter, manage your account online and more!

Weighing options--gratitude and appreciation

8708 views
48 replies
1 rating 2 rating 3 rating 4 rating 5 rating
  • Member since
    December 2004
  • From: Rimrock, Arizona
  • 11,241 posts
Posted by SpaceMouse on Wednesday, April 2, 2008 7:14 AM

Cool,

Okay, all the more reason to make my self rich. Awsome toys.

Does the BDL168 have transponding?

Chip

Building the Rock Ridge Railroad with the slowest construction crew west of the Pecos.

  • Member since
    November 2002
  • From: Colorado
  • 4,074 posts
Posted by fwright on Wednesday, April 2, 2008 7:30 AM

Chip

You change the requirements as soon as I get the recommendation out of my mouth.  Talk about requirements creep - in you case it's requirements leap!  "one small step for a man, one giant leap for a spacemouse"  Big Smile [:D]

I see way too much picking a technology, and letting the technology drive the requirements.  Let's revisit the requirements, and let that pick the appropriate technology.

For the automation in your dream, I derive the following:

  • train is turned over to staging system for arrival
  • system safely parks it with knowledge of the departure schedule
  • based on knowledge of event sequence and time, the system selects and activates appropriate train to depart
  • train departs staging under staging system control to a hand-off point

Some big unknowns here that need definition:

  • where are off the hand-off points?  Will the train be stopped at hand-off, or does the staging system take control of a moving train?  The same question in reverse for departing trains - does the engineer take control of a moving train?  Or is there an arrival and departure staging area where the hand-off takes place?
  • will the system be purely sequence driven, or will it be a combination of clock and sequence?  In other words, will train 98's departure be held until the correct time even if train 97 has already arrived?

My assumptions:

  •  train sequence and schedule (timetable) will be input before an operating session, but may/will change from one operating session to the next.  Logic that changes needs to be put in software, not hardware.
  • locomotive assignments to a specified trains will be determined during the operating session.  This is a huge item, because current detection systems are not set up to detect a particular train.  IR and reed contacts detect passage of a train (doesn't care which train) past a point.  Digitrax transponding detects a specified decoder in a given block of track.  If you want variable locomotive assignments to trains, there must be a way for the system to know which decoder is assigned to a given train.  That could be done by giving decoders train number addresses instead of locomotive addresses on the fly (probably easiest), or have a screen to input locomotive assignments for trains (engineers have to remember to make the entry).

Last important part of the requirements/system design (and usually more than 50% of cost and effort) is error trapping and handling.

  • Is it OK for the system to simply shut down when an error is detected?  What happens when a locomotive is on a dirty piece of track, and can't be located or started?  Is a flashing red light and system shut down good enough?  Or does the system need to identify the error from a table of possible errors?
  • How difficult is system reset?  How do you reconfigure the system to match reality after an error or shutdown?
  • Is train integrity detection needed?  Do the system need to know the caboose is in the clear, or will time and train length be sufficient?  This is why the Free-mo signaling guys use both transponding and IR detection.  Also why magnetic reed systems put magnets in cabooses, and block detection puts resistors across caboose wheels.

Reality is that the effort and cost to achieve your dream will likely be too high.  But identifying the dream requirements allows you to decide which requirements can be sacrificed to bring down the cost.  And the remaining requirements will point to the correct system for you.

Last thought - human beings are amazing computers, easily reprogrammed, adaptable, and very adept at error handling.  They have built-in sensors capable enough for your situation.  OTOH, humans are miserable failures (compared to computers) at repetitive tasks they consider not challenging enough.  They invariably make a boring task interesting by sub-consciously allowing and encouraging errors to creep in.

my thoughts, your choices

Fred W 

 

  • Member since
    December 2004
  • From: Rimrock, Arizona
  • 11,241 posts
Posted by SpaceMouse on Wednesday, April 2, 2008 8:03 AM

Fred, 

I'm sorry if I present a moving target.

The title of the post is weighing options though. And as stated, cost and value are factors.

I figure though that if I push the envelope (of my knowledge, not what people here know) then I am more likely to come to some sort of compromise.

At one end of the the spectrum, there is me walking into the laundry room, throwing a couple hand throws, and manipulating the trains.

On the other end of the spectrum is me hiring a team of programmers to create exactly the functionality I want. 

I'm not an engineer, but I am pretty good at systems. I have headed teams of programmers to create say a just-in-time distribution system. And I shouldn't have been needed to reminded that a systems needs to be idiot proofed--in this case the idiot clicking the keys.

That said, eventually, I'll pick a system somewhere between the poles. Part human, part automation. In the end it will really about how many dollars do I want to throw at my laziness. My days of technomania are over (I think.) 

 

Chip

Building the Rock Ridge Railroad with the slowest construction crew west of the Pecos.

  • Member since
    November 2007
  • 1,089 posts
Posted by BlueHillsCPR on Wednesday, April 2, 2008 8:36 AM
TrainController looks pretty good!
  • Member since
    December 2004
  • From: Rimrock, Arizona
  • 11,241 posts
Posted by SpaceMouse on Wednesday, April 2, 2008 9:11 AM
 fwright wrote:

Chip

You change the requirements as soon as I get the recommendation out of my mouth.  Talk about requirements creep - in you case it's requirements leap!  "one small step for a man, one giant leap for a spacemouse"  Big Smile [:D]

I see way too much picking a technology, and letting the technology drive the requirements.  Let's revisit the requirements, and let that pick the appropriate technology.

That is not a lesson I need to learn.

For the automation in your dream, I derive the following:

  • train is turned over to staging system for arrival
  • system safely parks it with knowledge of the departure schedule
  • based on knowledge of event sequence and time, the system selects and activates appropriate train to depart
  • train departs staging under staging system control to a hand-off point

Okay, keep in mind this is a dream. Ideally, the train is detected as it enters the "staging zone." Through some sort of procedure, a train departs and the incoming loco fills it's spot. It may need to stop it on the main and allow the other engine to depart, or the other engine can start it's departure, with the computer adjusting speeds of the two locos as needed.  

Some big unknowns here that need definition:

  • where are off the hand-off points?  Will the train be stopped at hand-off, or does the staging system take control of a moving train?  The same question in reverse for departing trains - does the engineer take control of a moving train?  Or is there an arrival and departure staging area where the hand-off takes place?

Ideally, the computer would take control of a moving train coming into staging. And ideally, the engineer would take control of the train as it leaves staging, however, there should be a drop dead point where the train stops should the engineer be still in the lounge watching the NCCA Tournament Bud Light commercials.

  • will the system be purely sequence driven, or will it be a combination of clock and sequence?  In other words, will train 98's departure be held until the correct time even if train 97 has already arrived?

Ideally, either/or. However, the time sequence might be more stress than I want to handle on my own. On the other hand, I do enjoy video games that get increasingly difficult.  

My assumptions:

  •  train sequence and schedule (timetable) will be input before an operating session, but may/will change from one operating session to the next.  Logic that changes needs to be put in software, not hardware.

I agree that the logical change would input into software, but operations should be able to be looped as well as being finite start/stop. Most of the cool operating layouts I've worked pick-up where the last session ended and there is very little tending (staging) of trains. One layout I work has just celebrated its 30th birthday, and the owner rarely does anything. His operating systems (non-computer) is set-up to be self-correcting and the worst that happens is that an car card (not the waybill) follows the wrong car and his has to swap the cards. He never touches a piece of rolling stock. Any car improperly placed will default to a yard for reassignment.

  • locomotive assignments to a specified trains will be determined during the operating session.  This is a huge item, because current detection systems are not set up to detect a particular train.  IR and reed contacts detect passage of a train (doesn't care which train) past a point.  Digitrax transponding detects a specified decoder in a given block of track.  If you want variable locomotive assignments to trains, there must be a way for the system to know which decoder is assigned to a given train.  That could be done by giving decoders train number addresses instead of locomotive addresses on the fly (probably easiest), or have a screen to input locomotive assignments for trains (engineers have to remember to make the entry).

Gotcha. If the yardmaster makes up a train and designates it as Extra 126 and assigns it Engines 899 and 1024, with engine 1024 as the dominate decoder, that must be input at the time of departure from the yard. Now we are getting into dispatching software, eh?

Last important part of the requirements/system design (and usually more than 50% of cost and effort) is error trapping and handling.

  • Is it OK for the system to simply shut down when an error is detected?  What happens when a locomotive is on a dirty piece of track, and can't be located or started?  Is a flashing red light and system shut down good enough?  Or does the system need to identify the error from a table of possible errors?

First off you would fire the MOW crew responsible for that piece of track. I ended up quiting my club because nothing worked and they resisted any effort to organize maintenance. Open houses were cluster-frakes--so crowded you couldn't move and locos derailing or stalling and getting hit by the train behind, and fight your way through the crowd to fix them.

The track (block) shutdown and flashing light is fine. In reality though this phase of the layout is so small either I see the problem or it is in staging.

How difficult is system reset?  How do you reconfigure the system to match reality after an error or shutdown?

This is a biggy, no? It would be nice to be able to drag and drop a sequence indicator to tell it where to begin the sequence. Ideally then, it would check the sequence against supposed train locations and self-adjust.

  • Is train integrity detection needed?  Do the system need to know the caboose is in the clear, or will time and train length be sufficient?  This is why the Free-mo signaling guys use both transponding and IR detection.  Also why magnetic reed systems put magnets in cabooses, and block detection puts resistors across caboose wheels.

The current plan shows staging sidings longer than the capacity of the locomotives. That is not to say that some day, the Rock Ridge Railroad might not quadruple their moguls and pull 40 cars. I suppose your would need caboose detection.

Reality is that the effort and cost to achieve your dream will likely be too high.  But identifying the dream requirements allows you to decide which requirements can be sacrificed to bring down the cost.  And the remaining requirements will point to the correct system for you.

Last thought - human beings are amazing computers, easily reprogrammed, adaptable, and very adept at error handling.  They have built-in sensors capable enough for your situation.  OTOH, humans are miserable failures (compared to computers) at repetitive tasks they consider not challenging enough.  They invariably make a boring task interesting by sub-consciously allowing and encouraging errors to creep in.

my thoughts, your choices

Fred W 

 

What this exercise--answering your points--has made me realize is that in order to achieve full automation, my maintenance would have to be impeccable. For example if a caboose or any other comes uncoupled the whole system breaks down. Such levels of maintain ace would exceed the effort to do the whole process manually and even with out the cost factor, the labor trade-off would not be efficient.

Chip

Building the Rock Ridge Railroad with the slowest construction crew west of the Pecos.

  • Member since
    November 2002
  • From: Colorado
  • 4,074 posts
Posted by fwright on Wednesday, April 2, 2008 9:31 AM
 SpaceMouse wrote:

Fred, 

I'm sorry if I present a moving target.

The title of the post is weighing options though. And as stated, cost and value are factors.

I figure though that if I push the envelope (of my knowledge, not what people here know) then I am more likely to come to some sort of compromise.

At one end of the the spectrum, there is me walking into the laundry room, throwing a couple hand throws, and manipulating the trains.

On the other end of the spectrum is me hiring a team of programmers to create exactly the functionality I want. 

I'm not an engineer, but I am pretty good at systems. I have headed teams of programmers to create say a just-in-time distribution system. And I shouldn't have been needed to reminded that a systems needs to be idiot proofed--in this case the idiot clicking the keys.

That said, eventually, I'll pick a system somewhere between the poles. Part human, part automation. In the end it will really about how many dollars do I want to throw at my laziness. My days of technomania are over (I think.) 

I'm sorry that I seemed condescending.  I didn't know about your experience in systems design.  And I was pulling your leg about changing requirements.  Requirements always change (even my own). 

In my systems design background, weighing alternatives effectively is more "pick and pray" than analysis if requirements aren't understood or prioritized.  Which is why I went through what I saw as your requirements, even though most are obvious to you. 

Agreed, there is rarely a 100% solution available.  Even if one has to resources to go down the custom path, the requirements change enough before the solution is implemented that it will no longer be a 100% solution in the end.  But just as in layout design, knowing and documenting the desired end state is really a quite valuable exercise.

If there are established, reasonably mature solutions available, then often picking becomes which drawbacks of the various alternatives can I live with?  Very similar to picking the best DCC system for myself - which system has the drawbacks that least matter to me?  I go through a similar evaluation process when buying a new car.  Listing drawbacks of each model in comparison to my givens and druthers allows me to rule out some alternatives up front.  "Excessive" cost is an obvious drawback that is weighted heavily.

I'm still not sure I have a good idea of your prioritization of what you want to automate.

For detection alternatives I know of (reed contacts, IR, cameras, block current such as Twin-T, transponding), only the cameras and transponding do more than signal the presence of a generic train.  The camera depends on a human eye to perform train identification, and transponding gives the block location of a specific decoder address.

End of train protection requires specific detection capability not easily available with transponding or block current detection.

For a hybird machine/human system, a look at the requirements and the drawbacks says that cameras are the easy, cheap solution, even if only in the interim while you work on something more automatic.  Either a series of fixed cams or a smaller number of pan/tilt cameras provide detection, train identification, and require minimum programming or operational skills.  It's also an inexpensive, adaptable, yet thorough solution which uses humans as the brains for identification and error handling (did the caboose clear the turnout?).  The human also provides the interface to the train control system (operates the throttle to start/stop the train).  No hand-off is required.  Only drawback I see is providing sufficient light for the cameras and humans to do their part successfully.

my ideas for what they are worth

Fred W 

  • Member since
    December 2004
  • From: Rimrock, Arizona
  • 11,241 posts
Posted by SpaceMouse on Wednesday, April 2, 2008 10:00 AM
 gandydancer19 wrote:

Option one:

Lets talk a little about the Digitrax SE8C. (I'm currently designing the signaling for our club layout.)  One SE8C will control 32 signal heads.  They can be used to control individual LED's on a panel if you want, instead of the signals.  Also, the same SE8C can detect 8 blocks by adding two BD4's to it.  The same SE8C will also control 8 Tortoise machines with no modification.  JMRI panel pro is free, but has a learning curve.  Download the manual and check it out.

Option two:

There is a detection ckt available from an eBay seller that costs about $7 each.  It is self contained and has an LED output, and you can add a remote LED to it.  (It requires a power supply for power.)  Detection is done by reflecting an IR signal from someting (usually a train) and this is received by the IR sensor.  This is a pre-built, one piece unit that you would just have to mount somewhere close to the track or under it.  It doesn't reflect from a black surface all that well.  (I am using one myself.)  So you would be talking about eight of these units minimum, one for each train.  (This would be the simplest one.)

Option three:

CTI makes a Train Brain system that provides automatic train control.  Depending on what you purchase, you could automate your entire layout, or just a few blocks.  (I am using that system also.)  The starter set costs about $100 for reading 4 sensors and switching 4 relays.  A computer is used, and their program can interface with most major DCC systems.  I think Digitrax is one of them.  You would need at least one other standard TB board to get 8 sensor inputs.  Then you would need to setup the sensors and wire them to the boards.  I use CSD cells on the track, which requires a light above them.  You will have to write some code, but it is fairly simple.

Option four:

Cameras.  Train cameras are not that expensive these days, and no layout or track connections are needed.  (They don't need to be mounted to a train.)  Plus, you would be able to actually "see" what is happening.  You should be able to get some sort of video switch that will allow you to use one TV and switch between cameras.

OK, I think I vote for cameras for your situation.

GD,

Thanks for your input. These are all good ideas. Each of the options have their up and downside and what is panning out is that there is no clear system that works for all contigencies.

 

Chip

Building the Rock Ridge Railroad with the slowest construction crew west of the Pecos.

  • Member since
    December 2004
  • From: Rimrock, Arizona
  • 11,241 posts
Posted by SpaceMouse on Wednesday, April 2, 2008 10:45 AM

 fwright wrote:
For a hybird machine/human system, a look at the requirements and the drawbacks says that cameras are the easy, cheap solution, even if only in the interim while you work on something more automatic.  Either a series of fixed cams or a smaller number of pan/tilt cameras provide detection, train identification, and require minimum programming or operational skills.  It's also an inexpensive, adaptable, yet thorough solution which uses humans as the brains for identification and error handling (did the caboose clear the turnout?).  The human also provides the interface to the train control system (operates the throttle to start/stop the train).  No hand-off is required.  Only drawback I see is providing sufficient light for the cameras and humans to do their part successfully.

I've pretty much come to the conclusions you have.

Here's what I see will work.

Using the block detector with the transponder to identify which engine is where.
Using Panel Pro as a readout to show the locations.
Using traditional electrical switches to control turnouts.

What is still iffy.

Detecting if a train has cleared a switch. I can't think of a good electronic system short of making the head and tail ends of the siding their own block and that triples the cost of block detection. The obvious compromise is a camera system.

What is ucky.

The layout is set in rustic times. Having a bank of monitors visible on the layout upsets my sense of artistic harmony.  

 

 

Chip

Building the Rock Ridge Railroad with the slowest construction crew west of the Pecos.

  • Member since
    January 2007
  • From: Eastern Shore Virginia
  • 3,290 posts
Posted by gandydancer19 on Wednesday, April 2, 2008 10:49 AM

No Problem.

One thing that may simplify what you are trying to do is have one staging track per train.  I know it means more tracks and turnouts for eight trains, which you may not have room for, but automation becomes simpler.  I set up a four track staging yard for four individual trains, running with CTI.  The turnout positions determined what was going where, and what was comming from where.  This simplified determining what trains were running.

Elmer.

The above is my opinion, from an active and experienced Model Railroader in N scale and HO since 1961.

(Modeling Freelance, Eastern US, HO scale, in 1962, with NCE DCC for locomotive control and a stand alone LocoNet for block detection and signals.) http://waynes-trains.com/ at home, and N scale at the Club.

  • Member since
    December 2004
  • From: Rimrock, Arizona
  • 11,241 posts
Posted by SpaceMouse on Wednesday, April 2, 2008 10:53 AM
 gandydancer19 wrote:

No Problem.

One thing that may simplify what you are trying to do is have one staging track per train.  I know it means more tracks and turnouts for eight trains, which you may not have room for, but automation becomes simpler.  I set up a four track staging yard for four individual trains, running with CTI.  The turnout positions determined what was going where, and what was comming from where.  This simplified determining what trains were running.

I'm sorry if I was unclear. One train, one siding was always a part of the plan.

Chip

Building the Rock Ridge Railroad with the slowest construction crew west of the Pecos.

  • Member since
    February 2008
  • 419 posts
Posted by UpNorth on Wednesday, April 2, 2008 1:27 PM

Another curve. Under TrainControler transponding is not required. He manages the loco database we'll call it.

You have us bouncing back and forth between different section to see what has been said and not said so we don't repeat ourself. Double posting are we...

Marc

  • Member since
    December 2004
  • From: Rimrock, Arizona
  • 11,241 posts
Posted by SpaceMouse on Wednesday, April 2, 2008 2:06 PM
 UpNorth wrote:

Another curve. Under TrainControler transponding is not required. He manages the loco database we'll call it.

You have us bouncing back and forth between different section to see what has been said and not said so we don't repeat ourself. Double posting are we...

Marc

Sorry about that. I originally posted on the General Forum and by the next day or so it was off the second page with no replies so I posted here. Then Dog found it and dragged it back. Since then it has progressed on two tracks, the physical practical on the General and the electronic/systems here. Given the nature of your comments your posts belong here.

But Panel Pro is free and Train Controller is $350, right?

Edit: General has gone technical, so much for sepration of info. Geez.

Chip

Building the Rock Ridge Railroad with the slowest construction crew west of the Pecos.

  • Member since
    February 2008
  • 419 posts
Posted by UpNorth on Wednesday, April 2, 2008 11:28 PM

So it's something the dog dragged in !...  Usualy the cat does that.

Yes sir JMRI and PanelPro (PP) are a freeby.. 

PP  will be ok for giving you block occupation indication and to give you control of the turnouts. Not all that complicated to setup, take my word for it.  Like I said I setup mine using Dick Bronson's clinic.

Train control itself (with PP) is another matter thow. You must write up the scripts (a programming language) to control it all.  That part is not simple unless you have acces to a 10 year old computer wiz or you posses infinite wisdom.   This is in responce to your dream of partial automation.  I had a dream too... I have a dream.   

Transponding is cool. but when you really look at, little you can do with it for the amount of time, expense and effort.  Even the high end software (TrainControler) does not require it at all. 

 

  • Member since
    December 2004
  • From: Rimrock, Arizona
  • 11,241 posts
Posted by SpaceMouse on Wednesday, April 2, 2008 11:50 PM

(partially stolen from General)  

I'm starting to visualize more clearly what you are talking about. I guess my misdirection is resulting from reading the block detection is accomplished either through IR of photo cells. But from what you are saying, it is done through resistance.

So let me clarify.

I need the BDL168 block detector and it will handle my 8 sidings easily. (Although at this point I don't know the difference between a block and a zone. )

I need transponding decoders in the locos. Q: are these in addition to the sound/locomotion decoders?

I need resistance in the caboose or last car (but not necessarily a transponder?)

What are the RX-4+ for?

Panel Pro will work for a readout. All I'm looking for is the identity of the loco so I can call it up on the DT400. I'm not looking for auto control. That's what a toggle switch and a turtle are for.  

I'll bet the scripts are Java. I know a little Basic, C++, and a dead dbase programing langurage. 

 

Chip

Building the Rock Ridge Railroad with the slowest construction crew west of the Pecos.

  • Member since
    December 2004
  • From: Rimrock, Arizona
  • 11,241 posts
Posted by SpaceMouse on Thursday, April 3, 2008 2:40 PM
Bump for clarifying the above post.

Chip

Building the Rock Ridge Railroad with the slowest construction crew west of the Pecos.

  • Member since
    January 2007
  • From: Eastern Shore Virginia
  • 3,290 posts
Posted by gandydancer19 on Thursday, April 3, 2008 4:01 PM

I may be able to answer some of your questions and expand some on detection.

The difference between Blocks for detection and Power Districts (zones) is as follows (basically). A power district is a separation of the layout track power by either using separate boosters or circuit breakers to manage the power delivery to different major sections of the layout. A Block, for detection purposes is about the length of a train or a little more. Multiple blocks can be in one power district.

Detection can be in more than one form. Most think DCC detection is only by current detection when a loco or lighted car is in the block. CSD cells or Photo and IR types are also means of detection, except they are better suited as point detectors. That is, when a train reaches a certain point, they trigger the input. Most DCC manufacturers set up their systems for current detection only. Electronic resources used that report any type of detection is the same. That is, you need one input for any type. The BDL-168 is a current detection board (resistance) and can't be used for anything else. An SE8C has other inputs that can be switched by an operator, thus it is possible that IR and other types of point detectors can be used. However, they may require additional electronic circuitry to implement.

To detect more than just a locomotive, other cars must be set up with resistor wheel sets or lights. (One wheel set per car will do). It's not absolutely necessary that you do that unless you want to see when the last car of the train leaves a block.

Digitrax transponding is done by additional equipment that is added to it's standard detection boards. It also requires special digitrax decoders.

The BDL-168 can detect 16 blocks. You may want to download and read the manual, then download and read the manual for transponding. Both are available on the Digitrax web site.

Elmer.

The above is my opinion, from an active and experienced Model Railroader in N scale and HO since 1961.

(Modeling Freelance, Eastern US, HO scale, in 1962, with NCE DCC for locomotive control and a stand alone LocoNet for block detection and signals.) http://waynes-trains.com/ at home, and N scale at the Club.

  • Member since
    January 2007
  • From: Eastern Shore Virginia
  • 3,290 posts
Posted by gandydancer19 on Thursday, April 3, 2008 5:38 PM
 SpaceMouse wrote:

You know, I started this thread with a dream.

In this dream I imagined that I could schedule 8 trains to run automatically. That when one train left the layout, the next train in sequence would start up and travel into my ops session. The train arriving in staging would occupy the track that the departing train just left. The at the correct moment, the next would depart. And I would just switch the incoming trains as needed.

But it dawned on me that although there are circuits to detect a train or loco and tell if it is occupying, a particular block, there is nothing that can detect which loco is in the block.  

And it's not like I need to know. But the computer needs to know so it can open the right turnouts and send the train on it's way at the right scheduled time.  

Without that, I might as well use reed switches and toggle switches and LEDs and keep track of the locos with a set of car cards hung on the right hook.

Having done what you want to do on my old DC layout, let me see if I can explain it. Since you know some code, it should be easy.

A- Each staging / storage track would have one sensor near the exit turnout. This is all you need here because your trains must be short enough to fit in the assigned track. When this sensor is activated, you stop the train. Also, this sensor will remain active, so you know a train is in staging track one and it should be 001. Also, maybe after a short delay, the turnouts now switch to staging track two, and start train 002. You know a train is there because the sensor says so. You know it is 002 because it was sent there and track two is reserved for train 002. If the track is empty, the program has to go to the next track and set it up for that departing train. The program has to know what train is assigned to what track and what turnouts are associated with it. Possibly by an array or table. Each track is assigned to only one train, and no other train should be able to go there.

B- The turnouts should be set up so when you activate them for track one, you actually activate a route that sets the incoming and exit turnouts at the same time for route one, if this is physically possible. That way when train 001 comes off the layout and back to staging, the route to staging track one is already set up for it.

C- There should be a place that the train can stop when a sensor is activated when coming onto the layout. (At the first town?) The train would stop and computer control of that train would be terminated and manual control would begin.  You may have to disable that sensor sometimes if switching moves would activate it.

D- There should be a similar place for trains to stop for the control change-over when getting ready to enter saging, and by using a counter, or odd / even count detection, you could use the same track and sensor.

You could also (or instead of D) have a button or two (or six, one for each train or track) that would tell the computer which track you want the train to go into, but then you would need some way to tell the computer which train is going there. So the simplest way would be to assign a button to each train. Then the computer would set up the incoming route for that selected train. And then the computer would also take control of the train and take it into staging and stop it. The buttons would be needed to set up the tracks and routes if you wanted more trains on the layout than staging tracks. (You said 8 trains, but I only see 6 staging tracks in your diagram.) Any reversing would be handled by the auto-reversers we have now.

The sensors can be current sensors or basic DCC block detection. Just make them about 6 to 12 inches long, because all you need are point sensors, but the loco has to stop inside the detection zone of the sensor. If it does, you won't foul the turnouts at either end of the train, so momentum will have to be accounted for.

 So, 6 staging track sensors, 1 outbound, 1 inbound, and 8 for buttons, means that you would need 16 block detectors minimum, and then stationary decoders for the turnouts.  You can wire the BDL-168 current sensors for buttons by using 10K resistors in series with them to simulate a train in a block.

I found that I had to use quite a few variables and a counter or two to keep track of what was happening. Again, I did this using the CTI system. Their code is very similar to Basic.

Edit:  Another thing, you don't really need the buttons if you want full automation, but you will only be able to have one train on the layout at a time, unless you use something to track the trains.  CTI does this by using Beacons, which is a program function.  And in case I didn't say it, CTI -CAN- interface with DCC systems for locomotive control, but is not able to read any DCC stationary devices from other manufacturers.  Also, most of the programs and systems that folks have mentioned so far have been designed to interface with a layout primarily for signaling detection (CTC and ABS), not staging functions, although some may be able to do it.  If you decided to go with CTI, I feel that you should use their boards and control bus.  That way you will have more control over what you want to do.  And, CTI is not phiscally tied into the track by direct electrical connections.

I hope this helps.

Elmer.

The above is my opinion, from an active and experienced Model Railroader in N scale and HO since 1961.

(Modeling Freelance, Eastern US, HO scale, in 1962, with NCE DCC for locomotive control and a stand alone LocoNet for block detection and signals.) http://waynes-trains.com/ at home, and N scale at the Club.

  • Member since
    February 2008
  • 419 posts
Posted by UpNorth on Thursday, April 3, 2008 11:37 PM
 SpaceMouse wrote:

(partially stolen from General)  

I'm starting to visualize more clearly what you are talking about. I guess my misdirection is resulting from reading the block detection is accomplished either through IR of photo cells. But from what you are saying, it is done through resistance.

So let me clarify.

I need the BDL168 block detector and it will handle my 8 sidings easily. (Although at this point I don't know the difference between a block and a zone. )

Block detection with the BDL168 is good for 16 blocks or sections. The BDL168 can also handel  8 tranponding zones. These are in addition to the 16 detection blocks.  That s what the 168 stands for, 16 blocks, 8 transponding zones.

I need transponding decoders in the locos. Q: are these in addition to the sound/locomotion decoders?

You need a transponding decoder in every piece of equipement you want to follow.  What you really require is one in the engine or first car after the engine and one transponding decoder in the last car (caboose). Most Digitrax decoders come with transponding. No one else at this time purchased  the license to implement transponding.  Digitrax sells the TL1, TF2, TF4 function only decoders with transponding. 

http://www.digitrax.com/ftp/bdl16rx4pm42appnote.pdf

http://www.digitrax.com/ftp/bdl168.pdf

I need resistance in the caboose or last car (but not necessarily a transponder?)

Exactly. Block is occupied but your guess by what.

What are the RX-4+ for?

They are what captures  the transponding signal emitted by the transponding decoder and in turn supply it to the BDL168.  The BDL168 puts the info on Loconet. JMRI picks it up and puts it in your panel (PanelPro)

Panel Pro will work for a readout. All I'm looking for is the identity of the loco so I can call it up on the DT400. I'm not looking for auto control. That's what a toggle switch and a turtle are for.

Yes. the transponder info is put up on the panel you created with PanelPro.  I'm still waiting for an RX-4 so I can wire it up  to test it. I've got a few  TL1's in waiting.  

I'll bet the scripts are Java. I know a little Basic, C++, and a dead dbase programing langurage. 

Java based Jython.

  • Member since
    December 2004
  • From: Rimrock, Arizona
  • 11,241 posts
Posted by SpaceMouse on Sunday, April 6, 2008 12:34 PM

I want to sincerely thank you guys. I've learned a lot.

That said, what I have been thoroughly convinced of is that a high tech solution on a 1909 layout really gets my aesthetical goat. I don't mind hidden technology, but monitors and computers in a visible control board...otherwise all the switching would have been manual with no control panel. 

More than anything, it points out that I am trying to solve a design problem without actually solving the design problem. It's back to the drawing board with me.   

Chip

Building the Rock Ridge Railroad with the slowest construction crew west of the Pecos.

Subscriber & Member Login

Login, or register today to interact in our online community, comment on articles, receive our newsletter, manage your account online and more!

Users Online

There are no community member online

Search the Community

ADVERTISEMENT
ADVERTISEMENT
ADVERTISEMENT
Model Railroader Newsletter See all
Sign up for our FREE e-newsletter and get model railroad news in your inbox!