Block Control of Legacy Engines

Well, the catch22.

You have the sensors- but you don't have "the logic". You explicitly want a logic that says if "an engine" is in a block, then "another engine" cannot enter that block. The problem is each engine is an individual address and not only does the "logic" have to know what engine is what, it has to send out individual commands to do so. Lionel to date has very simplified commands such that a sequence is followed for a specific engine. Example the sensor will perform an entire sequence, but for that engine only when it crosses the sensor.

What you need- a computer or microcontroller- polling the serial data chain of the base and sensors, to implement a more complicated logic process where it knows what all engines by ID are on the track or loop, what engine is in a given block by the sensor, and where the trailing engine is behind it- potentially wanting to enter that block and then send the command to that trailing engine.

It's theoretically possible- but again, requires a much more complicated setup and potentially additional equipment.

I know there are some 3rd party apps and maybe even open source ones? capable of controlling Lionel TMCC/Legacy and integrating into LCS and sensors- but  unsure what is the best app and if any yet go to this level of complication.

Pennsy Johnnie,

I've had blocks on both my layouts.  Basically my current layout is made up of 5 blocks.  You need to be able to keep some power at the engine to keep it on, otherwise it shuts down an then does not power back up.   I think my signals supply that limited power.  I don't really use the blocks so much anymore for multi train operation, rather more interested in making sure there hasn't been a user error in leaving cars on the track and forgetting about them or the errant coupler misfire.

FWIW, I myself had considered just such advanced control software or other microcontroller solution for some of my mixed trains. By mixed, I mean Legacy and TMCC. Example, the sensor track natively when you do a recorded sequence only sends out Legacy flavored commands. So great, say I run a Legacy engine but a TMCC only sound car (stationsounds diner). Again, the catch 22, I could record a simple sequence to stop the train just after passing the sensor at the station, but because the sound car was TMCC, the LCS sensor track sequence function only sent Legacy flavor commands not understood by the TMCC only car.

So I was thinking a simply lookup table of a microcontroller on the PDI serial data bus, that saw the Legacy commands for sound, and repeated a TMCC flavored command (most likely with specific engine and car addresses and sequences).

So yes, I fully understand the desire, and have some idea of how one might go implementing it- but haven't yet had that kind of "spare time".

Lionel built a great framework with LCS, sensors, and Legacy and even older TMCC. That said, there seems to be opportunity within the market for someone to build software that can implement this level of "If- Then" logic (probably need all the common logic scenarios- AND, OR, NOR too).

Again, we know from Legacy monitoring software the data and commands sent and received rounding that serial data bus, and it in theory should be possible to take events from the sensor track- or maybe even other inputs- and send commands on the same bus when events happen.

Great info, and I really appreciate the detailed reply!  I agree that there's a market for something like this, and the technology is already there with the LCS sensors and the serial bus.  I just wanted to be sure that I'm not overlooking anything "obvious" and it appears that I'm not!

Great Question?, I can see this being a rather simple fix in Conventional control with engine’s having their E units fixed in the forward position and utilizing a Lionel station with the proper stop and go switches. The issue as I see it is the TMCC/Legacy controlled engines are always set to go forward when initially turned on. Therefore, if the engine goes into a non powered block, it will stop. When the block is powered up it will sit still until a command is given that engine again and will go forward. So, I’m thinking this is a hard question to answer. I would let both trains run Simultaneously both set at the same speed…. Good luck, keep us informed. Happy Railroading Everyone

Also, oddly enough, if you go back in time in Lionel and look at the "TMCC Action Recorder" series of devices http://www.lionel.com/products...roller-arc-6-14181/- They did have more of a mechanical/electrical sensor inputs and then could send TMCC commands and sequences. Again, the catch22 is, you have individual engines, with individual addresses. Even if you used the all engine command 99, well then all engines would stop in your block sequencing scenario.

I'm just saying, throughout the history of Lionel Command Control, they have made some fairly advanced devices. It's kind of interesting to me that the TMCC ARC almost in a way does things the current sensor track cannot do, but then the sensor track also can identify and know what exact Legacy engine crossed and send a complicated legacy sequence back out, but may not in my experience do much of anything for TMCC.

