Python code to issue TMCC, Legacy, and PDI Commands

I'm now able to send TMCC commands directly to the Base3 via wifi (not via the LCS Ser2). Although this is good (), it is tempered by not all TMCC commands are echoed out from the base. It may be possible to query the base for detailed engine state info (is the bell ringing?; is the engine started up?), it may be a lot easier to read the state info as the stream of TMCC commands available via the Ser2.

I may focus for the time being on reading from the Base 3 only the state information I'm most interested in for managing control panel state. This includes switch positions, accessory state, and power district state. But I now have in place the some of the architecture I'll need to perform bidirectional communication with a Base 3.

  -- Dave

I ran into an interesting situation today while coding up my PDI packet parser for the ASC2.  In TMCC land (via the LCS Ser2), accessory commands focus on the Aux 1 and Aux 2 buttons on the Cab2 controller. This makes it very easy to understand which button was pressed. That said, it is Not at all clear, whether buttons are being used to control a momentary action device, such as the little man that goes round and round inside a control tower, or an on/off toggle device like the interior light in that control tower.

With the ASC2, you are presented with very clear on and off states. The Aux1 button sends a series of “on” packets for as long as you keep the button pressed, and sends a single “off” packet once you take your finger off the button. The Aux2 button functions completely as a toggle. The first time you press it, and “on” packet is sent. With the second press, an “off” packet is sent. This is great, however, you have no way to tell which button was pressed!

I want to use the PDI data available on the Base 3 to initialize my system. This mismatch between TMCC and PDI lands makes this challenging.

Any thoughts?

Thanks,

  — Dave

I’m now reading switch state from the PDI events generated by the STM2 and the ASC2, as well as power district events from the BPC2. I still need to add code to query initial states when the system powers up, but I have most of the code in place to do this.

I am taken by how very different the PDI command structure is from TMCC. There is really no overlap. PDI devices all share/support a set of “common” commands (get, set, receive), and actions (config, status, info, reset, identify, clear errors, and firmware) as well as a few device-specific commands and actions. Most of the common commands focus on what I would call "system administration"; reporting comm errors on the PDI bus, getting firmware revisions, etc. These have really nothing to do with running trains or operating accessories,  And, as I mentioned previously, PDI land doesn’t receive any notifications at all about many of the events that occur in TMCC land, meaning I will need my Ser2 when I roll out my first control panel.

  -- Dave

I’ve added support for Python 3.10, 3.11, and 3.12, as well as have started using Tox to run my test suites. This week, I’ll add support to send commands directly to the Base 3, removing the requirement for an LCS Ser2. However, you will still need the Ser2 if you want to issue the extended TMCC commands (like to trigger dialog), and if you want to monitor the TMCC command stream that is made bailable via the Ser2 (not all TMCC commands are broadcast from the Base3).

I am also reading up on how to package the code and put it up on PyPi. At that point, it will be much easier to install and use the main executable, PyTrain!

  -- Dave

Code is checked in to send commands directly to a Base 3 (or Base 2 via a LCS WiFi module). This means that those of you without an LCS SER2 (or any LCS devices) can also use PyTrain to control your layouts.

  -- Dave  

I can now read Acs2 and Bpc2 states at system startup. I will add support for other Lcs modules ads/if folks (and myself) need it.

  -- Dave

Is there anything people are working on that would take the place of a Base unit?

Thanks,

John

I can now read the Engine and Accessory rosters from the Base 3. It will be easy enough to do the same for switches and routes as well. Between this and the code I added earlier to query LCS devices t system startup, I have all the pieces I need to keep system state in sync.

Reading data from the Base 3 also lets me get the road names nd numbers of everything, but I don’t think this will be of too much use in fabricating control panels, at least the ones I plan to build.

The Raspberry Pi’s continue to be able to handle all of the work, and the memory footprint is still pretty minimal.

The next big piece left is packaging the code so I can upload it to PyPi. This will make it much easier for end users to grab the code without having to set up a development environment.

  — Dave

