Prototype waybill system for Trainz

Dap

Prototype Operations Guru
Has anyone come up with a workable Waybill system for Trainz that simulates the prototype? You know, where every car has a destination and is routed accordingly? I find the LARS system too Lionel like. I have operated on several scale layouts that use way bill systems that really add a new level of realism to the operations. Any ideas how this can be done in Trainz?

Dap
 
Hi there

So what are you talking about exactly .....

Not using the built in loading for eiter LARS or the built in so cars would be empty like model railroads just have loads assigned to them?

Would help if all cars that there could me multiple of be renumable.

I still have my model railway one re-wrote from a orginal a long time ago it allows a car to be picked up from its home yard or last location unloaded (Your choice if cars have to be returned home after unloading) then taken to supllier loaded take to delivery point and unloaded (Loading and unloading times can be controlled.

The only thing is there is no direct interface, at the start you tell the program where the cars are and it will track them after. for each session you have to print out the waybill lists for each train and / or location and then gointo trainz and follow them.

Sorry this is the best I can do

It is compiled in Visual Basic 1, the only conditions I was given is i can't give away the source code.

Was going to update it but never got around to it, so it uses dynamic arrays in memory witch are saved once run instead of database files, was going to make it use ISAM files, party done but never completed.

Tom
 
This is something I have begun to consider, and I am working on some ways that it can be done in TRAINZ, with the goal of making a formal proposal to Auran as to how it this can be incorporation in the next major release. Just as an operator / engineer / driver can choose between "DCC" and cab-control mode, I would hope that waybills could be set to be either "Model RR" or "propotype" oriented. Just as cab control takes more thought and work on the part of the user, so too, prototype waybilling will take more work to set up. I would welcome the opportunity to toss discussions about this with others who are interested in the same goals as Dap and I.
 
mjolnir,

Are you familar with the Operations Special Interest Group (Opsig) of the NMRA? Model Railroad Operations SIG Lots of good stuff there.

I have operated with car cards that have sequential destinations and with 4-part way bills. I prefer the 4 part waybill, but I would hope that for Trainz, we can come up with something much better.

Any ideas on how this would be implimented?

Look at the Opsig website. There are several database software packages they discuss that might be adaptable. I have thought of using printed 4-part way bills and just keeping them in a box by the computer, but having the function build into Trainz makes much more sense.

I have no expertise on computer programming, but I do know how to design systems. Several things I'd like to incorporate:

-click on any piece of rolling stock and have its Way Bill pop-up
- option that automatically blue flags a car that has been spotted at its destination industry for a pre-specified amount of time
- industry call for empty car issued as a Trainz Message
-ability to assign waybills to freight cars as they are added to a consist in Surveyor

What can you add to this list?

Dap
 
Dap:

I've never been a member of NMRA; I knew they had special interest groups, and I suspect I would have imagined that there was one related to operations, but prior to reading your post I had no specific knowledge of it.

Just as with tangible models, in order for there to be prototype operations, there are some pre-requisites that need to be put in place for any route where someone is going to use a waybilling system that resembles the protoype.

1) Routes upon which it is to be implemented must have at least one modeled interchange with the outside world, and it must be decided where in the outside world the connection is made. Note that in this case, by "outside world" I mean only someplace not modeled on the route; it may or may not be a real or virtual point on the existing rail network. Just as most real railroads have multiple points at which they interchange traffic, a large route may have multiple connections, and even if there is only one physical connection, this may represent multiple interchange points.

2) More consideration is going to need to be given to the industries on the route. For each industry, one will need to plan where its suppliers are located, how much of the raw material is purchased from the supplier in any given time frame, by what route the raw materials it requires are shipped from the supplier to the industry, and the typical transit time from the origin. Similarly, one will need to determine where the industry's customers are, how much they purchase, and by what route the product is shipped, and the transit time to the destination.

3) One will need to prepare a detailed industry list, listing each industry, the number of cars per day of inbound material from each supplier, the number of cars per day of outbound product to each customer

4) One needs to plan and prepare a detailed roster of freight equipment available for loading on the route, most equipment to be loaded should have unique car numbers.

5) On needs to devise a system for traffic generation and a car management system (these are two separate, but related functions, which may or may not be accomplished by a single system).

