That deadbeat in the train

While walking today I heard a train whistle in the distance. The train seemed to take forever to arrive. When it did, I saw a loaded ethanol train with two locomotives up front. The lead engine was just screaming while the second engine didn’t appear to be running. About 10 minutes later came the back end of the train with two locomotives working so hard they sounded like they were ready to blow up. It looked like 3 engines doing the work intended for 4 engines.

At that point, is the second engine functioning as just a very heavy, non-revenue producing car along for the ride?

It’s saving fuel by either being shutdown or isolated. A very common occurance.

I’ve noticed GE’s “Trip Optimizer” Energy Managment System will often work the DP unit(s) more than the lead. There are places where you need to do that, but T-O does it a lot and more so than an engineer would.

Jeff

On CN we aren’t allowed to have more powered axles in a remote consist than in the lead consist.

Jeff’s answer is the most likely case, though that unit could also have suffered a mechanical failure. Regardless, it is just along for the ride, and isn’t doing anything to help move itself or the train.

Our HPTA program (horsepower per ton analyzer) does not count the weight of the non-functioning unit(s) toward the trailing tonnage of the train. In a few cases this has resulted in trains stalling on grades even though the working unit(s) should be able to just make it.

Engines do fail enroute. If you can keep moving with the power you have - you keep moving.

Our Equivalent Powered Axle calculations does take into consideration any dead or isolated engines. However, due to rail conditions during inclement weather, I’ve still stalled while being at and even under the EPA route restrictions.

Jeff

Sounds like your programmers were trained by the people who worked on NAJPTC and set up trains with zero length…

The default length of trains in CSX’s CADS is 9999 feet. CSX data systems when calculating HPT, use the HP of all locomotives in the engine consist as the Car & Train data systems are not configured to know if a locomotive is operating or dead. Locomotive Management’s data systems do know if locomotives are operating or not.

That’s pretty sad. Moreover it answers the immediate following question ‘does CSX count the weight of dead or isolated units in the trailing tonnage?’ It’s pretty clear that if all the units are assumed to be making power, none of them are counted in the ‘trailing’ resistance… double the stupidity. [D)][D)]

Why there isn’t data fusion between Locomotive Management and Car & Train is the question that perhaps needs to be asked – and fixing this ought to be a priority for any financier-driven PSR railroad that intends to minimize OR while operating monster trains right at the edge of HP/ton under all operating conditions. In fact it could be argued that setting up a kind of data warehouse to store streamed, realtime locomotive condition would allow dynamic modeling access (for example, to predict whether a train may stall a few miles ahead if there is an engine failure or derating) and therefore enhance the ‘precision’ of the ‘scheduling’.

PTC counts engines in the trailing tonnage.

Car & Train data system was a legacy system that actually predated the creation of CSX as it was the system that Seaboard System was using prior to the creation of CSX. It used the state of the art technology of the 1970’s. CSX’s in its corporate wisdom of the time felt it had more needy areas of its operation to invest it’s computer application design efforts to, rather than to redesign a existing applic

But there often comes a time – and it comes early and hard in many aspects of railroading – where the people cannot make informed decisions without full computer or data support.

Here the issue goes far beyond expeditious car tracking and ‘logistics’ – and it does not occur to me that extensive legacy coding would be necessary for the purpose of calculating effective power or train resistance. Even if it were nothing more than a tool run on the data from the existing calculations, it would be a useful guide (if necessary via recursion) both as a reality check making up trains and a realtime tracker for changes enroute. This would likewise be a logical place to incorporate other sources of cumulative train resistance, e.g. transient weather conditions that might have an impact on routing or scheduling in a PSR model with any considerable ‘slack’ in its critical paths.

Perhaps more important that the speed and memory capabilities of computers in providing information is the communication that lets a tablet, computer, or cellphone communicate the data that the computers make available.

A yard clerk (if there is still such a thing) can have the entire manifest for a 13,000 foot train in his/her hand in seconds. It would have taken a lot more time to print out the same information on paper. A railroad official at the scene of an incident can have info on the train’s consist in seconds, assisting in emergency response and clean-up.

I was looking for a comparison between the IBM in “Hidden Figures” and today’s cell phones. It’s virtually impossible - both memory and processor speed are literally millions of times faster.

If you haven’t watched “Hidden Figures,” you should. It provides an object lesson on the progression of technology.

When initializing PTC the trailing tonnage used by us is the tonnage of the cars alone. Engines in the consist aren’t reflected in that number. However, all engines are listed including their status. Working engines are shown as in “run” status. All non-working engines, whether idling or dead, are shown as “isolated.” I’m sure the system takes into account the weight of the entire engine consist when calculating braking distance.

When initializing EMS integrated into PTC, it will ask if the dynamics are cut in or out. The EMS needs that info but PTC doesn’t. EMS can operate dynamics, PTC can’t. If you have light power, PTC calculates braking distance on the braking power of the locomotive’s brakes alone.

Jeff

Per Larry’s post. Hidden Figures is indeed a terrific movie. Highly recommended.

We are required to have two copies of the train list when handling trains with hazmat. One to be retained on the engine and to be used to show first responders the position of hazmat in the train.

They are trying out some new electronic devices that can do everything in the field you can do on a computer terminal. It’s also a communications device that can be used in place of a radio on long trains when the conductor’s hand held can’t reach the engine. (It’s supposed to be able to dial into the wayside radio towers.) It can also be used to take and release track authorities.

The biggest thing is it can do all the paperwork for the train. It can report in real time work done, resequence cars in the train or on a track. I’m sure the ultimate aim is to get rid of paper lists, if not computer terminals in the office themselves. Engineers aren’t issued anything, so far.

So now, if we become paperless in the future and go into emergency, and the air doesn’t come back, the conductor and his Zebra (I think it’s the manufacturer’s name) start walking. Fifteen or twenty minutes later there’s a big boom with lots of fireworks. I can’t raise the conductor while I dial the 911 call to the dispatcher. He sends the call for the first resp

I’m pondering how that conversation goes:

“Where’s the hazmat matrials?”

“66th car back.”

“Where’s that?”

“About a mile or so back in a train where all the cars look alike to non-train people.”

Indeed. We (first responders) are told to seek out the conductor/whoever is in the cab to get the consist.

I would suppose the only reason to have a dynamic resource would be if the consist is going to change - ie, a local or other train making pickups and drops.

After the engines start counting couplings beinging with 1