Computer technology overhead

This blog post is just a rant about the fact that any human activity involves a certain amount of "overhead", like it or not. For example, I resent the fact that I have to spend up to a third of my life sleeping when I could be doing something productive during those nighttime hours. Also, who likes to pay taxes, but in fact a well-functioning society needs things like courts, legislatures, fire departments, etc. in order to function well, and the cost of these services is another type of "overhead" for collectively enjoying a good life. Get over it. Pay your taxes and get some sleep.

I also resent the amount of time I spend with overhead in the hobby of model railroading. I developed the diagram shown above to illustrate a clinic on how to set up and use the braking features of modern locomotive decoders. I wanted to be clear how complex a simple DCC system can get, pretty quickly. All the operator wants is to experience is a train with realistic motion, lights and sound. but the experience provider (aka. layout owner and the various product manufacturers) will have a considerable overhead to maintain, both in designing the system and, per the asterisks in the diagram above, keeping up with "firmware upgrades." (I should have just said "software and hardware upgrades," but I wanted to sound fancy. For example, do you remember to replace the coin battery inside your NCE Powerhouse Pro every 5 years? I've been doing this religiously for almost 20 years now, and writing the date when I do it on the bottom of the unit on a sticky label I put there just for that purpose. You could call that a "hardware upgrade," but really it's just maintenance.).

Let's pick on one item for a minute - loco decoders. I am operating a layout with a combination of Tsunami and LokSound decoders in a fleet of over 80 locomotives. I generally use JMRI DecoderPro and NCE "Programming on the Main" (POM) to make adjustments in the Tsunami's, but one of the "advantages" of the ESU LokSound decoders is that, if you use their proprietary "LokProgrammer" hardware and software, you can "upgrade" the "firmware" in the decoders over time. In fact, I usually find when I unpack a new ESU-equipped loco from the store and hook it up to the LokProgrammer, the first thing it notices is the need for updated firmware to be loaded onto the "brand-new" locomotive.

But the LokProgrammer "free" software only runs on a PC platform, and I'm running a MacBook Pro (new in 2013 - uh-oh!). This means I need a $60 software called "Parallels Desktop" to create an artificial PC environment running inside my Mac, in order to download and operate the LokProgrammer. Which I only do occasionally. If you're familiar with the PC environment, you know that Windows is constantly uploading software upgrades and security patches, what seems like every few days. Go for two months without opening it, and you are in for a long process of downloading and installing these upgrades retroactively, often involving restarting the computer several times. When all I wanted to do was adjust some CV settings in a single locomotive.

It gets worse. Apple keeps upgrading its operating systems as well, and Parallels Desktop has to upgrade to keep up with that, while Microsoft has to continue to keep the Windows environment working. The end result is that, in anticipation of receiving my long awaited ESU-equipped ScaleTrains BN SD45's (which I'm sure are going to be super cool and fun)(which, by coincidence, are going to be arriving on my birthday, tomorrow!), I tried firing up my LokProgrammer yesterday to make sure everything is ready for those new 3600 horsepower monsters.

Forget about LokProgrammer - Parallels Desktop itself wouldn't open. I restarted this and that, re-downloaded and installed the program, and it still wouldn't open. I finally found a YouTube video with a guy in broken English telling me about a couple of lines of code to type into the "terminal" of the Mac (kind of like the inner control room of a nuclear power plant). Which I did, and then Parallels Desktop miraculously opened. Yay! Then, of course I had to restart the computer several more times for Windows to complete installing its latest security upgrades etc. Then, after at least 4 hours (or more) of time focused on nothing but computer overhead), the LokProgrammer software opened. But, of course, ESU recently released an upgrade, so I needed to download and install that, too. That task only took, say, 10 minutes, for which I was grateful and relieved. Just to make sure, I restarted the computer and started everything up again (another 10 minutes), and yes, it seems like I'm now, finally, ready to take in the new SD45's tomorrow. Happy Birthday!

"There has never been a better time to be a model railroader" is a true statement. We have an array of products, services, communication tools, research resources and inspiration that is unprecedented and worldwide. But it still has some overhead costs, just like everything else. I don't have to like them, but I have to pay them.

More on 1970's grain handling

 

Building on my previous post, there are two interesting aspects of grain handling I've been thinking about:

(1) For the empties, they weren't sent to a specific elevator, just "up the branch" (see previous post). The conductor would just take a string up there and spot the right number of cars. Which car number didn't matter at all. So having a specific destination on a waybill for an empty doesn't make sense to do on the model railroad, either. I guess I could just put "Mansfield Branch" on my waybills and accomplish the same thing, since I don't have enough room to model branchlines east of Stevens Pass.