As with many other aspects of TRS, the traffic generation and car management can be modeled with more or less detail.

I am presently working on an outline of a scheme, about which I will post a more detailed description later.

ns
 
Re: Additional Options

mjolnir,

Sound like you have read eveything on the Opsig website. By the way, you don't have to be an NMRA member to join this Opsig. If you haven't checked out the website, you should. There are some awsome resources such as a list of industries and and their traffic requirements.

There are several software packages described on Opsig that do most of what you have described, organizing industries, identifing suppliers, quantities of product, time required to load or unload car, etc. No need to recreate these if they work.

I am modeling the Ft Dodge, Des Moines & Southern which did a lot of interchange work. Other protoype modeling could include an operating division of a major railroad which would have trains arriving at on end of the division and exiting the other end with none or some of the cars being set out for industries or interchange. Each car will still need a waybill to identify its destination.

And you are right that every car needs a unique car number. But that is fairly easy to do, having cloned and renumbered a bunch of cars and I have only been using Trainz for about 6 weeks.

Fortunately, Portals in TRS allow you to model "the outside world". Unfortunately, there are no good controls for Portals. What is missing is a time trigger to bring trains onto the territory in a orderly fashion.

Looking forward to reading your outline.

Dap
 
Hi again

Thats a good description of what my progam is actually a computer replacement of the manual card system used by model railroaders for years. there has been a few different versions done.

My was orginaaly developed by 2 other members and myself of the CMIR(Computer in Model railway group) of the NRMA its now merged into another SIG.

Tom
 
Sound like you have read eveything on the Opsig website. By the way, you don't have to be an NMRA member to join this Opsig. If you haven't checked out the website, you should.

Actually, I haven't read anything on the Opsig website, <VBG>.

There are some awsome resources such as a list of industries and and their traffic requirements.

I am modeling the Ft Dodge, Des Moines & Southern

I know FDDM, they interchanged at several points with my preferred carrier (and onetime employer), the Rock Island lines.

Each car will still need a waybill to identify its destination.

No, it would not necessarily need a waybill; only a train or switch list, telling where in the model world each car is supposed to go.

ns
 
First, since Auran already uses "Waybill" for "model railroad" operating mode, I propose we adopt the name "switchlist" for prototype operating mode.

Lets consider a very simple route. This route has a single industry, a contract packaging plant, which receives products in bulk (dry in private owner hoppers, or liquid in tank cars), and ships the repackaged product in 70 ton boxcars. For the purposes of this discussion, the railroad serving the industry has one interchange, and owns twenty 50 foot, 70 ton boxcars. We'll assume that the plant has the theoretical capacity to process 45,000 gallons of liquid product, or 12,000 cubic feet of dry product per shift. We'll further assume that the weight of 45,000 gallons, or 12,000 cubic feet are both about 360,000 pounds (180 tons). Thus, theoretically, the plant can handle about 2 23,000 gallon modern tank cars, or two 6000 cubic foot covered hopper cars, and for each two cars unloaded, produces about two and a half loads of outbound product a day. Now, we will further define that the repackager does not manufacture its own empty containers, but buys these, and we'll assume that the shipper of the containers insists on using high-cube equipment, so as to maximize the amount of containers per carload. We can assume therefore, that the repackager will receive about five loads--four loads of product, and one load of containers--every two days, and will generate about five outbound loads every two days. For the purposes of this discussion, we'll assume that the repackager has four tracks in the plant; two are set up for inbounds, one with equipment unloading of hopper cars, and one with equipment for handling of tank cars, with the capacity for as many as four cars on each track, depending upon the length of the car. We'll also assume that on the shipping side, there are two tracks, one capable of handling four cars, and one capable of five; empty containers are received on the "shipping" track with five spots, deepest from the switch. We will also assume that the management of the plant is prudent, and in an effort to protect themselves from the occasional disruptions in transportation, has several days worth of inbound loads in the area most of the time. Finally, we'll assume that the railroad has one interchange with one connecting railroad.

