Fun with JMRI

Okay, so I've been having some fun with JMRI (Java Model Railroad Interface) and I've made some good progress.  For those that don't know about it, you should follow the link for details, but essentially JMRI is a FOSS tool to help you manage and automate your model railroad layouts.

After getting my prototype layout completed, I settled in to see how the software works.  I knew already that you can use Jython/Python to do scripting.  So I started diving into that first.

I should start by saying that my vision was to use a Python IDE to write and manage the scripts.  After looking around quite a bit, I settled on Aptana Studio which is, among other things, an IDE front end for PyDev.  Pydev is an Eclipse plug in that lets you write Python code.  Aptana Studio is also based on Eclipse, but is a skinny'd down version, which was attractive as Eclipse is HUGE.

I played around with it and did some research, and I found that, as far as I know, I can't really do what I wanted with Aptana Studio.  I was hoping for integrated debugging and stuff like that, but JMRI really needs the Python scripts to be run inside of the JMRI software.

So I started trying to use JMRI as my IDE.  Let me say that JMRI is NOT intended to be used as an IDE!  There is a window you can bring up that lets you type individual scripts (Script Entry), and an output window (Script Output)  to see the results after executing.  Both windows are spartan to say the least.  There are no menu bars, no copy or paste functions... nothing but a multi-line text field and a button at the bottom to execute what you typed.  I did find that you could paste code in by using the keyboard short cuts.  And this works... but it is FAR from an IDE.

At this point, I should recognize 2 things.  First, JMRI isn't meant to give you the functionality of a Python IDE, or even a simple editor.  Second, since JMRI is open source, I shouldn't complain about it.  I should build it instead.  Alas, I'm a noob, so maybe someday, but right now, I'll find another way around it.

There is one other option in JMRI called Run Script.  For reference, all of these items are in the Panels menu item.  Clicking Run Script allows you to select a Python script to run.  I found, by trial and error, that the output of the script is sent to what looks like a DOS box that is opened when JMRI first loads.   Error messages and the output of print statements will show up here.

There is also a nifty menu option under Panels called "Thread Monitor" that lets you see the scripts that are running.  It will tell you which scripts are active, and how many times they've been cycled. 

Once I found these items, I found that I could sort of combine Aptana Studio with JMRI to get some of the benefits of an IDE - or at least my most important one for now - context completion.

Context Completion is basically the IDE popping up a menu of items that you could logically write at that point in the script.  For instance, if I wanted to print something, I could type "pri" and after the third letter, the menu would pop up offering me options, one of which would be "print".  It seems like a small thing, however, if you are typing in a method call that requires 4 parameters, it will pop in the parenthesis, and quotation marks if the parameter is a string, with each parameter stubbed out with commas between them.  At that point, you just fill in the values (which again, may have options pop up) so coding becomes much more of a pick and choose operation than a total recall operation.

So far, the only context completion that works is the base Python stuff, but I think I'll be able to include the JRMI classes as well, so that all those method calls become available for context completion.

So at this point, I was able to write and save scripts, and then test them by switching to JMRI and clicking the Run Script menu option.  This saved a lot of time, and I made good progress.

In the end, I was able to create a script, extending an example to something more complicated.  The example ran a locomotive between two sensors.  I was able to modify it to run it to one sensor over a set of turnouts, have it reverse direction, and when it got back to the first sensor, it again reversed again, threw the switch, and sent the locomotive to a siding with another sensor, which reversed it's direction again.  I wrote the script so it would continue to do this until stopped. 

Bottom line is that I've written my first successful script, and was able to sit back and watch my train essentially run itself.  Very satisfying.  However, now the doors are open... lots more scripting to work on, and object models, and class design, and... well, you get the idea.

TTFN

Prototype Layout Complete!

Santa was good to me this year.  I got a Kato RDC car, along with the decoder.  I also got the rr-cirkits LocoBuffer USB.  With these additions, I was able to start work on my prototype layout!

I started by hooking up the DS64 and the Zephyr Command Station, and wired up a couple of Atlas turnouts.  This worked flawlessly, and seem to be a very robust solution.  I was able to wire up 2 turnouts to the same port on the DS64, confirming that it can indeed drive 2 snap switches without any trouble.

I then hooked up the LocoBuffer to the command station, and began wiring up the Boulder Creek Engineering IR Detectors that I had gotten for my birthday.  I had a little trouble here... but the bottom line is that the sensors also work flawlessly.

My troubles started when I used a generic wall wart to power the DS64.  That ran the DS64 fine, and it ran the switches without a problem.  However, when I wired up the IR sensor, I found some troubles.  It seemed that the signaling voltage was far below the 12-14 volts needed for the DS64 to register the sensor.  I think it was probably that the wall wart didn't provide the necessary amperage.

The next thing I did was to wire up the sensor, and the sensor only, to a Radio Shack external 13.7 volt 2.5 amp power supply.  Trouble was that I continued to power the DS64 via the wall wart.  Well, I'm not quite sure what I did, but after breaking out the voltmeter, it looks as if I fried that sensor.

