G Scale Model Train Forum banner

1 - 4 of 4 Posts

Premium Member
19 Posts
Discussion Starter #1
I looking to automate my pike using Digitrax equipment. Was curious if any here has had any experience with the various software programs out there that work with the DCC equipment. I've used the Digitrax Loconet system with visual basic to automate a small HoN3o(?? LOL) christmas display a few years ago with success. But this time around I'm looking for something I can spend less time programming and more time setting up and running. I'll probably have better luck with the small scale forums, but thought I'd try here first, LOL.

Super Modulator
21,008 Posts
You need to talk to Bob Grosh, he has done some very cool things with transponding and the JMRI software.

Look for him here, lsc, or the Aristo forum.

Regards, Greg

Premium Member
254 Posts
Gee a command performance/DesktopModules/NTForums/themes/mls/emoticons/shocked.gif

First, I did something similar to what you did, but in "G"
Writing your own control system from scratch MIGHT actually be easier than using JMRI to do it.

B I G P R O B L E M :

Automation systems depend on detection.
You will never get detection to work outdoors.
(OK, you might, until it rains, or you have a humid day.
Aside from humidity, the high current, and typically much dirtier track cause problems. And you need lower resistor values than HO, and you need to de-sensitize the detectors. On the BDL 16 and 168 you will also need to heat sink the dropping diodes. You will find yourself endlessly troubleshooting empty tracks that are "stuck on" and tracks with cars that don't show up at all.

You will need about 100 pounds of copper to wire an outdoor railroad with detection. And you thought rail was expensive?
Forget detection.

T H E S O L U T I O N:
Transponding works outdoors, even in the rain.
There are a few tricks though. All the manuals are for HO, They assume that the maximum current draw in a zone is 3 amps, Yea, right!
First trick is simple. Between the white and blue leads (common and F0 Forward) install a .1 micro-farad capacitor in series with a 100 ohm resistor (1/8 watt will do) This is in addition to the headlight.
Before you wire anything on your railroad, set up a separate 10 foot ( or longer ) test track. Wire it up for three transponding zones and run every lighted car, sound car and loco you have on this test track.
Get a DG583S motor decoder, a TF4 function decoder, and SFX064 sound decoder. Set these up on some cheap flat cars with all the lights wired for testing purposes. These also serve as a benchmark to compare other decoder and sound board installations.
Forget everything you read or have read about automation. Those are track oriented systems. Transponding is car and loco oriented. Instead of configuring all your blocks, switches and signals to control actions, you will be programing locos and cars.
When this block is occupied, and that block is occupied, and this switch is thrown, and that signal is thrown, THEN kill the power to block X.
LOCO (Transponding) CONTROL:
When myLocation includes "Yard" Set F6 ON (change to switching speed)
When myLocation includes "Yard" or "Siding" Set F1 ON (ring the bell)
When myLocation does not include "Yard" or "Siding" then set F6 OFF and set F1 OFF
When myLocation includes "Yard" and "End" Stop at uncouple, change direction, pause and resume speed.
Notice the difference! Track oriented detection has no clue as to what is in the block. It could be a car with a resistor, a different loco than the one it expected, a toad, or a wet pine needle.
Train oriented feedback (Transponding) does not give a hoot about the track plan. To see what I mean by this, I'll give an example:
Lets say you have a passenger stations at two of your three passing sidings.
the passing sidings each have their own transponding zone:
Each zone has aliases, ( or labels) like this
ZONE 1 = Passing, Passenger station, Mill Creek
ZONE 2 = Passing, Passenger station, Ruby Springs, US-MAIL
ZONE 3 = Passing, Holdover, Yard
Train oriented software does not care h=where these three sidings are, what order they are in, or how they are connected. Instead, trains are given rules to follow, ( I call them "Behaviors")
Using the above example:
A local passenger train can be given three rules: (1) Always pause at Ruby Springs" (2) Pause at Mill Creek if the light is on in the Stationmaster's office. (3) Stop at "Holdover" until a light comes on at "Ruby Springs"
A Scheduled passenger train can be given two rules: (1) pause at "Passenger station" (2) Stop at "Holdover" until 04:30 PM (Include throwing turnouts so all other trains pass)
A Train with a RPO can (1) "Stop at "US-Mail" for 30 minutes. This will stop it at "Ruby Springs" or any other location where US-MAIL" is one of the items in the list of aliases. Every 30 minutes I does it again.
You can assign different behaviors (or rules) to each loco, so each loco can stop, throw turnouts, or do whatever you like based on the labels you set up for the zones.
Obviously, an advantage to this is that you can re-arrange you layout without changing any wiring. You won't have to edits page after page of block, signal and turnout lists. You can even move buildings,(like the post-office to another town) just by editing a short list of aliases.
One more advantage to train oriented software, You do not have to install transponding on your whole railroad. Just the places where you need automation. Look at how much automation we can do with just three zones. And we could run three trains or ten trains on those three zones. How many detection blocks would that take to handle ten trains?
There is no software for train oriented automation using NMRA feedback or Digitrax Transponding.
Sure, some packages (like RR and Co.), can translate transponding messages into block occupancy, (if something is transponding from there, then it must be occupied) You still have track oriented system. It can Identify a loco using transponding, so instead of tracking "a" train through dozens of blocks, it can track "LOCO 1234) through those blocks. The actual decisions about stopping the train are made by the track, not the loco.
And you will need LOTS of blocks.
And You will have to rely on their software to track train movements just like it does with blocks.
And you will need LOTS of transponderRecievers.
And a hundred pounds of copper wire.
JMRI can't automate your trains either. (at least not without writing your own software to go with it)
All the code to figurer out packets and handle the mundane stuff is already there.
They just don't USE transponding to do anything.
They do have a reporter table. You can look at a list of zones and see what cars and locos are in each zone.
They do have an example, or demo script that turns these transponding messages into "memories". You can use these "memories" to display different icons on the screen to show what loco is in a zone. But, You have to write a program using Java or Python to even make it do that. (And you have to create your own icons.)
JMRI is open source, so you can see all the code, and help on their forum is fantastic. (And it is free!)
Like you, I wrote my own software. A long time ago. For Windows 3.1.1. The old PC gave out, and the serial port device, my programing environment, and my development package are not worth trying to port to a new USB PR3 and Vista.
So, considering the choices, I decided four weeks ago to give JMRI another try.
GAWD I HATE PYTHON, JAVA and their ilk. But I am struggling through the process of writing code to automate the ALLY just a little.
Keep in mind, my goals:
(1) I do not want to have the trains run like a department store display. WE RUN THE TRAINS.
(2) I want "Animation" not "Automation". That is, I want lights in the trains to behave in a realistic manner, as though there were real passengers, conductors and crew members on the trains. I want sounds to enhance the animation effects. An example would be a light comes on in a lavatory on a passenger car, a flush sound follows, and then the light goes off. All automatically and only when appropriate.
(3)I want to mix automated (computer controlled) trains with human operators. IE: a milk run, or a through passenger service. Unlike a simple timer, or scheduled automation, these trains must be aware of human controlled trains. They are primarily designed to make the operation more interesting for the human operators. Automated switchers might set out cars to be picked up and delivered elsewhere.
(3)Animation is for effects, like turning on cattle sounds when the cattle car is delivered to the stockyard, and turning them off when that car is delivered to the packing plant.
(4) Animation replaces or supplements card order systems. Operators must move the stock car to the packing plant when it has cows in it.
Automation must assist the human operators. Examples include turning on the bell in yards, (without magnets) blowing the crossing signal, (without magnets) position couplers over the uncoupler magnets, Stopping a loco before it hits a bumper. throwing turnouts when approached from the wrong way, etc.
(5) The animation system shall not prevent the trains from being operated normally when the animation system is shut down or not desired.
(6) the animation system must use the absolute minimum of wires on the ALLY.
How much progress have I made in four weeks?
Well. right now, I am watching a pair of LGB 3 axle switchers shuttling cars back and forth on a small test layout. There are four sidings and three transponding equipped cars.
Each loco has several "Behaviors" loaded , "Bell in Yard", Stop, and reverse out of dead ends", "Three toots on start in reverse", "Throw turnout X on entering zone alias "Y", "Determine loco orientation" and the behavior i am debugging today, "Return Home" Which is kind of cool. Place the loco anywhere on the track, in either orientation, and the computer runs the loco to it's home position. I handles throwing the switches and moves the loco back and forth till it gets to a zone that contains it's DCC loco name in the list of aliases. Fun to watch. Would be a lot harder if I had a turntable or Wye.
The down side of using JMRI. I suppose if you write code in C++ or JAVA or PYTHON, this would be easier. My experience is in Assembly and Basic/like languages. Syntax errors are guaranteed. I struggle with every line of code.
Some of the things I tried to do didn't work because of problems in the JMRI throttle handling code. I documented them, posted them and got new code emailed to me in a day.
If you want to see some more of what I am attempting, well, I started making drawings for my own reference as I worked out how the code would work. I posted these drawings. I had fun drawing them, and as I did them it helped keep my programming tasks firmly in mind. Especially when adding the comments. I'll add to and refine these drawings as I progress with the code. The drawings are here:

Premium Member
19 Posts
Discussion Starter #4
Hi Bob, thanks for the response!
I've only had time to quickly scan thru your info...but am bookmarking it to come back to later, LOL. Lot's of good stuff there. The transponding is the reason I chose Digitrax in the first place and planned to incorporate it into the automation as much as it allows me to.
It looks like I will be programming "from scratch" using the JMRI stuff as what I want to do is very similar to what you're doing. I'm starting off with two simple loops (with some cross-over trackage) and want the PC to automate the control of three trains. Eventually...when i expand it even more to include a yard and as I add sidings...I'll want to manually pilot short freights or excursions...in and amongst the "automated" trains...great minds must think alike, LOL!:D
I've already planned on many, many blocks given what I want to do. But I had planned on some of them being "dumb"...ie, just detection...might have to rethink that part based on what you've said and what I've found online.
Thanks again, and I look forward to comparing notes down the line.
1 - 4 of 4 Posts