Now, for us, the operators of the railroad serving this plant, the information that we are most interested in is the answers to these question: "What cars do we move?", "When do we move them?", and "Where do they go?". The transportation manager of the repackager will give us this information; he will call, fax, or send an email instructing us what inbound loads have been emptied and should be pulled, and which inbound loads should be spotted for unloading. He will also tell us which of the outbound shipments have been loaded, and are to be pulled, and what shipments he has for which he needs empties for loading. If it matters, the transportation manager will also advise us where to spot the inbound loads and empties. For the longer term, we're going to need a storage track for the extra days worth of inbound loads, and for the empties for loading.

So, let's assume it's a Monday morning, and we have reported to work. When we left on Friday, there were nine loaded cars on the hold track for the repackager, four tank cars (Tank1, Tank2, Tank3, and Tank4), and five hoppers (CH1, CH2, CH3, CH4, and CH5), and six empties for prospective loading (Box 1, Box 2, Box 3, Box 4, Box 5, and Box 6). In the plant, were CH 10, CH 11, and CH 12 on the hopper track, and Tank 10, and Tank 11 on the Tank track. There was a partial load in the empty container receiving spot (5) on one of the shipping track (BIG 65), behind three cars that were being loaded with outbounds (Box 23, Box 24, and Box 25), and two other cars on the other shipping track, (Box 31 and Box 32). When we did the yard check, we found that the outbound loads and empties left on the interchange track on Friday afternoon were gone, but there were a dozen cars there this morning, set out over the weekend: Tank 45 and Tank 46, CH 55, 56, and 57, and BIG 68 (all inbound loads) and Box 84, Box 85, Box 86, Box 87, Box 88, and Box 89, all empties. On the fax machine, is a switchlist from the transportation manager, containing instructions to pull CH 10 and place CH 5 in the spot it had been in, and to pull CH 12 and place CH 56 in the spot it had been in. CH 11 is to be returned for finishing of unloading. Tank 10 and 11 are both to be pulled, and replaced with Tank 1 and Tank 45. Big 65 is to be pulled, and replaced with Big 88. Box 23 is still empty, because the door was defective; Box 24 is a partial load, but Box 25 is an outbound load going to Miami FL, and Box 31 is going to Portland, OR, and Box 32 is going to Minneapolis, MN. Four empties are needed for loading, three to Minneapolis, and one to Miami. The Transportation manager also has faxed us a car order, that he is going to need three more empties to load to this week, and five to load to Miami next week, ten cars for Portland next week, and four more cars for Minneapolis this week.

Now, to summarize, the first step in a more realistic operations is defining more precisely what the industries do. This can be as little, or as highly detailed as one wishes; at one extreme, one can say that Acme industries consumes raw material A obtained from some origin point, and for each quantity of raw material consumed, requires a certain quantity of supply B, and produces a specified quantity of quantity C. When one establishes the rate at which material A is processed, on therefore has established how often a load of B is required, and how much, and how often loads of C are produced, and to where they are shipped. When this is done for all of the industries on the route, it then becomes possible to provide the traffic generators. I see the need for three of these.

I see the need for a couple of traffic generators and a status modifier. The status modifier analyzes cars spotted at an industry, and under the influence of a randomizer, changes the status. Most (85%) loads will be emptied on the first pass of the status modifier, most of the rest (90%) will be emptied on the second pass, and a few (1.5%) will be emptied on the third pass. Similarly with empties: most will be loaded on the first pass, though occasionally one will be rejected, and most of the rest will be loaded on the second. Rarely, a car will not be loaded until the third pass. When it has completed its run, the status modifier produces a list of cars (loads and empties) to be pulled from each industry. The first generator produces switch lists. It processes the industries in the route, it checks to see how many empty places, both those at which there is not now presently a car spotted, and those at which there is a car spotted whose status is changed. It then evaluates the loads consigned to that industry, and empties available for prosective loading, and generates a switchlist of cars to be pulled, and cars to be spotted. A second generator produces interchange receipt lists, a list of cars returning home empty, and inbound loads, and additional empties ordered by the car clerk. Finally, the third generator will produce car orders for loading.

Ideally, the status modifer and traffic generators can be made into "helper" applications. I don't think they need to be plug-ins as such, but they do need to process the Auran data file to be able to evaluate the industries and cars on a route. Eventually, I envision an editor not unlike CMP, where you open a route, are stepped through the industries, and define materials, supplies, and products, and optionally define origin and destination points, and proportions; you are also stepped through equipment on the route, and given the option of defining your home route roster. After initial set up, pre session processing before the session would generate initial interchange and switch lists, and place the necessary equipment on an interchange track, and change the status of cars at industries as required. Until the helper applications are developed, it would not be difficult or very time consuming to develop applications that will use the IBM [NB: "It's Better Manual"] method.