I am now updating the Base 3 database when changes are made to an engine/train's speed, momentum, diesel run level (rpm), engine labor (efx), smoke level, and train brake via TMCC commands. All changes are reflected back from the Base 3. Only speed and momentum changes are correctly reflected on the Cab 3. I've made @Dave Olson aware.

I'm not sure if the Base 3 maintains the fwd/rev direction state of a train or engine (relative to motion, not the direction an engine is facing in a consist). Would be nice to sync this state as well, if possible.

So, to recap progress (and I may repost this separately), here is what's working:

• All TMCC-style commands can be sent via Ser2 and/or Base 3 except for consist creation and modification (See V1.21 of the Legacy Command Protocol document)
• All 3 byte Legacy/TMCC2 commands can be sent via Ser2 and/or Base 3 except for consist creation and modification (Also in V1.21 of the Legacy Command Protocol document)
• Almost all multibyte Legacy/TMCC2 commands have been implemented. They can be sent  via Ser2 and/or Base 3 (multibyte commands include smoke levels, dialog controls, advanced lighting controls, etc, see V1.21 of the Legacy Command Protocol document)
• Ability to define a sequenced command (maybe I should call this a component command) that allows you to issue multiple commands with specified time delays and repeats, as needed. For example, I've developed ones to perform the grade crossing whistle blows that happen when you use an IR track, and that do a sequenced speed increase that includes engine and tower dialog. These mimic the "official" railroad speed buttons on the Cab 2 and Cab3, but include the tower and engineer dialogs issuing the speed-up (or slow down) dialog, the change speed command, then the engineer acknowledge dialog.
• All TMCC and Legacy commands broadcast from the Ser2 and echo'd to the console.
• All PDI commands broadcast from the Base 3 can be echoed to the console
• All broadcast TMCC, Legacy, and PDI commands can be "subscribed to" and callback functions can be invoked when specific actions occur (this feature is used to support state management as well as console echoing)
• Switch, Accessory, and some Engine/Train state are maintained.
• State is initialized at startup by querying LCS modules and the Base 3 itself
• Client/Server mode is supported where the code on one Raspberry Pi can service multiple connected clients. Clients can send and receive commands and state updates as if they were the server module. Only the server needs connection to an LCS Ser2 and/or a Base 3.
• TMCC state changes are pushed to the Base 3 (and Cab2/3 controllers) automatically
• A command line interface is provided that allows all TMCC and Legacy trains, engines, switches, accessories, and routes to be operated and monitored. This same program is used to perform TMCC/Legacy/PDI command echoing.
• Most implemented commands can be issued via the command line interface.
• Support has been added for the LCS BPC2, STM2, Ser2, and ASC2 modules.
• Software support exists to issue all of the common LCS  PDI commands (Firmware, Status, Config, Info, Clear Errors, Reset, and Identify). It is a TODO to make these commands available via the command line interface.
• Helper methods are provided to simplify the association of buttons, LEDs, toggle switches,  joysticks, rotary encoders, and pots to TMCC and Legacy commands and dynamic state. This means you can associate the commands to throw a track switch to buttons on a Raspberry Pi, and have an indicator light that correctly reflects the switch state, even if thrown another way (e.g., the black Lionel controller, your Cab2, derail prevention feature, LCS STM2, etc). This was the raison d'être for the project
• Higher-level methods exist to control Lionel Culvert Loader/Unloaders, Gantry Crain (some work left to finish here), Smoke Fluid Loader, Generic Route, Generic Switch, Generic Accessory, Power District, and Engine.
• Ability to define buttons, lights, components, etc. in a startup file that is loaded when the command line program runs; this is where you will "define" the physical components on your control panel and associate them with the TMCC/Legacy operations to perform when the controls are manipulated.
• All code is in Python3 and runs and has been tested on Python 3.10, 3.11, and 3.12 (the most recent version supported by the Pis is 3.11) and is up on Github today.
  
  

