Skip to main content

I recently had an Atlas GP lose TMCC signal and take off like a rocket. The result was one broken car, a substantial derailment of the train it rear ended, and that wreckage spilling over onto the next track.

 

That got me to thinking. Is there any way to disable conventional? Personally, I would rather just have a locomotive just sit there if it didn't have signal. What would really be neat is to be able to install a switch for CMD/CONV. That way it wouldn't be up to the engine to choose the mode.

Original Post

Replies sorted oldest to newest

Elliot, Have you seen what's called a "Palm Switch" an Emergency Stop Switch in red usually on industrial equipment?  Wire track 120V through a relay with an extra set of contacts, called latching contacts.   They sell miniature palm switches today and you space them around the layout all wired in series connected to the latching contacts.  Hit any palm switch and 120V is shut off.  We used to call these switches "Chicken Switches.  This is how I will wire power to my transformers.  

Thanks guys, the layout kill switch would be an improvement over the current arrangement of running the length of the room in panic to shut things down. However, the question was aimed more at a preventative approach, and less at a reactive one.

 

I was kind of afraid the answer to the original question was NO, but it was worth asking anyway.

Yeah John, that makes sense, because I had successfully moved it, and then it became unresponsive. That may be when it slipped into conventional but remained in neutral. Then I turned the layout off, and when I turned it back on, as you say, turbo mode.

 

This engine has always been flaky. Now I wonder if it isn't our old friend the unshielded coil. I'll have to pull the shell.

Lionel PowerMaster has a conv/cmd switch.    Right now I'm running MTH proto 2.0 and Lionel legacy locos with just a Lionel Cab-1 remote with Lionel powermaster and a MTH brick.   The HALT button on the cab-1 remote shuts the power off to the track.  Also this seems to be the cheapest way to run locos with a wireless remote.

Your setup looks like an industrial control panel! Very nice. With what you have a relay in the 120volts and some wiring would provide an Estop setup.

  I would suggest a BSR module but the are subject to interference from other users in the neighborhood. You could use one( the appliance type is good for 15 amps) and have a master switch to turn everything off when your done.

  With all the modern technology you should be able to find something you can turn on/off from your cell phone.  Don

I'm not really seeking a master kill switch here. I have one of those. The way it went down was, the layout was off and I turned it on. Because the trains are parked with only a couple of car lengths between them, if one takes off there isn't enough time to react. It's like tailgating with your car. I flipped the power off as soon as I heard it move, but it was too late.

 

The original question was not about modifying the layout, it was about modifying the engines to disable conventional operation. I.E. TMCC only.

 

Back in the days before TMCC, I wanted my trains to run forward only, because I was using relay controls to start and stop trains. The old mechanical e units were OK, but the electronic ones were problematic because, even after they were locked, they would occasionally "forget" and begin to cycle again. The ultimate solution was to remove them, and hard wire the engines to forward only.

 

This is really just a high tech version of the same issue. Somewhere on the control board has to be circuitry that detects if there is no TMCC signal. There are switches to turn odyssey and sound on or off. Why not conventional off?

Originally Posted by gunrunnerjohn:

You make a very good point Elliot, but I know of no such capability.  Perhaps asking Jon Z. or Mike Reagan about this might be instructive.

Thanks John, let's see if they spot this topic, otherwise I'll try contacting Mike. I mentioned earlier that it could be that pesky shield issue that caused the disaster in the first place.

 

If we do find out that this is possible, it just means a major project to do the conversions.

 

Maybe I just shouldn't park the trains so close to each other.

When it comes to TMCC, I do have a certain knack for the obscure and theoretical. Here's another one to try to wrap your head around. This goes back to the computer codes being published for TMCC.

 

We all know that the cab-1 can handle 100 different engine addresses, 00-99, but the codes use 8 binary digits representing 128 addresses. Clearly the cab-1 can't deal with 3 digits, but in theory, a computer connected to the command base could program and subsequently run channels 100-127.

 

I know this is a strange idea, that most normal people would never consider, but I might have a use for this in the future. Call me curious.

John, I thought of that even before I had a potential use for it. The ultimate plan for my layout is to use a computer to control mainline switches, signals and detection. Once those things are in place, the computer could be a virtual operator with full control of some trains to supplement human operators.

 