ns
 
I have operated with car cards that have sequential destinations and with 4-part way bills. I prefer the 4 part waybill,

OK. This is where I should probably post notice that I have had a fundamental dislike of the "car-card" model railroad operating schemes since I first read about it 30 or so years ago, with one exception. They are quite prototypical for those cars which must be returned home via reverse route when empty.

- option that automatically blue flags a car that has been spotted at its destination industry for a pre-specified amount of time

Well, if you're going to be faithful to the [U.S.] prototype, you won't want to "blue flag" a car. In U.S. railroading, the blue flag is a safety device, and is reserved for use by mechanical people, and when applied to a switch, car or locomotive, that car, locomotive, or switch may not be operated until the flag is removed, and the flag may be removed only by the employee who placed it.

The railroads do keep track how long railroad owned cars are spotted at an industry; there is a financial reason for doing so. A shipper gets 24 hours to load an empty car, or to unload a car received loaded. Beginning with the second day, he pays a penalty (called "demurrage"), which is higher each day to a maximum (Sorry, I don't know for sure what the current rates are; it might be something on the order of $10.00 for the first day, $25.00 for the second, and $50 for the third and each succeeding day after three. There is a mechanism built in, too, where the rate cannot increase on a weekend day or holiday.) Other than charging a shipper for the demurrage incurred by keeping a car too long, railroads do not keep track of how long a car is held at a shipper, an in the case of private cars (as in most tank cars and hoppers), the railroads don't even charge demurrage. A car is spotted when the shipper orders it in, and is pulled when the shipper orders it out. Other than doing the work, the railroad has no control over the process.

-ability to assign waybills to freight cars as they are added to a consist in Surveyor

Ideally, this would go a bit further, and consists would be created, and pertinent details added for each car automatically by a helper application.

ns
 
It occurs to me that this statement

... I have had a fundamental dislike of the "car-card" model railroad operating schemes since I first read about it 30 or so years ago, ...

deserves a bit more explanation. In my view, other than the exception I detailed, one of the biggest problems with car-card waybill systems stems from the age of the scheme. When it was invented thirty or forty years ago, it was conceived as a means of removing "unprototypical control", introducing a bit of randomness in operating, and minimizing the handwriting or typing that needed to be done. At the time the scheme was devised, inexpensive photocopies had not yet been invented. Car cards and waybills could be made once and used for a long time before they had to be remade. Also, some of the improved randomization schemes developed by in board based simulations had not yet been devised. Also, while there are a few instances of cars moving back and forth between one origin and one destination, most cars have much more varied travels. In these days of general availability of inexpensive, high powered computation (I'm guessing that the average home computer used by a gamer probably far exceeds the power of the roomful of computers used by the railroads when they got computers in the 1950s and 1960s.), I think a there are better means of controlling "prototypical" operation than the car-card system.

ns
 
Prototype Way Bills

. . . . I think a there are better means of controlling "prototypical" operation than the car-card system.

ns

I am not advocating a car card system. I'd like a system that does not Control "prototypical" operation, just a system that presents the data so the operator can control the operation if he/she chooses. Waybills are always current, no matter where the car is in it's travel to its destination. A switch list is only good for a brief period and is no longer useful once the car has been moved to its destination in the location for which the switchlist was created. Switch list creation can be an option, but it will be based on the waybills. The Waybill should be attached to the car for which it is created. I see a RMC (right mouse click) on the car in driver mode that will bring up the waybill in a small window. When the car is empty, the window will list empty routing instructions(ie: deliver to interchange ABC at <Specify City>).

I'd like to see a prototype way bill system that includes enough data elements to operate the railrod in a prototype maner. As I see it, there are some data items that are essential, and some data items that are "nice to have".

Essential data: Car Reporting Marks(Car Road and Number), Car Type(AAR code), Receiver(industry name), Receiver Location(city where receiver is located), Spot(where to spot the car when delivered) and Routing(ie: deliver to the XYZ interchange at <Specify City> so XYZ can take car to its final destination)

Information that is nice to have is: From(city,state) Shipper(industry name), contents. These items help with the illusion of operating a railroad in the real world.

Behind the scene, all the data concerning the industries and their capacities have to exist, but they will be mostly unseen in driver mode.

More to come.

Dap
 
. . . Well, if you're going to be faithful to the [U.S.] prototype, you won't want to "blue flag" a car. In U.S. railroading, the blue flag is a safety device, and is reserved for use by mechanical people, and when applied to a switch, car or locomotive, that car, locomotive, or switch may not be operated until the flag is removed, and the flag may be removed only by the employee who placed it.

ns

Well, when I was growing up along ther CNW mainline and a car would be spotted at the local grain elevator, whenever it was being unloaded, a blue flag was hung on the coupler to assure it would not be moved if a way freight happened to come along and want to service other spots on the siding. Definately a safety device, but not reserved for the mechanical people.

Dap
 
I've never really used the built-in waybill system, but it seems to me that pretty much any system that is used by a physical model railroad would be possible to use with Trainz as well, would it not? Either a physical car card system, or a software program? I realize that nothing currently out there actually interacts with Trainz itself, but you still wouldn't be any further behind a physical model railroader who has to input car numbers and other layout data. Perhaps Auran is better to leave that all up to us, since everyone would probably have a different idea of exactly what kind of system they want anyway.
I'm in the process right now of building a layout, and I plan to use a customized car-card system. I feel that Trainz is absolutely perfect for this kind of operation, since it's the only train sim currently out there that allows each item of rolling stock to have an individial running number, and also has unlimited, unscripted sessions. Plus, Proto-LARS is just awesome! These features, rather than shiney new graphics, will actually be the deciding factor as to whether or not I upgrade to either of the new sims.

Patrick
 
Guys.. I've been fudging around a bit with some prototypical switchlist programs. Although I would love something that could interact with Trainz itself, I can't see that happening soon. However there are some great programs out there that you can easily adapt to your 'virtual' layout. The best one I have seen so far though that combines ease of use and a huge feature set is Ship-It by Albion software. The only downfall is its cost. Its pretty close to $100. He does have a free 30 day demo if you want to give it a try. I recommend taking a look at the sample layouts he includes with it. I actually built the sample layout #1 last night and ran it through a session. I spent about an hour and a half switching on a two board layout and had a blast doing it. I actually used LARS Destination Database program in conjunction with it so I could actually tag the cars with where they were headed

The program is very powerful and can handle passing cars between towns and divisions. You can even set up offline industries to generate consignees or shippers for the industries you have on your layout. All in all a very cool piece of software if you don't mind the cost.
 
I have been a user of Ship It for years. I think I have gone through at least 3 upgrades of it. Like it has been mentioned, it is not cheap and more importantly, it is not for the casual user. There is a lot of work involved in the initial setup. As all movements are by individual car, you need a fleet of individual serial numbered cars, so that means the Lars Auto Numbering system won't work, nor using the same car more than once. I love it, but it really is for the hard core user.

John
 
I have been a user of Ship It for years. I think I have gone through at least 3 upgrades of it. Like it has been mentioned, it is not cheap and more importantly, it is not for the casual user. There is a lot of work involved in the initial setup. As all movements are by individual car, you need a fleet of individual serial numbered cars, so that means the Lars Auto Numbering system won't work, nor using the same car more than once. I love it, but it really is for the hard core user.

John

I thought it was fairly straightforward as far as the setup goes. There are some old dos based programs out there that I never figured out and I work in computers for a living. The Mad River Waybill program that was mentioned in the virtual railroader isn't too bad but it was a bit too simplistic for my tastes but is definitely better than what Trainz has now.

Honestly there are some great minds out there that if they probably came together they could model something that could work inside of Trainz.
 
Friends:

I've been giving thought as to how I want to implement some of the ideas discussed in this thread, but it seems to me that implementation of these ideas in the AURAN TRAINZ universe means that this thread will become off-topic in this forum. Therefore, future posts on this topic will be made in the "Surveyors, Operators, Drivers" Forum under the thread http://http://forums.auran.com/trainz/showthread.php?t=16776

ns
 
Back
Top