PDA

View Full Version : Ops on the Connell Northern



samusi01
5th Feb 2018, 11:22 PM
This is planned to be an irregularly updated companion thread to the (also irregularly updated) build thread found here (http://www.nscale.net/forums/showthread.php?43186-Northern-Pacific-s-Connell-Northern), but describing the background and use of JMRI Ops on the Connell Northern branch. Note that things may change as I don't leave well enough alone...

The present Ops setup is actually a very modified version of my previous layout's operation setup, which was designed to model mainline Northern Pacific traffic in the late 1960s. The Connell Northern branch does see mainline traffic at the southern terminus (Connell) but, as far as I can tell, not too much interchange traffic between the main line traffic and branch line traffic. Most branch line traffic originated from or was initially sent to Pasco and then on to other system destinations or interchanges, and my Operations setup reflects this. On the below map, Pasco serves as the origin point and a Pasco-Connell turn serves Connell. The remainder of the branch is served by a train starting out in Pasco, working up to the GN interchange at Adrian, and back again. Beet plant traffic in Wheeler has it's own road switcher during the campaign.

94181

One of the first things I did when setting up Ops, some years ago, was look at the various car types and - naturally - decide that I didn't want to use either of the supplied options, but my own version, based on what the NP used. What follows may be illuminating or serve as a basis if one wanted to use, say, UMLER car codes in lieu of descriptive ("HopGrain") or AAR ("LO").

The Hill Lines used more-or-less the same car codes by 1969, perhaps an artifact of the earlier failed merger or planning for the upcoming merger. Lists are available at various locations and I used one found in an old manual as the basis for my car types in JMRI. Problem is, there is 122 separate codes, 49 of which are used by my present fleet. I could use the editor in JMRI to one by one delete the extant car types and replace them with my own but laziness compels me to seek a faster alternative. It's found by looking at one of the files in the JMRI\operations directory, OperationsCarRoster.xml. As an XML file, it can be easily (and carefully!) edited with a basic text editor. The actual entries for the various car types look like the following:

<types>
<type name="A6" />
<type name="A7" />

...so I would have to again go line by line and edit. Easier by far, in my mind, than the usual method through the JMRI interface, but still not happening: too much work. Enter Excel, and concatenation. My cars were already in an Excel file with the correct NP car codes assigned. I simply grabbed the list of car codes, added a few lines of Excel formula, and all the necessary work was done. All I did was copy/paste into the XML file and save. Here's a screen capture showing the concatenation:

94182

Next up: differentiating car types.

samusi01
5th Feb 2018, 11:43 PM
The next problem I had was selecting specific types or groups of cars for certain routes, locations, or customers. As I'm on the road I don't have access to any fleet images so I'll have to use a stand-in.

94183

Three covered hoppers... the default JMRI ops would probably refer to these as hopsand, hopgrain, and hopcmnt respectively. If one of my N scale industries asked for a covered hopper for a grain load, they would probably be reluctant to accept either of the outer cars. So some means of differentiation becomes necessary, especially if the AAR codes (LO for all three) or NP car codes (C5, C6, C5 respectively) aren't quite enough to keep cars from going to the wrong track.

One idea would be to use the UMLER codes! Great idea: we now have little to no problem differentiating them: C111, C113, C611. Not really helpful on a switch list unless the operator really knows their stuff. Most folks could probably get by with LO, though, so perhaps something can be appended to the car type to help:

<type name="LO-C111" />
<type name="LO-C113" />
<type name="LO-C611" />

JMRI doesn't bother to print anything after the hyphen symbol so a switch list simply shows the more useable "LO" and Ops itself sees different types that can be allowed or disallowed at a specific spur, or have specific loads, etc.

As the NP's car types fall squarely into the 'not descriptive enough' category, I make extensive use of this feature. Here's an example: car type C5, a 90 ton covered hopper of capacity less than 3,900 cubic feet (much like the SP car shown above).

<type name="C5" />
<type name="C5-Dworshak" />
<type name="C5-Fertilizer" />
<type name="C5-Grain" />
<type name="C5-Ideal" />
<type name="C5-Malt" />

What we have here is all of the C5 types that are going to show up on a switch list, but with suffixes that pigeonhole them into various categories:

C5: the basic covered small covered hopper, usually cement/sand/etc.
C5-Dworshak: these cars were ones that the NP had assigned to service building the Dworshak dam in northern Idaho. They may carry cement, sand, or fly ash.
C5-Fertilizer: dedicated fertilizer service.
C5-Grain: dedicated grain/farm products service.
C5-Ideal: these cars were assigned to Ideal Cement, Seattle, Wash. Basically just like the C5 car type but with specific Return When Empty assignments for each car.
C5-Malt: NP assigned to Malt service.

As you can see, this allows a fairly fine degree of control but at a cost: each car type may require it's own custom loads, there will be additional work selecting which cars can go into a spur, schedules get pretty obnoxious... but I like it.

Hopefully these two posts will give a idea of various ways to leverage some of the features in JMRI for operations, car types, and traffic.

TwinDad
6th Feb 2018, 12:06 AM
LOL when I first saw this thread pop up I misread the railroad name as “Cannoli Northern” ... I simultaneously got a good chuckle and a hungry rumble in my tummy.

Some interesting ideas here on using the JMRI ops system and getting it to do what you want. I’ll be keeping an eye on this...

epumph
6th Feb 2018, 04:26 PM
TwinDad
and so will I!

samusi01
7th Feb 2018, 09:09 PM
I'm not a fan of pulling around a string of cars that are either 'L'oaded or 'E'mpty. I like to move freight, like the prototype.
94213
Above: an excerpt from an NP wheel report (lists all cars in train, types, destinations, etc.).

To accomplish this, I've completely moved away from the default JMRI loads of L/E and replaced them with custom loads. It's more work than simply allowing JMRI to swap 'L' for 'E' at a spur, but my typical manifest now looks like this:
94217
Where each car has a load of some sort and a specific purpose in life. It does deviate a little bit from NP practice but with my present setup I don't need to do very much scripting at all, and to more closely match NP practices would take more scripting than I've time to do or interest in doing. Perhaps someday...

As with car types, I tend to dive into the OperationsCarRoster.xml file and edit it manually to generate loads. It's much easier to do it that way, especially if loads are going to be the same for multiple cars. As an example, the NP shipped a lot of lumber and other wood products east, so XML lines simply get copy/pasted amongst various car types. The example plywood load

<carLoad name="Plywood" loadType="Load" />

is a line that I've pasted into multiple boxcar types and flat cars. A minor item to note is that each car type can have any number of different loads, but each load must have an original name. An example is found in westbound auto parts loads on the NP. Generally they were all marked as auto parts but a small percentage were labeled dangerous. As JMRI doesn't allow two loads to have the same name, I ended up creating two different loads to model the prototype. The originating schedule uses the random feature to limit the number of auto parts loads.

<carLoad name="Car parts" loadType="Load" />
<carLoad name="Auto parts" pickupComment="DANG" loadType="Load" />

As a side note, I don't really use the built-in hazardous check box as I seem recall that it to applies to the car and not the load. Very few of my cars are hazardous when empty.

Loads can have priority added, as well as pick up or set out comments (the HW for high/wide loads):

<carLoad name="Autos" priority="High" pickupComment="HW" loadType="Load" />

One note about pick up and set out comments is to keep them short and sweet: too long, and your manifest printout will get unexpected blank spots.

Priority affects how JMRI deals with the car, and empty load types can also be prioritized:

<carLoad name="MT" priority="High" loadType="Empty" />

Be careful on how those are used, though. Too many priority loads and soon the 'normal' loads are going nowhere and all your trains will be priority traffic.

The chief drawback with custom loads is that spurs will have to have a schedule of some sort to receive or ship loads, which does represent an increased workload when setting up Ops in JMRI.

samusi01
10th Apr 2018, 08:29 PM
Kernels are an interesting feature of JMRI. Essentially, a kernel is a set of cars that JMRI treats as a single unit of cars. One disadvantage of a kernel is that dissimilar car types can be used, but for custom loads, the load types must be the same. If one is simply using the default loads, no problem will be encountered.
Historically, a large percentage of the Northern Pacific’s eastbound traffic was lumber loads of various types, mostly in boxcars as centerbeam flats were just starting to be considered. For larger loads, flatcars or gondolas were used and, in some cases, ended up having one or more idler cars.Examples of this can be seen at the following links:
http://www.rrpicturearchives.net/showPicture.aspx?id=3298967 (http://www.rrpicturearchives.net/showPicture.aspx?id=3298967)
http://www.rrpicturearchives.net/showPicture.aspx?id=2472268 (http://www.rrpicturearchives.net/showPicture.aspx?id=2472268)
These loads can also be found on period wheel reports.

9570295703

I decided that this would be an interesting feature to model in JMRI.
I selected four 50’ flatcars (NP car type F5) and created two new car types, F5-Idler, and F5-Poles. You may recall from previous posts that the suffix “-Idler” or “-Poles” isn’t displayed on manifest printouts.

95705

I then created a number of loads for each car type.

<load type="F5-Idler">
<carLoad name="Machinery"loadType="Load" />
<carLoad name="MTY"loadType="Empty" />
<carLoad name="Lumber"loadType="Load" />
<carLoad name="Idler"loadType="Load" />
</load>
<load type="F5-Poles">
<carLoad name="Poles"loadType="Load" />
<carLoad name="Machinery"loadType="Load" />
<carLoad name="MTY"loadType="Empty" />
<carLoad name="Lumber"loadType="Load" />
</load>
As can be seen, the loads are the same except for “Poles”and “Idler”. I initially set the loads on each car to MTY and created some schedules that would cover various situations. I could probably get away with only including the lead car type in each kernel in the schedule, but I haven’t bothered to experiment.
95704

What this schedule means is that each kernel of two cars will arrive at the spur empty. The schedule will assess the chances of loading the cars with lumber (30% chance) or with poles. If the cars are loaded with lumber, there is no problem: as noted, each car in a kernel must be loaded identically so both cars get loaded with lumber and are dispatched to their destination.
If, however, the lead car is loaded with poles, JMRI has a problem. It can’t load any other car in the kernel with anything but poles, but the idler car type doesn’t have poles as a listed load. So JMRI substitutes the default load “L”. The manifest would then show the first car loaded with poles and the second car loaded with “L”.
Fortunately, there is a solution. In the JMRI example scripts folder, (see: http://jmri.sourceforge.net/help/en/package/jmri/jmrit/operations/Operations.shtml#TrainScripts (http://jmri.sourceforge.net/help/en/package/jmri/jmrit/operations/Operations.shtml#TrainScripts))there is a load replacement script that I slightly modified to specify the cartype F5-Idler and loads L and Idler. I run this script after the cars have been spotted and JMRI substitutes Idler for the default load L.
95706

The end result looks like this:
95707
Other examples of uses for kernels might be a wrecker or crane and idler car (no need to mess about with loads) or military loads as those seem to be handled as unit trains. For modern modelers, Boeing fuselage loads and windmill blade loads would be ideal candidates for this custom load replacement script.

samusi01
25th Apr 2018, 10:47 PM
Team tracks can provide a layout destination that can host a large variety of loads and car types without the need to model a correspondingly large collection of buildings. As an example, Northern Pacific documents show the city of Grand Forks, ND, listing about 40% of the 140-odd businesses as team track customers in 1967. These customers dealt in goods such as autos and auto parts, building supplies of all kinds, appliances, newsprint,farm machinery, implements, and tires.

A similar industry to a team track Ė but more applicable to a larger city Ė might be a freight forwarder or transfer and storage facility. These could be either railroad owned (the N.P. had a large facility in Pasco, Wash., and the ATSF owned freight houses all over) or non-railroad. The most significant difference would be that the traditional team track usually has only a loading ramp whilst these facilities will often feature some sort of warehouse or other loading dock.

In JMRI, creating a basic team track is very easy Ė simply create a spur, allow the car types that should visit the team track, and thatís it. Using schedules makes the team track a bit more complex, but still manageable: the schedule needs to support each of the desired customersí cars and loads. My tendency is to use match mode for schedules, allowing a degree of randomness to develop. Cars will still be delivered to the team track, but now they will have specific loads, or depart with specific loads. JMRI will send cars to the "Team Track" or whatever other name has been chosen for the track.

A JMRI feature that Iíve not yet addressed is track pools. Basically, a track pool allows one to assign multiple industries to the same section of track, which is what a team track basically is. Iíll use the Connell team track on my layout as an example of a track pool. Connell had a large set of industries that were team track industries. The 1967 industry list shows the following:

Connell Builders Supply Co Building Supplies TEAM
Connell Farmers Supply Co Farm Machinery TEAM
Connell Grange Supply Co Farm Hardwares TEAM
Daugherty Implement Hardware Farm Machinery TEAM
Farm Service Inc Agricultural Implements TEAM
Seuell Implement Co Farm Machinery TEAM
Union Oil Co Petroleum Products TEAM

Iíve created a separate track for each of the industries Iíve chosen to model for the team track and grouped them together as a track pool:

96065


When I created the pool, I took the total length of the team track (130 feet), divided by the number of industries (5) and used the result (26) as the initial spur length for each industry. As I added each spur to the pool I assigned a minimum length of zero feet. The end result is the pool has the total length of all the tracks (130 feet) and each industry can have zero feet assigned if another industry receives a car.

96066


JMRI will automatically adjust each track length as necessary to permit cars to be spotted. In this case, Builderís Supply and Seuell Implements are each receiving one car, and the twelve feet assigned to Grange Supply is probably a leftover from when it last received a car. A slight hiccup to managing a team track this way is that each consignee will require its own schedule; Iíve cheated and re-used the same schedule for industries that received the same loads, such as Daugherty Implements and Seuell Implements. An advantage of managing a team track this way is incoming cars are destined to a specific consignee, not just the team track, but one must brief guest operators on whereall these industries are located.

TwinDad
25th Apr 2018, 11:31 PM
You should turn this into an article

samusi01
26th Apr 2018, 03:14 PM
You should turn this into an article

That's an idea I've not yet considered, and I'll have to look into. Part of the reason for the enormous gaps between posts is I do these from a hotel room.