Video Gallery  


Who's Online  

We have 146 guests and no members online


Sunday, June 8, 2008

Sensor Processing Logic

free web page counters

I've been working with my train automation for some time. There have been a large number of successes in the process and I've learned a lot about not only what I want to do, but how to accomplish things within the software I have. As you may know, I'm using the CTI-Electronics equipment for about a year and a half or perhaps even a bit longer. Their TrainBrain software uses the Train Control Language, TCL to control trains. The language is much like programing in BASIC and while appearing to be deceptively simple, things can become very complex in a hurry.

One of the main reasons is that with train automation, things happen asynchronously meaning independently and in real, or very near real time. For example you must close or open a turnout before the train gets there and keep in in position while said train in passing through.

Layout designed for Automation
My layout is primarily designed for computer automation. To be ready for automated computer operations I incorporated these features:

  • The layout is made for continuous running.
  • Most of the sidings on the layout are passing sidings. A train can pull in and back out without backing up.
  • The trains only go in one direction.
  • The mainline has choke points meaning I cannot run two trains parallel and just let them go.
  • When trains meet, in certain parts of the layout, they are going different directions.
  • Trains can pass each other on the sidings.

My layout has 29 blocks, 5 are photocell and 24 are current detection blocks. Plans call for at least a dozen more. All of the current detection blocks have passive torrid style detectors and are mounted behind the facia in a wiring channel near the physical location of the block. I use #14 gauge wire for my DCC bus and #20 wire for feeders. Feeders are typically no more than 2.5 feet long. The layout is set up for two power districts with my DCC drawer located directly under the #11 signal indicator on the CTC panel. I use two DCC Specialties RRamp meters to independently monitor the current and voltage in each of the districts. Using a third RRamp meter with a lightbulb cliped to it, I have measured my current drops which in all cases are less than .75 volts with a 1/2 amp load.

I purchase most of my materials for my railroad locally at either Caboose Hobbies begin_of_the_skype_highlighting end_of_the_skype_highlighting (Dave 502 is their Mr. DCC) or Mizel's Trains. When I need to purchase something over the internet, my favorite place for DCC is Bruce at Litchfield Station.  Tony's Trains has a wonderful selection of DCC specialties.  The Hare and Wrabbit are two favorites.

Sensor Logic
Programming sensor logic seems pretty straight forward. IN CTI's TCL, the syntax goes something like this:
When SensorA = True do
LocoA.Speed = 15
Wait 15
LocoA.F2 = pulse 2

or when Sensor A is true, set locomotive A to speed 15, wait 15 seconds and press f2 (Whistle/Horn) for 2 seconds. Certainly this is simple enough but there are lots of other things we need to do, like manage the locomotive assigned to which block using CTI's Beacon logic, and things get even more complicated when managing the CTC panel indications.

The sneaky snake in all this is that sensor logic typically becomes so involved that it can takes a lot of time for it to execute. The worst sitatuation with sensors is when you have a second locomotive enter a block whle the previous locomotive is still processing. In these situations the second and any subsequent sensor actions is lost which of course screws up the program logic. These sitations become common when you start adding 2, 3 or more locomotives.

To help overcome these type issues I have incorpoated the following logical scheme to deal with sensors.

I have a couple of rules for sensor programming.

  • Only one set of code for each sensor which does all logic for that sensor.
  • Use the same logical flow and style for all sensors. (Simplifies troubleshooting later)
  • Reduce and eliminate hard coding of locomotives as much as possible.
  • When hard coding of a locomotive address is required, use an alias with only one place where the Alias must be changes when the locomotive changes.
  • Always make sure there are two empty blocks between trains.
  • Use a sequencing scheme for sensor logic. Use a variable to clock through the steps of the sensor logic.
  • All CTC panel addressing is done by a reference variable that contains the address of the panel object; this is because many CTC panel objects can be used multiple times in the logic. This makes the program MUCH easier to maintain when things change.

The logical flow for sensors is:

  1. CTC panel logic - update the coloring of signals and routes plus adding locomotive symbols as desired.
  2. Beacon management - movement of the locomotive address through the route as required. Sensitivity to direction and route is required.
  3. Clock the train - move and position the locomotive into the block as required, especially necessary when you are stopping in this block.
  4. Hold the train - On sidings, an Icon of a lock allows one to hold a train in a passing siding indefinitely until released by the CTC panel operator. My three color passing sidings have this capability.
  5. Block exit logic - keep the train stopped in the current block until you have a clear route ahead. I test for a minimum of two empty blocks.
  6. Set Loco & TurnOut Controls - after the locomotive has been cleared for release, set locomotive speed, momentum, whistle/bell and set turnouts for correct path.
  7. Update CTC & Cleanup - as the train leaves the CTC panel, set signals, colors and variables as necessary.

I use the following variables for each block. Yes, this means each block, all 29 of them, have these variables. You quickly fall in line with using indexing. ie. BlockNOKOCC[3] = the Occupancy variable for Block 3 of NOK (Norman Oklahoma)

  1. Occ - Occupancy - Is this block occupied? Set and reset by the relative sensor for the block, this variable is also used as the block sequencer. As the logic moves from one setion to the next, this variable is changed.
  2. Loc - Location used for two purposes. 1 - Mark the spot where the code colors a block, 2 - Location where the Train indicator Sprite will reside.
  3. ID - Place where the Locomotive ID is written on the CTC panel.
  4. Hold - Tells the logic the locomotive is to be held in the block until the variable is false.

Each of these section sis a separate When statement. This means that all when statements in my code have very small and controlled amounts of code to be executed. This has greatly reduced the problems I had with sensor timeouts. I also post the sequence number directly on the CTC panel so that I can see which logical step a block is in when the troubleshooting the layout. I keep all blocks to the same sequence so that I have a clear knowledge of what is happening. For example When a block is setting at 15, I know that block is on hold and the train should sit there indefinitely until released.

More to come, I hope this is helpful.




Copyright © 2019 Joe Daddy's Weblog. All Rights Reserved.
Joomla! is Free Software released under the GNU General Public License.