Amtrak’s Growing Pains with Siemens Locomotives

CSRR573 wrote: ↑Tue Jul 05, 2022 1:50 pm

ApproachMedium wrote: ↑Tue Jul 05, 2022 3:32 am Why on gods green earth do we need nonsense like this????

The best is the TOD that constantly goes back to traction status when your trying to read important data. One of our tech literally said it was one of the best mods they've done so far

I found it to be more of a distraction then beneficial while running at first, they seemed to have ruined the car wash mode in the last update as well!

Any mechanical item be it auto, loco or other items needs to be able to default to the basic function of the item. Not go on some wild or even unintentionally dangerous path.

What should it be called fail soft instead as AM seems to found it fails hard.

Like a car auto transmission that if certain things go wrong it might lose high gear, or if ABS senses a problem it gets disabled but not the brakes themselves. On heavily computerized commuter locos, something goes wrong and the loco and train can only move at a lower speed than normal, but it can move at what was predetermined a safe speed for that fault.

photobug56 wrote: ↑Mon Jul 04, 2022 9:34 pm Are these computer languages I'd have heard of?

Most microcontroller code is written in C, some newer stuff in C++. Some older DoD stuff is in Ada. Older stuff (and some new stuff where speed or memory usage is a concern) is often written in assembly language. Assembly is very low level and each line of processors has its own assembly language: each line of assembly code usually corresponds to a single instruction on the processor. Each processor brand/model often has its own paradigm so for instance knowing ARM assembly language (RISC paradigm: many registers; many, less-complex instructions) is different from knowing Intel x86 assembly (CISC paradigm: fewer registers; instructions can be more complex), or TI C6000 DSP (VLIW architecture with predication, programmer responsible for managing execution units and scheduling instructions).

Now ideally, once you've learned one assembly language (I was taught MIPS R2000 in school 20 years ago) it's not that hard to pick up another, but it takes time to become proficient. Also, the development and debugging tools for microcontrollers are often vendor-specific and it takes time to bring a new developer up to speed there as well.

Are these computer languages I'd have heard of?

While the languages are likely those you've heard of, the operating systems for critical control systems likely isn't. While something like Windows or Linux might be good for information kiosks, passenger information displays, point of sale terminals, and the like, software for controlling operation of the train is almost certainly running in a Real Time Operating System (RTOS). Traditional operating systems are "best effort" when it comes to how long it'll take to respond to events, such as sensor or control inputs. An RTOS provides deterministic (i.e. defined and predictable) timing in response to such events, allowing for precise control in embedded systems.

In order to accomplish this, an RTOS may provide functionality that seems basic, limited, and/or more complicated than what a programmer experienced in other environments is used to. Many of the convenience features and safety guardrails that allow programmers to weave complex systems together don't exist or have hard limits placed on them to ensure system behavior meets specifications.

Source: A long programming career that started with embedded control systems for DOD hardware.

And a lot of stuff (especially older stuff) is "bare metal" with no operating system at all. I must say despite being a bit of a purist and starting out with C and bare metal, I've found that C++ with an RTOS is much easier to program on and maintain. And often, there's minimal performance impact.

I have not seen the Chargers yet nor am I qualified to operate them and I don't run under the wire and have no knowledge on the ACS64. Judging from what Ive read and heard they could be a bigger PIA then dual modes I currently deal with. All I want is the ability to turn on the headlights and turn off the markers. When I say giddy up it moves and when I say whoa it stops. Really don't care what program makes all this happen or feel the need to learn nuclear launch codes to solve simple issues. Just want to run trains not fly the damn space shuttle.

WhartonAndNorthern wrote: ↑Wed Jul 06, 2022 8:46 am

photobug56 wrote: ↑Mon Jul 04, 2022 9:34 pm Are these computer languages I'd have heard of?