(2) For the loads, Bob Stafford and Ray Wheeler have told me that each car's load had a specific moisture content and protein content, as measured at the originating elevator, and so they would spot the loaded cars at Cargill (Seattle's 4 million bushel Export Grain Terminal at Pier 86) in very specific order on specific tracks, by car number. Switching Cargill was a huge switching project. I was just thinking "shove them all in there and forget it!" How wrong! They would store the cars both next to the export grain terminal and in Balmer, and (sometimes) call for them to be unloaded by specific car number. I could simulate this by making up a switch list for the grain terminal switcher, but I'm also thinking that I could put moisture and protein attributes on the waybill itself, and then give the switcher instructions on which attributes go to which track, possibly in which order, and let them figure out how to switch it. In addition, the unit trains of covered hoppers were also switched out this way, after they terminated in Balmer yard (Interbay). The 40' boxcars from the light branchlines came in to Balmer yard (Interbay) too, but on regular manifest trains, not in the unit trains.

The bottom line is that, when I get the paperwork straightened out, someone is going to have a lot of fun taking several hours to work Pier 86. I was mistaken, thinking it was a trivial job!

Empty Grain Box (XGB)

Here's a random 40' boxcar sitting in my HO model of Stacy St. yard in South Seattle set in 1973. It needs to be weathered more, but that's another subject. Add ACI labels, take off roofwalks - also other subjects. But for today, have you seen the 2020 print edition of "Great Model Railroads" by Kalmbach Media? The first featured layout, by Clark Propst, has a really interesting sidebar about how he made his car card and waybill system more realistic by letting his conductors decide which empty boxcars to spot at which grain elevators along his modeled midwestern railroad (M&SL) branchline. Since you're reading this, you're as addicted as I am to over-thinking model railroad operations, so bear with me.

All he did was write "XGB" on the car card behind the waybill pocket. And, to quote him, "Instead of getting a sleeve for every empty boxcar, trains are issued a single sleeve with a slip that tells the conductor how many empties are to be dropped at each elevator on the branch. This is more prototypical than forcing the crew to spot a specific car." He uses plastic "sleeves" to hold both the "car card" information, and, inserted on top of that, the single waybills that he uses. So, if a conductor receives a sleeve with instructions to spot 3 mty cars here and 5 mty cars there, he finds 8 mty (XGB) cars in the yard and puts them in his train. He doesn't care which ones, and nobody else does either. When his run is finished, the grain elevators now have mty cars to load, and their car cards are sitting in the respective car card box on the front of the layout. In between sessions, he can insert waybills showing where the now loaded car needs to be shipped next.

Since I use the preprinted MicroMark car cards, the "X" seems a bit redundant with the "EMPTY CAR" already printed on the car card, visible when there is no waybill present. Now, what if I simply crossed out "RETURN TO" and replaced it with a list of viable uses for car. I could write "Available for:" and then list out "grain, lumber". The conductor of a local would get a "train brief" in a plastic sleeve, with the number of mty grain and lumber cars needed that day at various spots, make up his train as needed, and go. Better yet, if the yard had a yardmaster on duty, the yardmaster could make up the train using that train brief, and then give the train brief with car cards to the conductor. Along the line, the conductor could make his/her own decisions about which mty cars to spot at which spots. If either one of them wanted to write up a switch list, I suppose they could, but I'm not sure why it's needed, since they already have the train brief and the car cards in hand.

I'm liking the flexibility of this idea. The train brief could also have information on any other blocks of cars that would be included in that train, such as loads billed for specific towns and spots. Presumably the yardmaster would have those blocks ready to go by train time, which the train brief would help guide. In the past I have relied on a "train instruction card" which said simply "pick up cars destined for x, y and z." Now I'm thinking of turning the train instruction card into a sleeve like a car card, with the standard blocking instructions for loads and specialized empties, and the ability to hold additional slips of paper indicating the empty car orders for generalized empties, such as grain and lumber. If there were too many, or not enough empties available during an op session, well, that sounds like a real railroad, doesn't it?

What do you think of this idea? Here's a photo of my "variation" on Clark's brilliant idea:

Playing at the turntable

 

A picture is worth a thousand words, right? The turntable in Everett needs to be ballasted and weathered, but what the heck, I spent an hour today just playing with it. Putting away a few locomotives that were blocking the turntable lead track, and such. The stock Walthers motorized turntable worked flawlessly. Once it was done, I had to take this picture. You'll notice that everything is in focus - this is the result of a software program called Helicon Focus, which merges multiple images of the same scene with different parts of the scene in focus, into one image, such as you see here. It's quite quick and easy to do. I propped up my iPhone on a nearby steady surface and focused on each engine in turn, taking 7 photos altogether. This is the resulting merged photo.

Of course, a "real" turntable would have some empty tracks ready for the next inbound engine, right? Also, since I'm supposed to be modeling the BN in about 1973 after the merger, can you see which engine is not supposed to be there? Only the hard core railfans will be able to tell. And I'm not talking about the two GN GP's that haven't been renumbered yet, either (911 and 710). I'll get to that eventually.

Anyway, I hope you enjoy looking at this picture as much as I do! :) Model railroading, at its deepest down core, is about locomotion. Serious locomotion.