This is a package for interfacing the so-called digital control for model railways to Unix-like systems. It should work on anything that's POSIX compliant (supporting termios) and that can run Tk 4.2+. It's GNU GPLed.
At this stage, we have these features:
Most of everything on there is kind of obvious. You change the speed with the big slider on the left. The big white disc with the numbers on the rim is supposed to be a meter measuring your speed. If you click on it, it will change the speed accordingly. The button with the double-arrow on it changes the direction. The blue rectangle with the little circles represent the lights. In the example above, we have the locomotive at address 7 (the slider along the bottom sets the address), not moving, with the lights off, in `reverse.'
Yes, there are some of you already complaining that the lights don't look like that of some North American diseasel, the needle on the meter is ridiculous, it's missing this or that, or whatever. Well, you can change it with almost no effort, and there is a straightforward basic cab module that can teach you how:
Here is another `cab':
This is the loco at address 6, lights on, going at speed step 3 forward. Right now, this is only limited to 14-step mode, but that's easy to fix, and will change sometime.
You can have as many `cabs' as you like. When you start up, you get a console window:
And then you can click on one of the `New cabs' to your heart's content. When two or more cabs are set to the same loco address, there is no confusion; all are updated when one is changed.
The text widget contains various messages that may be of interest. `Status' indictates the status of the DCC system. Clicking `Go' attempts to bring the DCC system back on-line if it's somehow offline. `Emergency Stop' stops all locomotives, but doesn't turn the track power off. `Power Off' turns the track power off.
Clicking on `Layout' brings up an overview of your layout. It looks sort of like this:
The blue shows the flow of the current settings, and the trains (in theory) follow that. If you click on one of the turnouts, it changes its state, and the red and blue parts swap colors and postion. In this picture, the one in the lower right is set to `straight' and the one near the top right is set to branch to the right. That little green piece of track is an uncoupler. If you click on that, the uncoupler activates for as long as you keep the mouse button down.
mtd has two parts, a common interface that talks to user programs, and a `driver' that talks to the computer interface of the digital system. For the driver, there is an API-like thing (where did this stupid acronym come from, anyway?) to which the commands are sent through. The user side has a simple protocol which is fast and easy to parse, and the commands to the driver are just as easy to concoct. The API and protocol are not set in stone (yet).
Right now, the only supported system is the Lenz Digital Plus NMRA DCC system, with the LI100 computer interface. Obviously, this is the system I have. Writing support for almost anything else should be simple. Support is only available for loco commands, and momentary and sustained accessory control. Again, this is all I have in real life.
tktrain keeps track of the locos with associative arrays, with the key being the address. A new cab or layout is a toplevel. Considerable effort has been put into the cabs to make them work well in multiples. One big feature that has to be added is multiple unit control. There will be no fuddling around with the command station for this; tktrain's cabs will keep track of all of locos in the `consist' together, and change their speeds all at once. Since different locos have different speeds at different speed steps, this task almost inevitably involves knowing the scale speeds of the trains. Other more involved things (like preprogrammed moves) will work along these lines and will be pretty simple to implement. They will be modular; you can load your `border loco switch' module and then use it, for example.
The cabs function well, but could look a little better and have some more features. The current scheme to change the address is kind of stupid, for one thing.
The layout and accessory control is still kind of feature-barren. However, it looks nice and does a great job with turnouts and uncouplers. I want to make a CAD-like module to graphically design layouts, but for now, it's all done by hand.
mtd is meant to be fast, and that's why it's small and kind of austere. I would like to keep it pretty much this way. You can add as much bloat to tktrain as you like, as long as I don't have to use it. There is still a lot to do, and I haven't even formalized an embryo of an to-do list.
About support for different kinds of train and computer hardware: I can only actively write code for that stuff which I actually have.
There is more information in the README and PROTOCOL files, found inside the package.
More importantly, I'd very much like to add support for Plan 9 and Inferno, using a filesystem instead of this silly socket stuff.
This page is listed by W&H in the `Signal System' section.
$Id: index.php,v 1.1 2000/09/08 00:18:57 bri Exp $