Remaining work:

• Package the code to enable downloading from PyPi. This will allow folks that don't want to download source code to install the executable that makes all this work.
• Documentation (sigh)
• More tests
• Implement logging (remove print statements)
• Modify sequenced speed commands to look at engine state, so if you give a speed change command, the engine gracefully ramps up to or down to the new speed)
• Add generic support for rotary encoder
• Complete Dialog Control commands
• Build a control panel

  -- Dave

I should add, if anyone is interested in giving the code a try in its current state, it would be much appreciated! Email or DM me for more info.

  -- Dave

Email sent. Thanks!

Just checked in the rest of the engineer/tower dialog effects on page 13 of the Lionel protocol spec. These are some fun things, like the engineer speaking the current speed, fuel, and water level, and the tower to engineer and engineer to tower arriving, arrived, departing, and departed dialogs. Using randomization and setting up event watchers on the IR sensor tracks would allow users to trigger random dialogs as your train motors along the rails.

  -- Dave

Email also sent, thanks!

The things I'll do to avoid taking on something I have trepidations about (packaging).

I've implemented support for the seven common PDI commands for the LCS devices (FIRMWARE, STATUS, INFO, CONFIG, RESET, IDENTIFY, and CLEAR_ERRORS). These can be issued from the server pytrain instance (the one with the Base3 connection). The commands let you display information about your LCS devices (modes, voltage, firmware, errors), turn on and off the little red Ident LED, clear out error counts, and reset the module (I have no idea what this does; sounds dangerous!).

I've also returned to the house where my layout is at and tweaked support for the STM2, BPC2, an Sensor Track modules, and I must say, things are working pretty nicely! At power-on, you get a complete list of all engines, trains, switches, and accessories, along with their names, road numbers, and current state.

One thing I need to do is to send a discovery command when a power district is turned on. Switches that are contained in a power district don't report their actual state until power to that track section is turned on. This is a simple addition for me to make.

  -- Dave

This is very exciting work! I could only dream of having the time and knowledge to tackle something like this. I'm having a little trouble understanding some of the posts but it gives me a good reason to try out Python. I'm trying to learn C# at the moment for work so I figure learning any code will benefit me.

@BillYo414 posted:

This is very exciting work! I could only dream of having the time and knowledge to tackle something like this. I'm having a little trouble understanding some of the posts but it gives me a good reason to try out Python. I'm trying to learn C# at the moment for work so I figure learning any code will benefit me.

Happy to answer any questions you have either here or in email!!

  -- Dave

I have support for Sensor tracks in. This could definitely be used to trigger events when engines pass over them. I could also have the engine actually "respond" to the "go to normal speed"/"go to slow speed". I will probably enable this as an option...

  -- Dave

Would these events include items outside of the Lionel ecosystem? Like say environmental sounds, scenery animations, or digital information? And as far as digital information, that would be things like moving digital freight around the layout.

This is starting to smell a lot like @Ryaninspiron's gamification project.

https://ogrforum.com/topic/int...rack-based-game-idea

It seems like that may have been stalled in the PDI communication implementation, but I don't see why it couldn't use the wifi connection.  I believe his goal was to have a pure LCS implementation (no serial), and it sounds like sensor track may have been the last piece of that puzzle.  I assume sensor track signals can be received via LCS wifi here right?

@Patrick Keistler posted:

This is starting to smell a lot like @Ryaninspiron's gamification project.

https://ogrforum.com/topic/int...rack-based-game-idea

It seems like that may have been stalled in the PDI communication implementation, but I don't see why it couldn't use the wifi connection.  I believe his goal was to have a pure LCS implementation (no serial), and it sounds like sensor track may have been the last piece of that puzzle.  I assume sensor track signals can be received via LCS wifi here right?

Absolutely. In fact, the Irda/Sensor Track packets are only sent out via PDI/WiFi.