|
|
|
|
The Los Feliz and North Western uses computer-generated switch lists for operation. Freight car routing up to now has been dominated by the systems developed in the 1950s, which fall into three broad categories: the switch list, the card system, and tab-on-car. It seems to be as much a characteristic of the hobby as of the prototype rail industry that we want to stick to the tried-and-true, not to say the obsolescent.
Computers aren't for everyone. But if you're used to using a computer as part of your work, or for other household or hobby interests, there can be dividends in using it to help with layout operation (and if you're browsing this web site, you may have the interest and ability, too). When I had a layout far enough along to start looking seriously at operation, I began to realize what a chore it would be to make up car cards and waybills, along with adding the boxes that so many operators have along the front of their layouts. And then I began to read about guys who'd started using carpenters' aprons so their operators could carry the car cards with them in the pockets. This seemed like a lot of unnecessary work, but just making up one traditional switchlist by hand looked like a tedious task as well.
Some people have objected to computer-based routing on the basis that you can't "just run a train" if you have to leave all the cars on your layout where the computer last said they should be. There are several ways to avoid this problem. Not all your equipment needs to be in the computer, and you can certainly have designated rolling stock available to "just run a train" any time. "Real time" systems, discussed below, will also allow you to call a particular train at any time and run it, and you can then report any moved equipment to the computer.
But other good reasons for using computer-based operation are the ability to run "what-if" simulations easily, and the ability to tune or balance the cars and car types you have on your layout to what's needed by industries. I've made many changes to my layout, adding spurs and industries to maximize traffic opportunities, as well as changing my buying habits to focus on rolling stock best suited to my layout. You may find, for example, that too many of your boxcars are sitting idle, while space for hopper cars is still available at mines and coal dealers on your layout. These conditions are much easier to see using a computerized system, which may contain diagnostics that point out these problems.
Finally, Bruce Chubb pointed out in How to Operate Your Model Railroad (Kalmbach, out of print) the problem of circumventing manual operating schemes. If operators don't want to move one car to spot another, or prefer not to make a setout on a switchback spur, they can conveniently "lose" or just ignore the car cards that say to do this. The result is that over time, operation can become too little of a challenge. A computerized switchllist is much harder to circumvent!
There's a surprising variety of commercial products available, as well as some freeware. Some people have written programs for their own use in languages like BASIC as well. However, it's worth pointing out that writing a program to handle all the tasks and possible options in routing freight cars on a model layout is a major technical challenge and a project for well-seasoned programmers (if you aren't well seasoned when you start, you will be when you're done!). For most people the price of a commercial product is well worth it.
Each system reflects its developer's experience and preferences in operation. Just as modelers differ in how they operate, the developers of car routing software have different visions of what their products should be doing for their customers. There are two major sets of choices in how a product operates. The first choice is whether to require the users to define the commodities their freight cars carry or not. The second choice is whether to see the task of generating switchlists as something done for individual trains, or something done once for all the trains an operator wants to run in a session.
Some operators like to be able to point to a particular car on the layout and say "that boxcar, UP 102987, is carrying tissue from Georgia Pacific's paper mill in Bellingham, WA, to the Safeway distribution warehouse here on my layout." Others might not need that level of detail and might instead note that since the boxcar in question is an Accurail model, no one will ever be able to get the doors open, and what it's actually carrying doesn't make much difference as long as the switcher knows to spot it at the warehouse.
For those who prefer this high level of typographical detail, ProTrak and ShipIt! are two systems that rely on defined commodities to route cars. To get these systems to move a car, you have to tell them what each industry on your layout ships and receives, and the cars that are used to carry each commodity. The New River Coal Mine ships coal in empty open hopper cars, while the Edison Power Plant receives coal in loaded hopper cars. ProTrak goes into even more detail on the specific commodities and tariffs.
The positive side of this approach is that the operator can feel an added sense of realism with each shipment. It's not just an Accurail boxcar going to staging; it's carrying grain from the Co-op at Jones City to the NYC terminal elevator in Weehawken, NJ. The downside is the major extra effort needed to identify commodities, set up each industry with its inbound and outbound shipments, and define the car types to carry them. This adds to the complexity of the system, and complexity has its own costs in the added chance of error and misunderstanding.
I don't think it's a coincidence that both ShipIt! and ProTrak have very active Yahoo! groups where users can assist each other in the intricacies of getting their layouts set up and shipments balanced. And some modelers, faced with the added complexity of shipping commodities as well as routing cars, throw up their hands and say all their industries ship "stuff"!
Others may decide it's enough to have a fleet of hoppers lettered for the Virginian, and assume that nine operators in ten will be able to figure out that they're carrying coal. If there's a problem, one of the nine will explain it to the tenth guy. RailOp and Minirail allow you to say simply that the local Coors distributor receives loaded RBL insulated cars. You may or may not know that such cars commonly carry beer, but as long as the switch crew knows to spot WPLX 80530 there, that's all you care about. You can't drink beer from HO size kegs anyhow.
In effect, these systems concentrate on the visual effect of having the right type of car go to the right industry without the need to explain the commodity. A loaded chlorine tank car often goes to paper mills or water treatment plants. You can tell a system like RailOp or Minirail this without the need for the extra step of saying the industry receives chlorine. The downside is that you don't have a piece of paper you can point to that says the shipment is chlorine. Some would say you just don't need it.
A layout full of cars is a routing system's raw material. One philosophy in designing a system is to look at that layout, break down all the cars, wherever they may be, by type and whether they're loaded or empty, and decide right then where each car should wind up at the end of the operating session. This means the system will look at the loaded boxcar at the Jones City Co-op and decide the best place for it by the end of the session is the staging track representing Weehawken, NJ. To get it there, it will set up a series of instructions in several switchlists, telling the Jones City local to pick it up at the Co-op and drop it at the Smithtown yard. Another switchlist generated at the same time will tell through freight SW-2 to pick the car up at Smithtown yard once it gets there and take it to the Weehawken staging track.
This is the session-based approach. It assumes the layout owner knows exactly which trains he's going to run in a session before the session starts. He hands each of his operating crews the switchlists for each train at the start of the session, and each crew gets to work on its particular task. If the owner is operating alone, he starts with the first switchlist and works his way through each one in order until, hours or evenings later, he finishes with the last. The advantage to this approach is that the computer can be anywhere in the house, or even somewhere else (a club wouldn't need a computer on site), and not in the layout room, since all that's needed is the stack of printed switchlists. You don't need to tend the computer during the session and can concentrate on the layout. ShipIt! and Minirail are session-based systems.
The problem with this approach is that in the real world, abilities and attention spans differ among operating crews. You may have no choice but to put new guys on the Jones City local, and they're just hopeless at figuring out how to get that carload of grain switched into the train. They're still at it by the time everyone else is ready to go home, and the owner is so busy at other things he hasn't been able to help them out. The result is the cars for Weehawken don't make the cutoff for SW-2, but the session-based switchlist still has the instructions for SW-2 to take them. First SW-2's crew wastes a lot of time looking for the cars from the local in Smithtown yard when it hasn't even gotten there yet; then SW-2's crew starts pestering the host about what to do now that they don't have them.
Once the host has explained everything several times over and everyone else has gone home, he has to go back to the computer to correct the files to show that the carload of grain (and every other car on the Jones City local) never made it to Smithtown, or he'll have to run the Jones City local later in the week the way it should have been done to get the cars to the right places. That way the next session he runs will start with all the cars where they should be.
There are various ways around this dilemma. One is to have an operator, if one is available, go from one crew to the next updating switchlists with a marker, crossing out cars that have been bad-ordered or haven't made cutoffs. Another is to keep working to be sure all operators are familiar with the layout and the system, while also tuning call times and the sequence of trains to match the abilities of the operators. If things go smoothly, there may seldom be problems with the session-based approach in any case. Some layout owners may enjoy finishing sessions in subsequent evenings as well.
Real time systems take a different approach to building switchlists. Rather than looking at the whole layout and a whole evening's work, a real time system looks only at the cars, locations, and destinations that apply to a particular train. If SW-2 runs from Smithtown yard to Weehawken, the system will make up a switchlist for that train consisting only of cars for Weehawken in Smithtown yard at the actual time SW-2 is going to run. The system knows this because, as each train on the layout reaches a certain point, somebody goes to the computer and tells the computer about it. If the Jones City local hasn't made cutoff and isn't in Smithtown, the computer won't list the Weehawken cars from Jones City as being in the yard yet. As a result, it won't give SW-2 a switchlist that includes those cars. ProTrak and RailOp are real time systems.
Another up side to real time systems is that the owner may not need to finish a session later in the week to get cars into the places the system says they should be. Since the system updates car locations as each train terminates (or even as it is OSed), there's much less need to play catchup. You can run trains out of their normal order, too. It's also much easier to run just one or two trains in off evenings.
The downside to real time systems is the need to have the computer handy to the layout room, since you will need to update the system each time a train terminates or OSes. You will also need to print out switchlists as the operating session progresses, reflecting the ongoing changes in status of trains and cars. This in turn means someone needs to take on the task of computer operator during layout operation, most likely the host. This may distract the host from other tasks during the session. Finally, while I haven't yet implemented parallel sessions with a session-based system vs a real time system on my layout, my instinct is that a session-based system won't move as many total cars for a given number of trains, simply because the available pool of cars will always be smaller.
Each layout is different, and each layout builder has different operational expectations. If you've been with a product, and you like it, it's clearly a good one for you. But beware of other folks trying to tell you that real operators use Brand Y. Some products have a near cult-like following, though I sometimes think it's similar to the cult-like followings that some English sports cars used to have - if you didn't have to fuss with it all the time, it wasn't a real sports car. If this isn't your philosophy, look for and select a product that's easy to use.
Visit the Yahoo! groups associated with the products, where they exist, and feel free to ask questions. (Here is the ShipIt! group, here is the ProTrak group, and here is the RailOp group). Read the comments, suggestions, praise, and criticisms of the other members. Examples of comments that should raise "red flags" would be this, this, and this. Also this and this. Any message entitled "It should not be this difficult" should be self-explanatory. See what the product developer's attitude (and those who act on behalf of the developer in the group) is toward criticisms and suggestions. Get a feel for how quickly (if at all) problems are resolved. See if you can attend operating sessions locally where such products are used.
But also keep in mind that most of the available software is reasonably priced - in most cases, the prices are equivalent to a single plastic diesel unit. At worst, if a product doesn't meet your expectations and you're past the warranty period, or if you've used a product and simply want to try another, the investment isn't prohibitive. I've tried to use as many of the products as I could, and find operations software an interesting aspect of the hobby in itself.
Once you've decided to try operating with a software package, it's worth keeping several things in mind. First, start small. Enter just a small number of cars and industries, with a single way freight to serve them. You should expect to spend some time getting used to how the system assigns cars. A particular problem many new users have with any system is cars that won't move, or industries that won't get served. Working these problems out often involves tweaking load-empty status or making sure the right car types are defined for the industries that need them. By all means make use of whatever resources the developer makes available for getting help and advice, either via e-mail or Yahoo! Groups.
Once you've got the basic product working with a small amount of data, begin to add more cars, towns, trains, and industries, and keep noting and working out any problems that arise with new data. To get the best distribution of traffic, you should expect to run a number of dummy "sessions" (or a corresponding number of daily lineups in a non-session based product) so that car locations and industry orders are smoothed out. Then you can start using the switchlists to run actual trains on your layout.
It's also a good idea to get the basic product features running smoothly before you try to add the more sophisticated pieces like staging, fiddle yards, and so forth.
If the product you're using doesn't have a Yahoo! Group associated with it, try to locate other users with whom you can share information on using the product. In my experience, the product developers (and often volunteer support people) are also generous with their time and effort in answering questions and solving problems via e-mail. Naturally, you will score points with them if you show that you've read the applicable help files and documentation before you contact them. Make use of these resources! However, keep in mind that the developers are often providing the product as a labor of love and aren't getting rich, while they may be helped by knowledgeable customers who aren't being paid at all and simply believe in the product.
Computer-based operation has had a major effect - a good one - on my approach to the hobby. It's added an extra dimension to my enjoyment of my layout, and I've formed a number of friendships as I've learned more about the subject.
September 24, 2003
 Free Web Hosting Since 1996. Join & Become Part of the TrainWeb's Railroad Community. |