TMCC ARC- can send TMCC flavor commands- and triggered by inputs that only sense "something" triggered- not ID what triggered

LCS Sensor - Can send Legacy flavored commands-*to my knowledge cannot send TMCC*- and triggered by LCS Legacy engines equipped with IR transmitter only.

Using a combination of both devices, in theory gives better overlapping TMCC and Legacy sequence capabilities- although I have not yet implemented or tried this (just added another to-do item).

Bottom line, this also won't do what you exactly want, but is semi related and might solve potentially other related ideas or sequences specific to TMCC.

@leapinlarry posted:

Great Question?, I can see this being a rather simple fix in Conventional control with engine’s having their E units fixed in the forward position and utilizing a Lionel station with the proper stop and go switches. The issue as I see it is the TMCC/Legacy controlled engines are always set to go forward when initially turned on. Therefore, if the engine goes into a non powered block, it will stop. When the block is powered up it will sit still until a command is given that engine again and will go forward. So, I’m thinking this is a hard question to answer. I would let both trains run Simultaneously both set at the same speed…. Good luck, keep us informed. Happy Railroading Everyone

Interesting discussion.

I run purely conventional, but ran into a somewhat analogous problem trying to replicate a Marx "Twin Train" setup, with two consists running on a single figure-8 track using a primitive block control system. The problem I ran into was that, when the second engine entered the depowered stop section, the E-unit would cycle (the Marx E-units on my engines cannot be manually locked out, unlike many Lionel units) and cause the engine to reverse direction when power was restored.

To stop this from happening, I ended up feeding a trickle voltage (through four 10 ohm, 10 watt power resisters hooked in parallel) to the stop section, which was enough to keep the E-unit immobilized yet prevent the engine from moving forward until power is fully restored. You may be able to do something similar, using the trickle to keep the control system from reverting to a full stop while cutting enough power to prevent the engine from moving forward. Good luck, and hope you can work it out!

@leapinlarry posted:

I’m thinking this is a hard question to answer. I would let both trains run Simultaneously both set at the same speed…

Larry,

This isn't about having two trains running simultaneously because they're set at exactly the same speed and thus never get close to each other.  That's relatively easy to do, at least for some minimal amount of time.

In reality though they will never be precisely at the same speed.  At some point one will overtake the other.  The O.P. is specifically looking for the ability to temporarily slow or stop the one of them that is going fastest to avoid a collision.

As someone's already pointed out, in command mode this requires the ability to monitor the relative position of both and send a slow down command (equivalent to a rotate the handheld's red knob CCW a little bit), for slowing, or a stop command, for stopping, automatically.

Also as others have pointed out, the control part is fairly straightforward with a computer that has a serial connection to the command base (for issuing the commands).  The relative position is the hard part.  Knowing where each train is and when they are likely to get too close to each other (meaning sensing the position, speed and acceleration of both in real time) is not easy.

You might be able to measure speed for each using the sensor tracks, but probably not acceleration (at least not terribly accurately), and definitely not position accurately (although you'll certainly know when one of them crosses a sensor track you don't know precisely where they are when in between).

I think that it could be done by estimating the required position, speed and acceleration from data received as the trains cross over the sensor tracks, as long as the layout has enough of them, and they are positioned satisfactorily.

@Pennsy Johnnie posted:

I agree that there's a market for something like this, and the technology is already there with the LCS sensors and the serial bus.

Johnnie,

Is there really a market for this?  In following the OGR Forum for the last eight years this topic, and the fundamentals behind it, have come up about twice a year as far as I can see.  From this I would say no.

But, is this one of those things that most people don't know they need until they see it in operation, then after seeing it absolutely have to have it?  It may indeed be.

We'll have to stay tuned to see what happens ...

Mike

