JMRI and Launchpad Thoughts: Virtual IO Points
There is so much left to experiment with concerning the Launchpads connectivity with JMRI that it’s mind boggling. One thing that has captivated quite a few of my brain cells recently is the notion of Virtual IO points.
The basic concept of IO points is relatively straightforward. A pin on the Launchpad is a single IO point. It’s either Input or Output. But the Launchpad is so much more powerful than just a bit setter or a bit reader! When thinking about such a waste of ‘power’ using the Launchpad as a 12 pin CMRI node, it hit me like a ton of bricks:
Virtual IO Points
What if we loaded on some custom lighting curves, setup a PWM and allocated two pins on a Launchpad to be the ‘red lights’ of a grade crossing. No problem, already been done. Now, allocate 4 more pins for the detection system to activate the grade crossing. Again, no problem. But now, what about making those 4 inputs also CMRI inputs that JMRI can see and a virtual Output that activates the PWM code and flashes the lights. JMRI would be able to see, and command, this ‘Virtual IO Point’ and enable the grade crossing, but not command the individual red lights. The Launchpad would also be coded such that the 4 detection inputs also activate the grade crossing.
By taking a LP based detection/grade crossing implementation and putting the CMRI->JMRI code into it, you increase the monitoring and control capabilities of your layout… for free!
Another example of using virtual IO Points would be a traffic light controller. A simple 3 light, two direction setup on launch pad would use 6 output pins. Little would be gained by enabling JMRI monitoring of the traffic light… unless the traffic light had ‘night mode’ code in it. Many traffic lights I’ve seen go into flashing yellow or red during the late night hours (presumably to save electricity). Having an input on the Launchpad connected to a button or light sensor that will trigger ‘night mode’ on the traffic light would be a perfect reason to enable JMRI monitoring/control now. The light sensor would be able to tell JMRI the day/night condition of the layout and JMRI could now tell the traffic light what mode to be in by commanding the Virtual IO point.
Last example. Glue the previous two examples together. I’ve seen a traffic light in very close proximity to a grade crossing, and when that grade crossing is activated, the traffic light flashes red in a specific direction.
With two red lights, 4 detection sensors and 6 R/Y/G lights, we are maxed out on pins for the Launchpad if we plan on using the CMRI code for control. What we get, however, is 4 inputs and two outputs for use in JMRI. 4 track sensors, 1 grade signal command output point and 1 night mode output point for the traffic light. PLUS, we can hard code the traffic light to go into ‘night mode’ whenever the grade crossing is active.
I’m sure there are hundreds more ideas out there for ‘advanced’ features driven by virtual IO points via CMRI. I’d love to hear them!