Runaway MTH engines

Given multiple locomotives are suddenly taking off, I'd start thinking of issues with the DCS signal to those locomotives and tracks.  In conventional mode, a power interruption will switch from neutral to forward, and with full voltage on the tracks, you have a drag race.

During the 2 seconds of sheer panic before you killed power did you happen to notice if the lights and/or sounds of the runaway engines were on?

I'm speculating the engines reverted to conventional mode due to an intermittent track power loss.  You wouldn't have seen or heard this since the engines were shutdown in command mode to begin with.  Then when power was restored, the engine would start in conventional mode and the same intermittent track power condition might have put the engine into conventional Forward at full track voltage (with lights and sounds ON).

But if the engines each took off dark and silent, then GRJ's point about some kind of DCS command signal issuing saying to "go" makes sense.  That is, this would be that so-called "stealth" mode where you can move an engine without starting it up.

Actually Stan, I was speculating that he was dropping into conventional mode as you suggest.  That seems to be the most plausible explanation.  If the DCS channel doesn't see the power cycle, you don't get the watchdog signal and you are in conventional mode.

I'd bet money that this is not a DCS issue but is rather a power/track issue.

Barry, I think we're all in agreement here.  Three engines doing it seems a bit too coincidental.   A couple of power glitches and they could do what he describes.

I just did a test with a switchable siding.  After sitting there for a spell, one power cycle brings it up in conventional mode as expected.  The second one and it moves out forward, also what we expected.

I think this is by far the most likely scenario.

Trying to read between the lines of Galon's original post, he makes careful note that the batteries of each engine appear to be in order.   IF he is getting intermittent power interruptions (putting the engines into conventional) these must be interruptions of many seconds...and not just "glitches".   And it happens in more than one location.

I don't know if such a widget exists for train layouts, but this reminds me of those refrigerator/freezer alarms which sound a buzzer when power goes out.

It could be that Galon is getting many unwanted power interruptions (loose wire, flakey siding switch, whatever) but most are short enough to be masked by the battery with the engine remaining shutdown and in command mode.  So a simple widget that immediately sounds an audible alarm when power is lost might be useful to track this down.

You need a dropout of power for a few seconds for the switch to conventional, that is true.  Any succeeding power interruptions to get the engine moving can be brief.

I tested, and a 10 second power interruption when they are dark brings them in conventional mode, than a brief interruption first them off in forward at full speed.

Stan,

IF he is getting intermittent power interruptions (putting the engines into conventional) these must be interruptions of many seconds...and not just "glitches". 

If an engine comes up in conventional mode initially, it only requires a second for a power outage to change direction from neutral to conventional.

The engine's battery is required to change direction under conventional control. If the batteries weren't in decent shape, the engines wouldn't take off at all.

16 seconds seems a long time for sounds to continue.

If there is a brief spark from a short on the layout, strange things sometimes happen.  DO these events occur when some other loco is running in a particular spot on the layout?

To avoid this problem completely I park any non-operated DCS controlled engines on a non-powered siding. I also have wired and wireless remote power disconnect pushbuttons on my layout to remove power to all tracks if necessary in an emergency.

To avoid this problem , take DCS and give all of it to the Goodwill , in my opinion , a completely over designed headache festival

unless of course you are a computer science and electrical engineer , as well as Windows systems master certification. But if you want to use it ,

Then take and put light bulbs on all track blocks with the star wiring , so you get the Xmas tree feel all year long .

Nice system when you have to use 100 year old technology (light bulbs) to make it work.

But then again they probably designed it this way so your locos fly off the layout so you have to buy new ones.

Galon, are you absolutely certain that all locos have same ID numbers in every remote?  

Some years ago, I had a loco with an ID ending in same digit as another, that would occasionally start when the 2nd loco was operated.  Changed ID of the first and problem never recurred.  Never figured out the cause.

Occasionally a layout will have a quick short, that makes a spark but ends too quick to pop a breaker, like when a wheel very quickly brushes center rail.  This starts locos in conventional on powered tracks all over the layout.

Prohobby, unless you wire in passive mode, the red button on the remote does this.  It's great whenyoungsters are running the layout.

Galon,

Any thing I should check?

It appears that, thus far, you've been unable to duplicate the event.

I suspect either operator error or a power problem. The issue is way too bizarre to be related to DCS. DCS is incapable of issuing commands by itself, other than via a Record/Playback session that the operator initiates.

If this happens again, knowing more about what is going on at the time would be very useful.

If the sounds are on when the locomotive takes off, it sure sounds like it's in conventional mode.  Exactly how it gets into that state remains somewhat of a mystery.

This may be one of those mysteries that has to be examined up close to determine the cause.