At that point, I did some independent testing, and decided that it must be a really bad idea to use two different power supplies on the sensors and the DS64.  The DS64 can take power off of two inputs from an external power supply.  So after breaking out a new sensor, and wiring things up, everything seemed to work fine.  I tested the 3 IR sensors I had remaining, and all of them checked out fine.  So all in all, that trouble got averted.  I'm also pretty sure that I want to use an external DC power supply to power a DC bus throughout my layout for sensors and DS64's.  I don't know if 2.5 amps will do it, but I have some time to figure that out later. 

The next thing I did was dive into the JMRI software deeper.  I was able to use it to verify that the IR sensor data was making it onto the Loconet bus.  It worked great in this regard.  So there wasn't much left but to start creating my prototype layout.

A trip to Lowes yielded some wire and a 6 foot length of 12 inch particle board.  I put some supports under it from left over 2X4's and I had a relatively stable platform.  I then laid out some sections of flex track, attached to 2 turnouts.  It is essentially two spurs that collapse into one track on the other side of the switches. 

I had been using a pair of wired connectors for power, but found that they didn't supply power throughout the layout.  So I used a small length of the 2 pair wire that got at Lowes, and fired up the soldering iron.  I found that wiring power leads to flex track is FAR easier than I imagined it would be.  I must have had a bad soldering experience that I've blocked out, because it really was as simple as stripping down the wire and heating it up with a little solder.  I think having the right wire is the key.  I'm using 24 gauge, solid wire and I think that makes a big difference.  I have no doubt now that this is the way to go.  Solder every piece of track to your rail bus people!

At this point, I was able to drill some holes and mounted the IR detectors (and when I say mounted, what I mean is that I drilled some holes and stuffed the IR detectors into them).  I popped off some of the ties in the track to make room for them.  Not pretty, but serviceable. 

I was able to get a train to move smoothly over the layout at this point.  I tied it down in one spot (near the power leads). 

Now came the fun part... watching sensors go hi and lo when a train moved over them.  It all worked like a charm.  Next post, I'll be talking at length about JMRI and the "fun" I've had with that so far. 

TTFN

New Toys

I know, I know... model trains are MODELS not TOYS.  But anything new and cool that I own is a toy to me.

So I finally cashed in some of my gift certificates and got a couple of new things.  First is a Digitrax DS64.  It will be a little while before I get around to hooking that up, but I will likely play with that once I get my LocoBuffer USB and can see inputs and outputs from it.  In the mean time, I got a deal on the second item...

I bought the Bachmann Acela n Scale set.  I had seen it this summer as low as $250.  Well, it was down to $180, so I snapped that up with a $200 gift certificate from my lovely wife.  It comes with a bunch of Bachmann E-Z track, basically enough for a big circle, and which I probably won't use except as a testing ground.

More importantly, it is DCC on board (has the decoders built in) and has two engines (non-powered), powered cafe car, a first class car, and a business class car, both with lighted interiors. I'll be using this on my layout as the express train, mostly running out and back on the center set of tracks.  I'll probably set up the oval and hook up the Zephyr command unit I have to see how it works.  Reviews were fairly good on this model - Bachmann doesn't have the best reputation, but they did a reasonable job on this set.  Time will tell.

So hoping that I at least get a LocoBuffer USB for Christmas and then I can start doing some real live testing in preparation for laying down the main layout.

TTFN

Birthday Went Well!

I'm overdue posting here, mostly because I've been sidetracked (sorry for the pun) with respect to my railroad work...

I did get generous gifts at my birthday that will allow me to buy the components that I want to purchase for my first test layout.  I should be able to get a DS64 and the module to allow my computer to work the Digitrax equipment I already have.

And I DID get 3 of the IR detectors I spoke about in a previous entry.  The idea is to test out a simple siding with the IR detectors installed.  This will allow me to test a whole bunch of stuff...

I also settled on RDC's for my commuter rail sections... I can get one to start with and build up from there.  I'll be able to get into consisting, and I'll be able to run them independently after my layout is complete and so I will be able to continue extending the computer control project making it more and more complex as I go.

I think this modular and staged approach will keep this hobby working more like a process than a project, which is the best way to keep up with it I think.

Anyway, if you want to check out what's been distracting me lately, check out my new blog - Mirthful Moose Musings... this will be a generalized blog about what is going on in my life, and keeping me from these other hobbies...

TTFN

Unitrack, Flex Track, and Platforms

Well, I've been distracted quite a bit by my position on the local Board of Education.  I had to vote to close a school, which was difficult, and unpopular, and has taken a lot of time away from other activities.  But I have been thinking a bit about my layout and other items.

I started to research track bed - Cork vs WS Foam.  Basically, cork is old-school, tried and tested, and well liked.  Foam is newer, but has adherents.  I started leaning toward foam as it sounds easier to get started and potentially will last longer.

