How to Use JMRI Software With Lionel TMCC video

This is an interesting subject. I do hope they do add some of the other Cab-1 and 2 functions to the JMRI library. I'd like to see turnout and other commands added. Unfortunately, very few 3 railers have discovered JMRI, and it shows.

The reason I mention turnouts is, mine will be controlled by JMRI via C/MRI, and not a Lionel device. If that was available, I could send a turnout command from my remote, back through the base, over the serial line to the computer. From there, it would be processed, then go back out over a second serial line to C/MRI and throw the switch. A little convoluted I know, but it would provide an alternate method of throwing switches, away from the planned central dispatch.

Edit: I guess I spoke a little too soon with regard to the switches. I had not finished watching the video when I posted that. The difference between what he's doing and what I want to do is the direction of communication. He's using his phone to send commands via the computer and base. I want to send commands via the normal remote and have JMRI react to them. It still should be possible, I'm just not sure if the Java routines for that type of function are written.

okay Elliot.... how do you wire a switch to work with this JMRI program?  am curious is all, does one need a lionel product to connect switches to so commands sent get to correct switch?

Ray, I'm pretty sure that the guy in the video was using a Lionel switch controller. No reason for him not to, as his layout is fairly small. He was just proving that the JMRI interface with his phone could do that function as well. So the chain of "command" goes: phone app via wifi to computer, through JMRI, then via serial line to command base or switch controller. DONE!

It's just a giant black box with magic inside.

Because I have so many switches, controlled by Tortoises, and I already own C/MRI and was using it for other functions anyway, I was hoping to be able to use the JMRI interface in a "listening" function for commands from the regular remote. Then it would relay those commands to C/MRI and throw the switch that way. I still have one technical difficulty with this whole theory, and that is, I have more than 100 switches, so I'm hoping that a route command could cover the overage.

Elliot  thanks for the explanation I thought there was a middle man that switches be connected to but at least I know what else is needed.

as to route am taking a SWAG here but in that turnout window would you be able to group say switch # 1 - 2 - 3 - 4 in that window and all would change as a route or am I missing your meaning to  "route command" ?

Elliot, what you propose should be possible with JMRI scripting.  The JMRI TMCC API includes routines to read serial traffic from a TMCC interface.  So what you would do is write a Jython script that listens to serial traffic from the TMCC port, parses the TMCC packet to identify the turnout and the direction to throw, and then just tell JMRI to set the turnout via C/MRI.

I'm not sure exactly how to do that - my JMRI scripting has been trial and error based on examples, and I've never touched the TMCC code. I don't think it would be more than a couple dozen lines of code. Parsing the TMCC command would be the most complex part, but the JMRI TMCC code does seem to include routines to parse TMCC commands into JMRI system names.