Also, I feel like I should add an important detail regarding modern recent legacy and Conventional Control (varying track voltage). Recent Legacy and LCP2.0 engines (talking mainly 2022-2023) using the newer all in one board LCP2 LCP3 series, maybe even newer, does NOT like varying voltage when trying to maintain a commanded speed. Should the voltage trip the stalled drive motor sequence (motor cannot maintain or reach commanded RPM due to source voltage) the engine shuts down and locks out until power cycled. There are differences in how the firmware handles this between different series of Legacy and TMCC electronics.

I'm just saying, those conventional techniques (example "holding voltage" to keep unit in a direction) that might be fine with a lot of other engines- there are certain newer Lionel engines that this would result in a whole lot of cab light flashing and motor lockout sequences in certain conditions playing with track voltage.

We (the forum and posts) have seen recent examples where reverse lockout did not work and was not reliable under conventional operation.

We've seen instances of engines stopping and stalling- sometimes with or without cab blink error sequences.

"Spare time", more specifically lack thereof, keeps me from publishing a project that reads Legacy/TMCC commands plus the LCS bus packets such as SensorTrack events and transmits commands based on configurable logic.  I considered an "If This Then That" approach to automating a multi-train loop to replicate traditional block control based on SensorTrack events, but as I tunnel into "what could go wrong" scenarios, I can't get past the inevitable train wreck using Lionel's current offerings in the LCS space.  With the Base3 having three PDI bus inputs, I'm hoping Lionel will come out with some new LCS products to support automation.

To start, a Sensor Car, or kit (set of trucks) to instrument more than just locomotives is highly desirable.  The original Sensor Car uses TMCC programming to configure the address that the IR sensor spits out as it crosses the SensorTrack.  This offers flexibility, but Lionel has not manufactured more Sensor Cars.  Time for a 3rd party solution with a simple approach.  If a tender or other car is retrofitted with an IR transmitter, it needs to be programmed with an address once.  The variable engine data and diagnostics transmitted by a sensor-equipped engine can be static for a sensor-equipped car.  An Arduino, PIC, or similar board could provide a serial/USB interface for initial address programming.  Once that is done, the  USB is unplugged, the car reassembled, and then can provide position information to Sensor Tracks.  Installing an IR transmitter in tenders, cabooses and end-of-train cars would by my first application.

A lower cost SensorTrack Lite that provides only position and direction events is desirable.

Extending LCS device addressing to 4 digits is desirable.

@Vernon Barry posted:

Also, I feel like I should add an important detail regarding modern recent legacy and Conventional Control (varying track voltage). Recent Legacy and LCP2.0 engines (talking mainly 2022-2023) using the newer all in one board LCP2 LCP3 series, maybe even newer, does NOT like varying voltage when trying to maintain a commanded speed. Should the voltage trip the stalled drive motor sequence (motor cannot maintain or reach commanded RPM due to source voltage) the engine shuts down and locks out until power cycled. There are differences in how the firmware handles this between different series of Legacy and TMCC electronics.

I'm just saying, those conventional techniques (example "holding voltage" to keep unit in a direction) that might be fine with a lot of other engines- there are certain newer Lionel engines that this would result in a whole lot of cab light flashing and motor lockout sequences in certain conditions playing with track voltage.

We (the forum and posts) have seen recent examples where reverse lockout did not work and was not reliable under conventional operation.

We've seen instances of engines stopping and stalling- sometimes with or without cab blink error sequences.

Fair enough, and all good points. It sounds like, for some rolling stock, a "conventional" block control solution (see what I did there? ) will not work with some modern engines, so my suggestion would be either to not run those engines on a loop equipped like I had suggested, or at least be able to disable the "trickle" voltage if you wish to use such engines. Or, come up with a better solution . . .

Wow, a lot of great info on this thread.

I agree wholeheartedly that Lionel needs to step up its development of LCS.  The concept is so promising (and I love the iPad-based turnout control panel!)  But I've yet to see a killer demo of what it really can do.  They need to re-engage with Neil Young and the more imaginative folks who were involved in the past.  I'm hopeful, but my patience is starting to run out.  The scarcity of sensor cars, etc., makes me wonder how committed Lionel is to LCS for the long-term.