I have never studied computer science.

I am neither electrical engineer nor electrician.

I have no computer certifications.

I do not have star wiring.

I have never had a train fall onto the floor.

But these woeful deficiencies do not stop me from running DCS.

I do recall the following letter in a model RR magazine from many years ago:

"I recently was given one of the new Lionel locomotives, a 226E, that has one of these newfangled so-called 'E-units.'  This is terrible.  It constantly has a loud annoying buzz.  It sometimes would not make proper contact on that silly rotating drum, so one needs a master mechanic to repair it.  We should stick with the reliable method, a lever on the locomotive to make it reverse."

GRJ, if a running train has an axle off the track, there will be occasional sparking as contact makes and breaks.  This can start another loco (shut down on a powered track) in conventional.  A further brief short could trigger the second loco to start.  All this is "could."

Sounds like there are a lot of operators.  That makes uniformity of ID numbers a likely suspect also.

Yep, when we do club functions, I take a couple of MTH remotes and do a factory reset on them.  I assign a group of ID numbers to specific folks, when we program the engine, we change it's ID to one in their group.  This hopefully prevents most duplicate ID issues.

I think the distinction between a long (many seconds) drop out and a shorter "glitch"...and how this affects DCS engines is the key clue.  Since it appears you have a busy layout with multiple operators and general commotion, I suggest some method of detecting ANY voltage dropouts.  Then, you don't have to baby-sit and when the "alarm" goes off you can correlate it to what someone just did. 

As stated earlier, IF you are getting drop outs I believe you are getting both long and short ones.  That is, if you were ONLY getting long ones then the first would place the engine into conventional and subsequent ones would do the same.  You would never take off.  If you were ONLY getting short ones then the battery would mask these and the engine would stay dark/silent in command.  Of course you'd want to track these down too which an alarm widget would detect.  So it must be a long followed by a short.  Apparently these take-offs are difficult to duplicate so that's why I'm suggesting some kind of detector so you can spend your time running trains and let technology do the baby-sitting.  If this is something you'd like to pursue we can get into the mechanics of what might work as a detector but I'd think it would cost only a few dollars.

One of the gurus would know for sure but I believe you can program an engine to be locked in neutral when in conventional mode (using a sequence of Whistle-Bell button presses).  And more importantly this setting is retained even if operating in command.  So if you are operating in command and the engine reverts to conventional due to a long dropout, then any subsequent short dropout will only cycle the engine between Neutral and Neutral and it won't take off.  This may be more trouble than it's worth but just an idea...

Using house wiring for a radio antenna goes back to the mid 1930's.

DCC the most popular form of Command Control uses both lights & snubber filters..hmm??

I think the idea of locking it in neutral is very inspired, I didn't think of that!

That would certainly preclude them taking off in conventional mode!

    RJR Yes all locos have same id in each remote. All TIU's and Remotes got a factory reset in August before hosting a NMRA division meet. All TIU factory reset and reconfigured to #2,#3 and #4 all outputs on and all channels fixed with single remote. All remotes factory reset , numbered to what I have painted on back (1-8) added TIU 2,3,4, set to super, turned off quick set speed and adjusted the power down to 15 min. All engines added to a single remote and cloned.

Stan 2004 I willing to give a shot how do I build this detector? I like the idea of locking it in neutral how do I do this? Same friend is coming over tonight gona give him same engines and remote and leave the three engines powered on the track where they took off from Thursday.

Hopefully I will have something to report later

Galon Tonell  

Galon, I was able to replicate your problem on my layout this evening.  I was running a train over a switch and for some reason that I haven't yet figured out, as each truck went over the switch it brushed the center rail creating a brief spark.  One of the sparks caused many engines on the layout to start up, and judging from the sound they started in conventional.  The next spark caused one of the engines that had started up to move forward.

I would suggest that you take careful note of what trains are running and where on the layout, and see if your unwanted startups recur under a certain combination.

Meanwhile, the easiest way to preclude a startup is to park locos not being used on a toggle-switch controlled track.

     Stan 2004 and group: Trainmaster ran away tonight NO LIGHTS , NO SOUND, either close to or at max speed. I did not think to check if it was going forward or reverse when I plucked it from track.

Unable to repeat despite trying for half hour.

Conditions ; three runaways parked powered, at location they took off from Thursday. My friend had the switchers at the location of the last runaway Thursday and ran the lead one onto a dead siding right before this happened, this being on the Lionel brick witch doesn't trip right ,on its own TIU.