But this lead me to a reconsideration of my track.  I had been planning on using Atlas flex track and snap switches, which are DCC friendly.  But the work involved in laying track, ballasting, etc. got me to consider Unitrack by Kato instead.  It has the advantage of being easy to use, and there are ways to wire it that avoid soldering, which is something that would save time and trouble.  It also has the advantage of being able to be broken down and reused - something that as a noob I find attractive.  So I'm still thinking this through.

I also spent some time looking for platforms.  I found some that may work well from Walthers.  I want the landings to have mock staircases to a pedestrian tunnel.  Trainboard.com is very helpful for this kind of advice and I'm just starting to participate there more fully. 

Anyway, things are moving slowly, but my birthday is coming up, and depending on the goodies I get, I may be able to make some real hands on progress.

TTFN

Latest Status

Well, a lot has happened since my last post.  So I should get right to it...

I spent some time designing a test layout.  It consists of 2 turnouts, one LH and one RH and a bunch of flex track.  I plan on temporarily mounting these and the switches on a piece of 8' 1x12.  Basically, it will merge two tracks to one.  I also plan on mounting 3 IR detectors, and a DS64.  Oh yeah, throw in an RR-Cirkits Locobuffer USB...

Among the tests I want to do are:
- Test that the DS64 can be used to throw the turnouts using a momentary switch
- Test that the DS64 can be used to throw the turnouts using the Digitrax Zephyr throttle
- Test that the Locobuffer can be used to interface with the throttle via the computer
- Load and test JMRI - use the default computer controlled throttle to run trains and switches
- Attach the IR detectors to the DS64 and verify that JMRI can sense the input
- Test that the JMRI software can throw the switches
- Begin testing the scripting of JMRI to control trains and switches based on sensor inputs

It is a long list and will take some time.  I've already designed the test layout in XTrackCAD.  I've also imported that into JMRI to create a default panel.  Some gotchas on the way, and I can expound on this step if people say they want that in the comments.  So far, nobody is looking or listening to this blog... but I will keep posting anyway.

That's it for now... I'll probably test whether or not this blog is getting indexed by Google next.  I've put a few links on Trainboard.com and have begun asking and answering questions there.  I will try and integrate the blog with my questions and answers there to drive some traffic.

Oh yeah - I put all the stuff above on my birthday list.  Hopefully some or all of it will come in.  If it doesn't, it will be a slow slog acquiring my test equipment, as money is tight.

TTFN

Why IR Optical Sensors / Detectors?

Good question.  This is probably the most untried and untested part of the layout that I'm proposing to build. The conventional wisdom is that block detection (using current) is the preferred method.  Most websites I've gone to prefer it to IR or optical detection.  They may be right.

However, I have a bias toward the IR or Optical Detection.  Let me try and explain so I can better understand it myself. 

With Block Detection, you isolate a section of track and you can then, by using lots of off the shelf detection circuitry, detect things like locomotives, cars with lights, and cars with wheel resistors on them.  The detectors, as I understand them, sense the extra current that flows to power these things, and thus is able to tell when something like that has rolled onto that section of track. 

There are lots of different off the shelf components that do just that.  Both Digitrax and RR-Cirkits makes boards that will sense the current spike that happens.

For optical sensors, or IR detectors, off the shelf components are hard to find.  Most of the stuff I found on the Internet was a "roll your own" type of solution, often involving the soldering of components together to make your own detectors.  And optical sensors have many options - some are simple light sensitive resistors.  Others are IR (infrared).  The regular optical sensors can be fooled by bright sunlight, and don't function in the dark.  IR detectors are a step up from this.  They can operate in the dark, but the complaint online here is that they are often very hard to align. 

In my application, it is very important that I sense exactly when a train reaches a certain point, not just that it has reached a section of track. For instance, in my layout, the commuter train will have a locomotive at one end, and simple rolling stock on the other.  So using block detection, I'd have to make sure that either the last car had a light or similar resistor on it, or I'd have to position the block differently on both ends, and sense when the engine came into the detection block.  (on the West station, the engine will come into the station FIRST, in the East station, the engine will come into the station LAST).  It gets even more complicated with the Acela, because on that train, the "engine" is actually one of the cars, and the "engines" on each end are dummy cars.

IR detection avoids all these issues.  And there is a vendor that makes EXACTLY what I'm looking for.  Boulder Creek Engineering makes a product called the NightScope IR detector that comes as a single unit - both the IR illuminator and the sensor for it.  They are already aligned perfectly for this.  You just drill some holes and mount this under your tracks.  And I'd like to send a shout out to Jim, who quickly answered my questions about how this device would integrate with the Digitrax DS64.  He confirmed that it will work and then sent me a diagram on how to wire it up properly.  While I haven't tested their products yet, I fully intend to, and if they work as advertised, I'll be incorporating them into my layout.

I'm happy to hear from any folks who think I'm crazy for taking this approach.  I'm a noob, so I may be all wet.  Failing feedback, I'll see if I can blaze a trail for IR detection instead of block detection.