The only other protocol I'm aware of of like LCS is JMRI (Bruce Chubb's Java Model Railroad Interface.)  I think JMRI can support TMCC events, but I've not dug too deeply into it.  I hoped that LCS would be more capable and mature by the time I had enough space and time to build a layout.  Tick tock, tick tock!!

I jumped into LCS with both feet, but I'm disappointed in the fact that it stalled and there hasn't been any development in years.  Add to that the fact they discontinued the IRV2 sensor track option for non-Lionel track and for many of us the utility went way down.  They still have the IR Transmitter for LCS, but you apparently have to suffer Fastrack to use it.

Automated block control with conventional power control of the locos is a basic electrical question which has been addressed successfully by a number of modelers including myself. Any form of R/C controlled operation creates a completely new set of technical issues. This is a reason to maintain your conventional control setup (which is my recommendation) regardless of what command or R/C system you also employ.

I just want to know what Legacy and TMCC signals taste like

@EscapeRocks posted:

I just want to know what Legacy and TMCC signals taste like

Chew on this for a bit https://ogrforum.ogaugerr.com/...c/171907990247902279

Glad to see my post provided a lot of thought-provoking dialogue, and it sounds like some of you can appreciate what I’m trying to do, but as GRJ stated, Lionel LCS development has stagnated, so hopefully some 3rd party developers will seize the opportunity. For context on my specific situation, I’m not trying to just run 2 trains at the same speed around the layout. Odyssey speed control does a pretty good job of that, albeit not infinitely. Rather, I run a passenger train and a freight on the same isolated loop in my layout. The passenger obviously is set to go quicker, but each time it goes around, I have an IR sensor track programmed to have it stop at a passenger station, then have programmed a sequence of passenger arrival and departure announcements from my RS dining car. Then, the train gets underway after approximately 45 seconds. That effectively slows it down on each trip around the layout, so it doesn’t rear-end the freight. It works flawlessly for around 10 laps, but the freight sometimes comes dangerously close to catching up, and I’m trying to prevent a rail disaster from happening. That was the impetuous of my question, but I guess that’s what the halt button on our Legacy remotes are for!

Thanks again for all the great feedback that you guys provided, and let’s keep stretching the imaginations to keep this hobby alive and we’ll (and interesting)!

@Pennsy Johnnie posted:

Glad to see my post provided a lot of thought-provoking dialogue, and it sounds like some of you can appreciate what I’m trying to do, but as GRJ stated, Lionel LCS development has stagnated, so hopefully some 3rd party developers will seize the opportunity. For context on my specific situation, I’m not trying to just run 2 trains at the same speed around the layout. Odyssey speed control does a pretty good job of that, albeit not infinitely. Rather, I run a passenger train and a freight on the same isolated loop in my layout. The passenger obviously is set to go quicker, but each time it goes around, I have an IR sensor track programmed to have it stop at a passenger station, then have programmed a sequence of passenger arrival and departure announcements from my RS dining car. Then, the train gets underway after approximately 45 seconds. That effectively slows it down on each trip around the layout, so it doesn’t rear-end the freight. It works flawlessly for around 10 laps, but the freight sometimes comes dangerously close to catching up, and I’m trying to prevent a rail disaster from happening. That was the impetuous of my question, but I guess that’s what the halt button on our Legacy remotes are for!

Thanks again for all the great feedback that you guys provided, and let’s keep stretching the imaginations to keep this hobby alive and we’ll (and interesting)!

Waaaay outside any area of expertise I might claim, but ISTM one simple solution might be to eliminate or shorten one of the "departure announcements" you've set up to delay the station departure, thus affording the freight consist less time to catch up to the passenger train at the station. Or, you may be able to tweak the relative speeds to achieve the same end.

In any event, whether it's 10 laps or 100, the time will come when the spacing will no longer be sufficient, so ultimately some form of workable block control system will be helpful. Good luck in your quest!