You might post on the JMRI user group, asking for help (if you haven't already).  As I said, the basic concept is simple: add a listener to the TMCC serial port, parse the TMCC packet to retrieve a turnout identifier, and then throw the turnout via C/MRI.

Elliot,

You can easily expand your C/MRI with an Arduino.  What I think will be really nice for your large layout will be implementing CTC or CATS with JMRI.  And as you said earlier if the throttle functions are expanded, JMRI could become your primary interface.

Chris

Looking a little more at the JMRI TMCC routines, there doesn't seem to be one to extract device identity from a TMCC packet.

But it's still pretty straightforward. The JMRI API provides a getAsWord() function that seems to retrieve the 16 data bits of a TMCC command emitted by the Command Base. With simple masking you can determine if the packet is a switch or route command, and then extract the address bits.

The hardest part would be getting used to the basics of the Jython scripting, but there are a number of examples on the JMRI website to get you started.

Correct Ray, you would define a group of switches as a route. In my case I could use them to throw single switches above #99, since the remote can't do 3 digits. This is an important function for me to throw switches from the Cab-1, because once the conversion to C/MRI & JMRI occurs, there will be no local control panels anymore, just a CTC dispatching board in a corner of the train room. If I'm running trains by myself, I need this convenience to get me out of the corner I've painted myself into with this high tech stuff.

Some really good examples for the route commands are my hidden yard ladders. Name the routes after the tracks they would access. That would be 10 right off the bat.

Prof, thanks for confirming that. I always suspected it was possible. I understand the theory and capabilities of these systems pretty well. The practice and implementation is where I'm going to need the coaching. I'm still a ways away from getting into this full tilt, but I'm always thinking about it. I think the first project will be to design my dispatching panel with panel pro, then get the C/MRI fired up and get the turnouts working.  From there it's on to detection and finally signaling. Eventually, I'd like to have JMRI run "virtual cabs" for fully automated mainline action.

Chris, I'm not sure I want to get involved with Arduino. I have so much excess output capacity with my C/MRI system, which has been boxed up for nearly 25 years. I might have 800 output lines available with under 150 allocated so far. Without a full schematic of the layout, I can't create a signaling plan to determine my final needs, but I'm sure I've got it covered. I'm a little short of input capacity for my detection application, but that is easily solved, by purchasing a few cards. I'm in the process of pinning that number down so I can order them.

Professor Chaos posted:

Looking a little more at the JMRI TMCC routines, there doesn't seem to be one to extract device identity from a TMCC packet.

But it's still pretty straightforward. The JMRI API provides a getAsWord() function that seems to retrieve the 16 data bits of a TMCC command emitted by the Command Base. With simple masking you can determine if the packet is a switch or route command, and then extract the address bits.

The hardest part would be getting used to the basics of the Jython scripting, but there are a number of examples on the JMRI website to get you started.

Prof, I was typing that big response, so I didn't see your most recent here, til after I pulled the trigger. Well, at least it isn't impossible, it will just take more work. I have a computer programming background from my time in college, which should give me a bit of a jump. My only problem is I haven't used any of it in 30 years. I knew I was going to have to learn a language, sounds like it is going to be Jython. I'm going to need some routines that aren't part of JMRI for my layout anyway. Even with a couple pieces of the puzzle missing, I still feel like I'm way ahead of where thought I would be before I heard about JMRI. Back then, I thought I was going to have to write it all.

Hi Elliot - just for fun, I wrote a JMRI script that listens to the output from the Legacy/TMCC base, and reports when you have thrown a switch from the CAB.  If you load this script file upon JMRI startup, it will display the output in the script output window. Note that for Python the spacing of the indentations is critical.

This code assumes you have set the serial connection to the base as the TMCC connection in JMRI preferences.

For your purposes you would want to add code to throw the corresponding C/MRI turnout, and maybe extend the code to handle routes. 

import jmri

class TMCCListener(jmri.jmrix.tmcc.SerialListener):
 def reply(self, r):
   print "Received TMCC Command"
   i = r.getAsWord() # retrieve two bytes of TMCC packet
   if ((i & 0xc000) == 0x4000): # first two bits are 01 -> is a switch
     if ((i & 0x0060) == 0): # and command field is 00 -> throw command
       a = (i & 0x3f80) >> 7 # get switch address
       print "Switch", a, "thrown",
       if ((i & 0x1f) == 0): # read data field; 00000 = through
         print "THROUGH"
       else :
         print "OUT"
   return
 
print "TMCC Monitor starting"
jmri.jmrix.tmcc.SerialTrafficController.instance().addSerialListener(TMCCListener()) # add the listener to the TMCC serial port

I set up the layout to run off JMRI and it works reasonably well. However it's fairly complicated and resolving issues requires more technical expertise. I moved into the LCS system so I wouldn't have to mess with it

Call me when LCS can do this:  

JMRi is really neat, and I am surprised there is very little discussion on it around here.  I looked into it a while back, but there was not a whole lot of support for TMCC at the time.  seems like there is a bit more now.   

Elliot, for what it's worth, the TMCC or Legacy base will actually run up to 127 switches from a computer control.  The remote is just limited to 2 digits.   also 15 routes rather than the 9 on a cab1.  From what I understand, address number 0 is not usable, so your total number of addresses is one less than the proper binary limit.  

Another option that can be used fairly easily with a computer control is to use one of the accessory addresses to switch back and forth between two banks of switch controllers.  This would also allow access to all switches from a cab1/2 remote.  ex, turning off accessory #1 activates switches 1-99, and turning acc #1 on would activate the second bank of 99 switches, say numbered 101-199 to make it easy.  Doing this, I would place all the commonly used switches and those that are typically going to be used in routes in the first bank, then less used switches and such in the second bank.  some creative wiring would also double the number of routes you could have.  

For the number of switches you have, I would build my own "SC2" type device.  I know Dale Manquen has done this full scale.  I've built a 16 switch controller, and with everything needed it cost around $50.  each additional bank of 16 switches only adds another $40 as the power supply and controller are only needed once.  pretty reasonable over using SC2's which, will set you back over $2000.00 to control say 120 switches, for 120 switches on the home brew version you're looking at something under $320.00 in parts.  

JGL

Yeah professor, that's exactly what I had set up except bigger and running Wiithrottle on my iPad as s control panel. Built s sweet control panel, full loco roster and switch library. It's a pretty powerful tool to run your railroad with infinite possibilities but it just required too much dickin around to start up and use. I want to be at running trains time not at messing with the computer then iPad time. 

That's a really nifty little procedure you put together there Prof. With the nice comments I can actually read and understand it. Brings back memories. Looks a lot like C. Back in college I had mastered Pascal, and C was the next big language. I had a tougher time with some of the differences, and translating between the two. C seemed a little fast and loose with the rules, and if you didn't do things exactly right, you could get some unexpected results. Lots of potential traps, but more powerful.

Matt, usually I say, "you get what you pay for". But in this case that gets turned on its ear, as JMRI is free and LCS costs money. Well maybe JMRI isn't really FREE, because there is some amount of learning required, but as the Prof points out, it is more powerful and can do a lot of things LCS can't, that control panel being just one. I'm not really into instant gratification when it comes to the trains, I would rather take the road less traveled. I find it far more interesting than simply running trains. That is one thing I don't plan to do, use WiFi devices.

JGL, it is unfortunate that more people aren't interested in JMRI and the other high tech controls that are available. Just look at the forum demographics. A lot of conventional runners, older, just want the simplest way to make the trains go. We technophiles are a rare breed in the 3 rail world. I suspect that the majority have worked with technology in their professional lives and carried it over to the hobby. They understand it, and aren't afraid of it. Everyone's definition of fun is different. I really liked your idea for the TMCC / LC+ bridge.

I actually have known about the 128 addresses since I read the command section in the TMCC manual years ago, only I was thinking about controlling engines at the time. Dale Manquen and I discussed that on the phone a couple weeks back. The remote just can't get them, but the computer can. BTW, I have an engine programmed to 00, works just fine. It's valid. I suspect the switches are the same. I forgot the routes only use 4 bits. The remote only allows one digit for those. I'll bet if you try 0 it works. I like the idea of the accessory key, that yields the desired result, not the route key. I've never used any of those keys anyway.

C/MRI is my giant SC2 (as well as other functions). This panel is at the heart of the turnout control system. Each relay controls one Tortoise. The terminals at the bottom of the panel are connected to temporary control panels in the field with SPST micro switches mounted to them, for now. When C/MRI is implemented, computer output lines will replace the micro switches. One of the reasons I did it this way was for the easy swap out. In a way, this is sort of like your bridge. Material cost? Technically zero, I put this together from recycled materials purchased almost 25 years ago, same as the C/MRI.

I'll have to try out address 0 for switches and such.  For some reason I thought it didn't work from the remote.  

Also, I think the legacy remote allows 99 routes instead of the 9 on the CAB1. I know you just got your Legacy base working, so that is an option if you need more.  Another option could be to use your computer interface to read accessory commands as route commands; program it to say 'if accessory #42 is turned on, throw all the switches for route 42'

This is just fun stuff for me and takes me back to my dad's layout with a Commodore64 operating a dozen switches and some number of power blocks back in the day.  

If I recall JMRI is programmed in Java, which I'm not well versed in, however I expect it is similar to C or Python, and it is nice in that it is cross platform compatible.  

JGL

It is too bad that support for O gauge (TMCC anyway) is so lacking in JMRI. It would be neat of someone would take the Legacy codes and incorporate that into JMRI. Would also be nice to have MTH incorporate their codes into it, or at least release the codes so someone else could do it. I guess some can improvise with the scripts like ProfChaos above. Way above my pay grade on all counts here.

After seeing all the JMRI items available for DCC that are blocked out for TMCC, it really re-ignites my interest in DCC. I would really like to have a DCC setup someday, just to experiment with if nothing else. I have read a little abut it and find it very interesting. I guess we could actually use it with the PS3 engines that ae DCC capable? Something to think or dream about anyway.

I don't really know a lot about all this, but I do enjoy reading about it, trying to learn and doing a little dabbling every now and then. I also enjoy following all you folks that know what you are doing, something even sticks occasionally.

RTR12, personally I think it was downright nice of the group that has developed JMRI to give our sleepy little backwater the nod of including TMCC in their program at all. If we as a group would get more involved with JMRI, we could create our own libraries, even if they don't get included with the published version of JMRI. Prof seems to be quite well versed in this stuff, and was able, in very short order, to patch a hole in the existing program, with just a few lines of code.

As for MTH, I don't buy their engines, in part, because their codes aren't published.

You're welcome to have "DCC envy". I've never really studied its features, but I'm quite content with what TMCC / Legacy offer, apart from the signal issues I'm trying to resolve. Something about the grass always being greener on the other side of the tracks.

Elliot,

Very nice job on the relays panel. Maybe take a closer picture next time when ever you post a new up date.

Good luck,John 

NYC,SUBWAY TRANSIT SIGNAL posted:

Elliot,

Very nice job on the relays panel. Maybe take a closer picture next time when ever you post a new up date.

Good luck,John 

Thanks John. There's really not much to see close up, but here's a little closer. The circuit is most basic, a DPDT relay, set in a socket, is simply wired to reverse polarity to the Tortoise. The coil is controlled by a single wire carrying the ground to complete the 24VDC circuit. It just looks fancy, because there are so many relays and wires. BTW, there's another panel just like it on the other side of the room.

Elliot,

It looks great nice and net. 

On my layout in Florida I 12 volt DC  Relays 4 pole double throw for my Signals  System.

If you go on you tube a type in  O Gauge Subway Transit Signals its a 2:33 video about my Subway Signal on my Train board 

Good luck, John

Big_Boy_4005 posted:

RTR12, personally I think it was downright nice of the group that has developed JMRI to give our sleepy little backwater the nod of including TMCC in their program at all. If we as a group would get more involved with JMRI, we could create our own libraries, even if they don't get included with the published version of JMRI. Prof seems to be quite well versed in this stuff, and was able, in very short order, to patch a hole in the existing program, with just a few lines of code.

As for MTH, I don't buy their engines, in part, because their codes aren't published.

You're welcome to have "DCC envy". I've never really studied its features, but I'm quite content with what TMCC / Legacy offer, apart from the signal issues I'm trying to resolve. Something about the grass always being greener on the other side of the tracks.

I agree, it is good they have added what is there already. If I had the ability I wouldn't mind trying to add on if possible, but that's way over my head. I would like to give JMRI a try someday if I can figure it out, which the video was pretty good at explaining. I have mostly MTH PS3 stuff, only a little Lionel Legacy and no TMCC.

I do think DCC is pretty interesting, lots of stuff to 'fiddle' with there, but I have never tried it either. May get old after a while? It could be just a case of grass being greener on the other side of the tracks, until you get over there. When I got back into the hobby a few years ago I tried to consider HO, but just couldn't go with it. I like O gauge much better, seems more like trains.