I spent a good part of the weekend on a busman's holiday - cleaning up the computer program I use for deciding which boxcars get switched during an operating session. It's cleaned up enough so that I'm willing to let others try it out.
Go check out a very early version of SwitchList if you've got a Mac, and could use a computerized switchlist generator for your layout.
Now, if you don't know why you'd need that, let's talk about model railroad operations.
If model railroad operation is a game, then figuring out what has to be done during the game is a key detail. For the operations game, the question is "where do the trains run" and "what freight cars do the trains need to switch?" There have been all sorts of ideas proposed over the life of the hobby. Some use car cards that can be picked randomly to figure out where a car should move. John Allen, a famous modeler from the 1960's, drilled holes in his freight car roofs and stuck colored tacks in to indicate the destination of each car. (Rumor has it a real railroad tried this once, but stopped after accidentally drilling holes in the roofs of new cars held in a car carrier.) Others have placed scraps of paper with placement instructions on the top of freight cars. Others go with the simplest approach and roll dice at each town to figure out the number of cars to pick up and drop off in each town.
When I first started operating the Vasona Branch, I tried the car cards approach. I photocopied a couple hundred of the cardboard slips to represent the cars and the cargo they carried, and spent a couple nights on the repetitive task of writing down potential actions. "Take a boxcar from Plant 51 back to staging." "Take another boxcar from Plant 51 back to staging." "Take a stockcar up to the passing siding at Alma." "Take another boxcar from Plant 51 to staging, but this time pretend you're sending it to Cleveland." It was slow, painful work.
At the operating session, I dealt out a card for each freight car, and paper-clipped the cargo card to the card representing the freight car, gave a stack to my operators, and let them start. The cards worked decently - the print was a bit small, but they weren't too hard to handle, and they were easy to find if someone dropped his cards on the garage floor. I needed a place to put all those cards, so I glued together some small plastic pockets out of styrene sheet to hold the cards for the freight cars at each industry.
It worked ok, but after a few sessions, I wasn't as happy. The cargo cards just specified a kind of car - "this car is for a tank car, that for a refrigerator car.' But the process of picking an appropriate car for appropriate lading in the real world is much more complex. There are elaborate rules about what to do to return a boxcar after it's carried a load to another railroad. Generally, the rule is that the car can be reused for a load heading back towards the owning railroad, but if no loads are going in the right direction, the freight car needs to be sent back to its owner as fast as possible. (Read a bit about demurrage here or here too if you'd like a future in transportation law.) One bit of fallout of that is that cars on my layout from a non-Southern Pacific railroad -- such as those East Coast boxcars -- should only appear on industry sidings that might either send or receive lading from the east coast.
And so, one day I look at the concrete warehouse spur in front of Plant 51, and I see a Florida East Coast ventilated boxcar sitting there, and I know that there's absolutely no reason why that car should be there. No one would have *any* reason to ship cement from Florida to California in the 1930's. Nothing in that warehouse would be heading the other way from California to Florida. It's just wrong for that car to be there, and I'm annoyed. Obviously it doesn't take much to annoy me.
Now, there's ways of tuning car cards to avoid that sort of problem. Maybe mark certain cards according to which railroad's cars can hold them. Similarly, when I got annoyed that the dirtiest boxcars were ending up hauling canned fruit for Del Monte, I could have started marking which cargo cards required "clean" boxcars, and which cargos could go in the dirtiest, most weathered boxcars. But that requires writing a lot of car cards, and I'd had my fill of that.
There are some commercial Windows-only programs for generating switchlists or waybills, but they were all for Windows only. I found some free switchlist software, but found them cryptic and hard to use. Yes, I'm proud I can tweak some strange configuration file for a twenty-year-old command line program to add a couple new freight cars to the system, but I don't really want to do that regularly.
So the solution was to write my own program for the Mac, and it's been sitting on my computer for a few years now. It's usually worked ok, but I've never spent enough time to actually polish it or get it in a state where others might be able to use it. One of my biggest problems was that that car assignment algorithm was messy, and I didn't have any easy ways to test that any change I made wasn't going to break the software completely. Fortunately, I tried using the automatic unit testing code for the Mac (specifically the OCUnit Objective-C unit testing framework), and spent the weekend adding hundreds of tests to make sure that cars moved reasonably correctly. Between that and some cleanup of how stuff is stored on the computer disk, SwitchList was finally at a state to let others check it out.
So try it out, see if it's useful for you, and let me know how it works!
No comments:
Post a Comment