If my theory holds true, the high number channels could be used exclusively by the computer. Of course this implies that there would be over 100 locomotives on the layout. I'm still quite a way from reaching that mark, so all of this is really a moot point (for now).

 

So what kind of things are you trying to trigger with your microprocessor?

Basically, I'm just working on having a serial decoder that can recognize when various commands are being sent to the sound module via the RailSounds serial input.

 

Once I have that working, I can then use either unused stuff like front couplers on steamers, to trigger other events.  Also, it would be easy to add flashing ditch lights to diesels, as I would know when the horn was blowing.  Finally, if I wanted to add ground lights, Rule 17 lighting, or motion controlled cab lights, I can know when the throttle is at zero and trigger the appropriate outputs.

 

Those are just a few possibilities, I'm also thinking of custom sounds that could be triggered using key sequences.  If I were to break the serial line and intercept certain commands, I could do all sorts of neat things that wouldn't interfere with normal operation, any sound commands I wanted to get through I'd let them go.

OK, I remember seeing you mention a couple of those things in other topics. They sound cool, and I'm sure there are a bunch of guys who will want to use those things. I'm not really going for that kind of detail. There are so many other things I want to do first.

 

Once I get the computer thing working, I will be able to have it set routes and throw switches. It will also be able to recognize if portions of a route are being used by another train. The operator would make a request, and the computer would allow or delay the action based on track conditions. This would all be done with CMRI, JMRI and TMCC, without the use of any of the Lionel add on controllers.

 

CMRI is a hardware based system of input and output control bits. I already own a large quantity of these, so I want to reuse them. JMRI is a Java based software control system that already has a module with the TMCC codes programmed. You use a layout building module to describe your layout.

Thanks John. The CMRI technology has been around for 30+ years. I've owned the equipment for 20, as it was part of the display I had at Mall of America. That's also where my monster power supplies came from. I was always planning to use that.

 

JMRI is a more recent development, with new modules and updates coming all the time. I originally thought I would have to write my own software to control CMRI and TMCC, but after attending some clinics last year at the NMRA convention, it became clear that I didn't need to "reinvent the wheel". This will cut a lot of time off the implementation, though it may still be 5 years before I have it up and running. I have a lot of layout construction to complete first. I don't even have a working switch yet.

 

This is cutting edge for the hobby. Even in the 2 rail world, only the seriously technically inclined try this stuff. If there were more than 100 guys in the 3 rail world that had even heard of this, I would be shocked.

 

All of this background kind of brings the discussion back to the original question about turning off conventional. It would be one less thing to worry about with an end goal of glitch free operation.

Last edited by Big_Boy_4005

I wonder if the way to "turn off conventional" would be to detect the 455khz signal on the track, and if it's not detected, shut down the track power?  That would at least prevent runaways, and if the signal was always there, it wouldn't affect running.

 

Another, but far more labor intensive solution, would be to equip each locomotive with such a sensor and a relay to drop out motor drive if the signal disappears.

 

The really sad thing here is, the R2LC software could easily do this if you had access and could modify it.

Originally Posted by gunrunnerjohn:

Another, but far more labor intensive solution, would be to equip each locomotive with such a sensor and a relay to drop out motor drive if the signal disappears.

 

This is more what I was getting at. I was thinking that there is already circuitry in the engine that is detecting the 455 signal, that's how the engine decides command or conventional.

 

The logic is straight forward enough, if 455 signal then command else conventional. If that is how it really works, there might be a way hard wire the else clause to null, perhaps by inserting the switch I've been hinting at. The switch would disable that part of the circuit that chooses conventional as the backup mode.

 

The more I think about it, the more it really has to function this way, because the trains never flinch when you turn the track power and the command base on simultaneously. They wake up in dead calm mode as opposed to turbo mode.

 

If this decision is made inside a chip, it may not be possible to do.

Thanks John, this has been an interesting and informative discussion.

 

That explains a lot. Now I get it. That makes your on board sensor and relay idea sound like the way to go. Then it's just a matter of building it and fitting it in. No easy task.

 

I'm afraid the layoutwide version wouldn't be as useful, because it wouldn't prevent the single bad actor. It would stop a mass runaway on startup, basically detecting command base failure. This would help with my previously mentioned Legacy problem (which I still haven't taken the time to figure out).

 

Post
×
×
×
×
Link copied to your clipboard.
×
×