I had a train powered by MTH Sharks coming out of the staging loop where the 2-10-4 is parked. It repeatedly tripped the breaker, tracked down to a caboose roller being forced against the brass tab across the axles, on a switch. Power was cycled repeatedly on this brick in the proceeding 5 minutes before the incident tracking down the short. I don't remember if power on or off when trainmaster made its appearance.  The 2-8-8-2 on this TIU ,separate brick stayed dark and silent the bricks and TIU in this room are on there own house circuit.

Trainmaster on 3 rd TIU sitting powered dark and silent on a Lionel brick on a seperate TIU brick and house circuit .  black outputs of two TIU all tied together for TMCC but not the problem Brick and TIU

Made sure all three engines came up in conventional with sound and lights before we started

RJR Were all of your engines on the same transformer? Same TIU? Trying your second suggestion right now. As for parking all unused locos on unpowered track or locking in neutral that only cures the symptom not the cause ,I really like to know what causes this. I try to keep the power off in the staging loops.

GalonTonell

On different transformers.  Same TIU.

Galon,

I really like to know what causes this.

With all of the sparking & shorting mayhem your club is causing, how can you believe that it's possibly not a power problem?

This sounds like a pretty unique happening, it's very hard for me to believe that you can lay this at the doorstep of MTH.  I must admit, I agree with the comments that you should park stuff on unpowered sidings until you're ready to run them, it'll prevent this kind of happening.  Another reason is the hour counter continues to run whenever there is power on the locomotive.

This is interesting because the first engine I ever purchased was an MTH BNSF Diesel. It almost always did the runaway thing when I powered on, until after reading Barry's book (thoroughly), I realized I wasn't powering up the TIU on a separate power supply, I "assumed" track transformer power was all it needed. My error. Since I powered the TIU correctly, that engine has never runaway again. I did have to send it to MTH for repair, cause it hit the floor and broke something. They repaired it and the packing list referred to some small board replacement. I have no clue what that was.

I'm probably waaay off track here, but thought I'd at least offer my experience.

George (G3)

Good observation.  So in this case it appears the engine was still in command mode and received a phantom DCS speed command or inexplicable unintended acceleration. 

What does this mean? This also was mentioned in your original post in example 2.  That is, what is the purpose of driving an engine into an unpowered power district?  Seems all this does is create weird power transitions as multi-trucked engines straddle the power and unpowered districts

IMO you/we need to be careful about assuming RTR's and your situations are the same.  So far his seems to be a case of reverting to conventional operation in response to a short-term power anomaly (spark).  As of now I interpret your situation is one of unintended speed (creeping or high-speed) while in command.

So at this time I don't think you are receiving track voltage dropouts so a dropout alarm is probably not worth the effort.  That said, we are dealing with undefined behaviors (vs. long-short voltage dropouts going into conventional and then Fwd at full track voltage which IS a defined behavior).  Frankly, unless someone else steps forward with a silver bullet or you just can't let it go, it seems masking the problem or reducing the likelihood is the practical way forward.  There's consensus on using toggle switches to sidings/staging areas when possible. Some other things to try include confirming you're getting good DCS signals (all 9's or 10's) into these problematic blocks, perhaps adding a TVS across the rails in the problematic blocks, perhaps adding a light-bulb to each of these blocks to serve as a visual indicator of power or lack thereof.  It also can't hurt to lock problematic engines in conventional neutral; you asked earlier about how to do this; this is from a PS2 engine manual:

Stan,

So in this case it appears the engine was still in command mode and received  a phantom DCS speed command or inexplicable unintended acceleration.

That's not necessarily the case at all.

A DCS engine's processor can, due to sudden voltage surges (caused by derailments, etc.), go into an undefined state causing the engine to simply take off without any change in the attendant state of its lights or sounds.

This is a power problem. DCS TIUs and remotes don't just issue commands spontaneously all by themselves.

By phantom I mean something that seems real but does not exist - or that's my definition of a phantom.  I'm not saying the TIU/remote sent a command to accelerate but the engine is interpreting some external event (spark, surge whatever) as equivalent to a command to "go".  Whether this manifests itself as a phantom DCS command or as some "undefined state" as you call it is semantic gymnastics. 

The end result is the processor believes it should be moving.  What I find interesting is when the engine enters the creep mode.  My interpretation of that is the processor is still alive and well since it takes processing to perform slow speed control with tachometer feedback.  If the engines ONLY took off at full speed I could attribute it to a runaway processor in an undefined state.  I don't think we'll know which it is for Galon without access to more sophisticated diagnostic techniques.  

Thus, I suggest his way forward is to minimize the likelihood of phantom commands by isolating the engine from these surges, sparks, etc.. 

What about the sound told you they started in conventional (vs. started in command due to a phantom DCS startup command)? 