Most microcontroller code is written in C, some newer stuff in C++. Some older DoD stuff is in Ada. Older stuff (and some new stuff where speed or memory usage is a concern) is often written in assembly language. Assembly is very low level and each line of processors has its own assembly language: each line of assembly code usually corresponds to a single instruction on the processor. Each processor brand/model often has its own paradigm so for instance knowing ARM assembly language (RISC paradigm: many registers; many, less-complex instructions) is different from knowing Intel x86 assembly (CISC paradigm: fewer registers; instructions can be more complex), or TI C6000 DSP (VLIW architecture with predication, programmer responsible for managing execution units and scheduling instructions).

Now ideally, once you've learned one assembly language (I was taught MIPS R2000 in school 20 years ago) it's not that hard to pick up another, but it takes time to become proficient. Also, the development and debugging tools for microcontrollers are often vendor-specific and it takes time to bring a new developer up to speed there as well.

I learned Basic Assembler Language in college, using it combined with COBOL, so I get what you're saying. It's good to get this sort of training early on in a computer career, and understanding it did help me years ago until I stopped programming some time ago. Few programmers get trained in things like this then and today.

Railjunkie wrote: ↑Wed Jul 06, 2022 11:15 am I have not seen the Chargers yet nor am I qualified to operate them and I don't run under the wire and have no knowledge on the ACS64. Judging from what Ive read and heard they could be a bigger PIA then dual modes I currently deal with. All I want is the ability to turn on the headlights and turn off the markers. When I say giddy up it moves and when I say whoa it stops. Really don't care what program makes all this happen or feel the need to learn nuclear launch codes to solve simple issues. Just want to run trains not fly the damn space shuttle.

The space shuttles had what I believe if a far more complex, antiquated interface, where you had to type in commands on a small keyboard to get certain things done. Siemens sounds a little bit more up to date!

Railjunkie wrote: ↑Wed Jul 06, 2022 11:15 am I have not seen the Chargers yet nor am I qualified to operate them and I don't run under the wire and have no knowledge on the ACS64. Judging from what Ive read and heard they could be a bigger PIA then dual modes I currently deal with. All I want is the ability to turn on the headlights and turn off the markers. When I say giddy up it moves and when I say whoa it stops. Really don't care what program makes all this happen or feel the need to learn nuclear launch codes to solve simple issues. Just want to run trains not fly the damn space shuttle.

Or try to fix everything by rebooting, like a Windows administrator.

scratchyX1 wrote: ↑Wed Jul 06, 2022 12:27 pm

Railjunkie wrote: ↑Wed Jul 06, 2022 11:15 am I have not seen the Chargers yet nor am I qualified to operate them and I don't run under the wire and have no knowledge on the ACS64. Judging from what Ive read and heard they could be a bigger PIA then dual modes I currently deal with. All I want is the ability to turn on the headlights and turn off the markers. When I say giddy up it moves and when I say whoa it stops. Really don't care what program makes all this happen or feel the need to learn nuclear launch codes to solve simple issues. Just want to run trains not fly the damn space shuttle.

Or try to fix everything by rebooting, like a Windows administrator.

Pulled the knife switch a few times dropped breakers even had the "are you sure this will work" conversation with mechanical. Some of the time I could get it to move, some we waited for a rescue to show up. Old timer I worked with always said they needed to give it a game to play kinda like Tron not the re make the original.

The Siemens locos all run on Linux software. The original run away throttle problem they had (around the same time 188 crashed) was a problem in the programming that when reached said bug the OS would crash, revert the date to Linus Torvalds birthday and the throttle would get stuck in power until it reset itself a minute or two later. Similar issue would happen with the dynamic. The dynamic was a better situation because stopping is more favorable than going out of control.

Ill take knife switching old diesels any day over playing system IT admin on these ACS. When certain problems happen i turn the battery contactor off and that upsets some people. But guess what? It gets it going again, and i dont want to live here i want to go home.

I remember when touching the battery switch use to be a big NO NO around here, until they realized they the soft reset hardly worked.

Hell thats what all our electricians do in our s&i. Drop the pans and do a hard reset. Cant find a Siemens tech to take a download anyway!. The best is when it dumps and im Under there changing brakes

Or try to fix everything by rebooting, like a Windows administrator.

I distinctly remember arriving in NYP on a BOS to WAS trip on the Acela, and the conductor announced there would be a brief delay before passengers boarded because they were going to reboot the train.