@gunrunnerjohn is it possible to "dig" the sensor out of the Fastrack section and install it between the ties of Ross or Atlas track?  Agree that Fastrack wouldn't be my first choice for a permanent layout.  Also, what is the "IR transmitter," I'm not familiar with that.  (If you are thinking of the 153ir accessory activation device, I believe that can be made to work with any type of track.)  Thanks!

@Ted S posted:

@gunrunnerjohn is it possible to "dig" the sensor out of the Fastrack section and install it between the ties of Ross or Atlas track?

Also, what is the "IR transmitter," I'm not familiar with that.

The IR transmitter is on the bottom of Legacy locos equipped with it. TMCC models did not have it. It is blinking and transmitting the data specific to that engine. Again, the purpose of this infrared LED is identify and provide detailed legacy information to the rest of the system specific to that engine. It's not "just" an LED, it's also the data it's sending.

Example diesel engine with it in the fuel tank speaker location

This is an example on a Legacy steam tender- attached to the truck facing downward

No, you are not likely to dig out the sensor out of sensor track. Also, the price ($75)makes that really costly for just one sensor location. That was the reason why the LCS sensor track module and individual sensors up to 4 per module was much, much cheaper per sensor.

https://www.lionelsupport.com/PCB-LCS-SENSOR-TRACK

You need the entire PCB and the required LEDs for indicators and accessible buttons. That PCB is much larger and wider in the sensortrack version- compared to the narrow IRV2 sensor.

Compared to the dedicated IRV2 separate sensor for use with other tracks- a specific narrow PCB with plastic cover (to prevent sliding shoes and other things like pickup rollers from shorting to the PCB as well.

Again on the why and economics of the sensor track.

The IRV2 LCS module comes with 2 sensors for 2 tracks and one module supports 4 sensors total- MSRP was $99.

http://www.lionel.com/products...rack-2-irv2-6-85296/

The IRV2 sensors were sold as an add-on for $29 each http://www.lionel.com/products...nsor-add-on-6-85383/

So in theory, 4 sensors or 4 tracks or locations plus IRV2 LCS module was $99 + $29 + $29 = $157 MSRP

If just buying the bare sensor track PCB from Lionel parts at $75 each (which won't fit in the same way) 4 X$75 = $300 But also this solution needs more PDI cables too- so even more expense.

LCS Fastrack sensor - again, ouch $75 PCB https://www.lionelsupport.com/PCB-LCS-SENSOR-TRACK

Of course it is easily possible to “dig” the electronics out of an O gauge FasTrack section. How do you think us forgotten and overlooked S gaugers made sensor tracks for our Legacy engines long before there was an IRV2?

Here are pictures of one of mine. There are three on the layout, this was done way back in 2016. Back then the only choice was to buy the FasTrack Sensor track and extract the electronics, cost was not a factor.

@Ted S posted:

@gunrunnerjohn is it possible to "dig" the sensor out of the Fastrack section and install it between the ties of Ross or Atlas track?  Agree that Fastrack wouldn't be my first choice for a permanent layout.  Also, what is the "IR transmitter," I'm not familiar with that.  (If you are thinking of the 153ir accessory activation device, I believe that can be made to work with any type of track.)  Thanks!

We did that at Harry's house once.  Actually, what we did was remove the rails and embed the base and sensor in a ballasted Atlas track installation.  Once it was painted and disguised, it fit right in.

@Vernon Barry posted:

So great, say I run a Legacy engine but a TMCC only sound car (stationsounds diner). Again, the catch 22, I could record a simple sequence to stop the train just after passing the sensor at the station, but because the sound car was TMCC, the LCS sensor track sequence function only sent Legacy flavor commands not understood by the TMCC only car.

I'll have to try this.  It's been a long while since I used the Sensor Track in a recording with a TMCC unit but I could have sworn I had a recording operate both Legacy and TMCC engines in the same recording.  Again this was a long time ago so granted I may be mistaken.

@Vernon Barry posted:

Chew on this for a bit https://ogrforum.ogaugerr.com/...c/171907990247902279

Yeah I've been down that path.  I was just joking around since you used "TMCC flavored," and," Legacy Flavored" in your prior posts in this thread