For example, are the conventional-mode volume adjustment controls on these engines set low (whereas command-mode volumes are 100%) so it was the low volume that told you the engines were starting up in conventional?

Also, since it appears you have some experience with this...and was able to re-create it with apparent ease...what steps (aside from toggle switches) have you taken to minimize the phenomenon?

The volume control setting on the locomotive would determine if you had sound in conventional mode.  Since it's not active in command mode, you might never know it's fully turned down.

Not sure where you're going with this?  I'm thinking the volume of the sound is a simple (and perhaps only?) indicator of whether the engine started up in conventional or in command.  This assumes the two levels are set to allow differentiation.

Stan, my conventional volumes are set higher, precisely to alert me to a conventional startup.

I've done nothing to minimize problem.  Rarely get a second spark.  Most common cause is rerailing an axle.

I'm just saying that the volume control on the engine only affects conventional mode.  I don't know where he has his set.

I don't know if this is common knowledge but that's pretty clever that it's your SOP - and more importantly easy for any command user to implement.  Hopefully this will archive and become easily searchable to help others rationalize this confounding behavior.

       Stan 2004 :...ran the lead one onto a dead siding right before this happened. It means he had 2 switchers mu's (lashed up) It's a single track main railroad with passing sidings for it to operate right they need to be powered all the time. None of the industrial spurs are powered ( I should have said spur above instead of siding) more than an engine length or two 2 as a safety precaution. A switch can't be left open and an engine drive off the railroad onto the floor. He left the switch open and later unintentional went in there. Also when one creeps it could be an operator error roll to 1 or 2 right before laying remote down or selecting another engine hopefully Barry will know one way or other

     Barry : Thank You for the explanation of the cause

A DCS engine's processor can, due to sudden voltage surges (caused by derailments, etc.), go into an undefined state causing the engine to simply take off without any change in the attendant state of its lights or sounds.

This poses several questions 1: Does explanation cover creeping? 2: Can it happen in both forward and reverse? 3:Is there an electrical component that can be installed to stop this from happing when a sudden voltage event occurs? 4: does the voltage surge travel to the other engine back through the outer rails, or through center rail, TIU, transformers, and house wiring or you don't know ? 5: Will locking it in neutral as some suggested keep it from taking off in this state?

      Barry: Have I offended you somehow?? You seem to have known all about the problem and exactly what cases it. Yet you kept telling me it was a power problem and not a DCS problem when in fact the power spike is the trigger and real cause is the processor inside the engine going into an undefined state causing the locomotive to take off

Galon,

I really like to know what causes this.

With all of the sparking & shorting mayhem your club is causing, how can you believe that it's possibly not a power problem?

How can youclaim it's not a DCS problem Barry?

     Gunrunnerjohn ; If you read back through the post's I made I never once suggested or implied this problem be laid at MTH's or any one else's doorstep,  I also I never stated or implied that any TIU, remote,or DCS System was somehow responsible. I strongly suspected a short was one component necessary to cause this for a long time but it was very random I could could never make it repeat. I really like the MTH DCS system, engines, track, and switches.

  Do you by any chance know the answer to question 3 or 4 above?

Thank you, everyone who helped with this problem

Galon Tonell

Galon,

Have I offended you somehow??

Not, I'm not at all offended.

 You seem to have known all about the problem and exactly what cases it. Yet you kept telling me it was a power problem and not a DCS problem when in fact the power spike is the trigger and real cause is the processor inside the engine going into an undefined state causing the locomotive to take off

How can youclaim it's not a DCS problem Barry?

Because it's not a DCS problem. Period.

DCS is not misbehaving, rather, the layout is throwing short circuits and the engine processors are reacting to them. The root cause is a power problem.

GRJ:

"This sounds like a pretty unique happening, it's very hard for me to believe that you can lay this at the doorstep of MTH.  I must admit, I agree with the comments that you should park stuff on unpowered sidings until you're ready to run them, it'll prevent this kind of happening.  Another reason is the hour counter continues to run whenever there is power on the locomotive."

Have had this problem with three different engines (all PS3 but diffent IDs and numbers) parked on unpowered sidings.  The engines suddenly take off at full speed when the toggle switch is thrown to power up the siding.  The problem is unclear since the engine moved onto the siding evenly and then shut down properly before the power to the siding was turned off.  Our club has several sidings we use to switch engines as we run all day long.  We uncouple the engine to be changed while on the main track, pull it off on one siding, shut the engine down and turn power off to that siding by means of a toggle switch, and then power up the second line and engine to pull the new engine out onto the main track so it can take over running the train.  We have 4 different track lines, each with its own TIU.  This is happening on only one of the lines.