JMRI (Java Model Railroad Interface) is often thought of as 'a DCC thing', probably due to the Decoderpro software that forms part of it - but it's got parts that can be of use to almost any modeller - 'Operations' is just one of those sections - and anyone who has used other bits of JMRI already has this installed as part of that package.

JMRI ops allows you to use virtually any computer with a printer to run a computerised car forwarding system for your layout, with manifests and/or switchlists for your crews to work from.

The thing I like most about it is how flexible it is, it will work at any level between a simple 'lets move some freightcars around' right up to being able to schedule complicated flows of specific loads and empties between groups of specific industries.

We've now used this at several operating sessions - there's a bit of a learning curve involved, but I can reccomend having a play to see what it can do for you.

Reasons why this may be better than CC&WB? (IMHO)
* The operating scheme and level of detail can be as simple or as involved as you want/need it to be
* On a complicated layout, the operating scheme becomes 'transparent' to the crews (the system tells you where to put the cars, it tells the connecting trains what cars to pick up - nobody has to try and work out on a car by car basis how to get that car from A to D via multiple connecting trains.)
* Easier for 'newbies' to pick up the operation than with CC&WB (as above - the manifest tells you specifically what moves need making - you're not relying on a crew converting a big pile of cards with the raw data into an efficiently operated train)
* Paperwork more comparable to modern (1970s+) prototype equivalent than CC&WB

Reasons why CC&WB may be better than a computerised system? (IMHO)
* Misroutes are self-correcting (in OPS you will need to manually update the system if a car isn't picked up or dropped off as per the manifest, whereas with CC&WB provided the car and waybill are both in the same place it's self correcting)
* CC&WB may be more appropriate for your era?
* Less reliance on tech

A lot of good points, however I would not agree that CC&WB may be more appropriate for some eras. I understand that a switch list was written by the conductor based on the waybills, all JMRI does in this instance is create the switch list directly.

So the end product is still a switchlist (which today could indeed be on a computer in the cab as opposed to a handwritten list.)

Ah, the joys of Theory V Practice. I love Theory. It's just a shame that it seems to me that nobody else does, because their Practices stuff mine up at every opportunity. Yours too, Peter, by the looks of it. I programme computer systems in my day job, and do you think I can get my users to use them properly? And then they blame me because it doesn't do what they want it to. Ah, the injustice of it all.

We're about to start getting serious about ops at Seaboard Southern and using JMRI to help. I love car cards and waybills, but they can be a bit labour intensive to set up, and troublesome to get a good load balance between trains and storage capacity in yards and so on. It's been claimed that you can do the whole thing on JMRI, though I don't think it can do actual car cards and waybills. Does that include scheduling empties for for picking up loads, delivering the loads, and returning the empties, allowing time for loading and unloading, all in a timely and realistic fashion? I've started working on a system using car cards and waybills because initially we didn't have JMRI hooked up. I converted them manually to switch lists myself. Any starting tips would be gratefully received.

I think it needs to be clear that there's a labour intensive side to this as well - there's a definate data entry element, and you then can spend hours "playing" to fine tune some elements if you so desire. CC&WB does have an advantage in potentially a simpler setup on the day, but I think you then lose that advantage in crews working it less efficiently (or not at all!)

On the data entry for example, you don't want to turn up at a meet and then build the JMRI model for the layout, or start doing data entry for the freightcars at that point - it really is an in advance thing. For a "one off" layout I would have built the whole thing and entered the cars in advance, and on the day would give each person bringing freightcars a printout of their car starting places. Obviously adding a car or two extra on the day if somebody brings something different is no great shakes, but doing the data entry for 100+ whilst everyone is waiting to run trains is something to avoid!

If you have the advantage that it normally goes together the same way then the workload goes down drastically after the first run.

It's been claimed that you can do the whole thing on JMRI, though I don't think it can do actual car cards and waybills.

I think it can do everything I need it to do - I don't think it needs to produce CC&WB, as it's giving you the relevant info in the switchlist so the crews don't need all the info on the CC&WB. They don't need to know the final destination of a car for example, just where they pick it up and set it out.

Does that include scheduling empties

Yep, assuming you give it a schedule - all of the following is optional:
A schedule can cover what car types the industry uses, whether (and what specific loads, if you also use custom loads) loads arrive or depart in each car type, whether (and how often) a load inbound generates a backload out of the industry, and whether loads heading out must go to specific destinations, it can force cars to arrive in a certain order (industry must have 3 covered hoppers and then must have a boxcar), it can do different days of the week if you so desire and (as below) it can make cars wait a certain number of trains before being picked up again...

picking up loads

Yep

delivering the loads

Yep

and returning the empties

Yep - assuming you want specific empties to go to specific places. Otherwise it will release empties to "free run". I tend to use a mix of techniques to try and emulate what is likely on the real thing - some cars will be locked into a pool cycling between two or three specific places, but others (say plain boxcars) "free runners" which after working a job then become free for any other job for that car type.

allowing time for loading and unloading

As above - yep.

, all in a timely and realistic fashion?

I believe it does.

Any starting tips would be gratefully received.

I'm happy to help - there is a kinda tutorial on their website, or just dive in and ask questions and I can try and answer? Up to you.

One thing I really like - you can "operate" the system you build without the layout, so you can dry run it and look at how the traffic is flowing, fine tune, and tweak and test to your hearts content before you ever set the layout up and try and run it. That is a very useful thing for modular and portable users...

Martyn has beaten me to it, even as I write! Not sure if you are talking modules or permanent layout. The big problem with regular meets is club members wishing to bring a different set of cars to each meet. Typing stuff in is just a bore, whereas configuring the layout is fun. My advice would be keep it simple at first then slowly add in schedules. The first I would recommend would be a generic hold to force cars to wait a turn or so at their spot (basically for the train after next to pick them up).

Gentlemen, thanks very much. That pretty well answers all my questions so far.

Martyn, with regard to the "free runners", can you direct them back to some storage location equivalent to "Return when empty to ..."? Also, I wonder if you could invent a dummy load called "cleaning" and direct them to a cleaning track? And then I might start asking about RIP and stuff like that. But I'll save that for later. I think we've got enough to be going on with. I rather like the idea of doing dry runs. I think I'll look into playing with that.

Our club layout is a mixture of fixed and modular, if you know what I mean. There's a fixed plan that consists of a load of modules, but we may be swapping modules in and out at random, as they become available, or as we want a change. I don't see us changing them around that frequently, however, so we'll probably just treat it as a fixed layout and worry about the changes as they happen. In the first instance they're likely to be additions rather than replacements, but we'll see how it develops. In the first instance we'll just use something very simple, but ultimately I'd like to get us to the stage where we can try some proper operations over several "days" and following complete cycles of car movements.

There is a Return When Empty (RWE) function, or you can set it so that empties from a specific industry go to a specific place, which personally I think is a bit easier to deal with.

We've had layouts where there was a car repair shop, and we had a "for repair" load that fed them, cars for that could come at random from staging, or from other industries in a schedule (for instance every 10th boxcar that arrives at a certain industry with a load gets "for repair" to the shops as an outbound load.)

Cleaning could work a similar way assuming the cars go to a specific place for cleaning...