Very, very nice stuff!
There's the beginnings of the code in jmri.jmrit.ussctc for creating
objects that use Routes & Logix to do various CTC components. I
haven't gotten anywhere useful on creating a user interface, but
there is some useful code there for going back and forth from Routes
& Logix to objects. This might be useful in implementing the
underlying logic for your GUI.
Basically, the idea is that there's a class representing something
that knows how to behave. You can configure it by e.g. telling it
what sensors and turnouts to use, and you can query that
configuration to get information for a GUI. But objects of that
class really only exist to make it convenient to do that
configuration; the actual performance, including loading and storing,
is done after the objects have been transformed into Route and/or
The first example of this was sensor groups. If you create a sensor
group, and then store it in a panel file, you won't see anything in
the file that looks like a single sensor group object. The sensor
group is actually a coherent set of Route objects, and that's what's
stored When you later query that sensor group, the code goes out and
finds the related Routes, sucks information out of them, and presents
it to you. If you change and store it, updated Route objects are
I haven't looked at your Logix, etc, and unfortunately won't have
time until late this weekend. Are there logical "chunks" to it, e.g.
maybe a "Logix runnign turnout lever 3", "Route handling code sound
4", etc? If so, maybe we could collaborate by you defining the
Logix/Route contents for those, and me writing the code to load/store
it, and then you working on the GUI?
I'm happy to write code to create and manipulate Routes and Logix,
because I have a lot of that stuff in my notebook already.
At 10:51 PM -0400 8/30/07, Dick Bronson wrote:
>Bob, Dave, and anyone else interested,
>I have posted several files on my web site for some developer comments.
>(no links yet except from this e-mail) The content of the Sounds.zip
>file is not for public release as yet, and at least two or three of them
>will need to be updated first. However they give you the general idea.
>The new sound files go into your "sounds" folder where you would expect
>them. The image "traffic.gif" goes into the
>"...\JMRI\resources\icons\USS\background\ folder along with the panel
>backgrounds because I didn't know where else to put it. The file
>"PP-07-Clinic-10.xml" of course goes with your other panels. This demo
>should be run with the LocoNet Simulator so as to not mess with a real
>layout. The two images show a mock-up of an idea that I need the
>comments and help with.
>The idea is to have a CTC Wizard that will show an empty set of input
>fields per these example images. Following the plan of SSL input I think
>I could get that far. However what is then needed is that these input
>values get translated into a set of Logix and Route entries. At this
>point in the process I have the feeling that it is beyond my abilities.
>The values are mostly related to the internal sensors used to create the
>panel interface, and the numbers that I have used in the examples are
>based on the plate numbers used for the location of the various icons.
>The graphical part of the Wizard screens is purely intended to give
>visual hints to the user, and not intended to be 'live' nor to show any
>actual information. The "left/right" radio button just switches the
>screen to match the direction of the plant that the user is currently
>entering. I did not include any fields for creating the linking Logix
>for driving turnouts or receiving sensor inputs. It would be helpful and
>probably should also be included, but it is also easy to explain how to
>do it for different systems. If anyone wants to tackle this project I
>would be glad to edit my mock up to include the extra fields. There are
>no direct links from the panel images to or from the layout due to the
>delays required for code unit sounds. (except for the turnout track image)
>I have experienced some sound glitches during operation. Sometimes when
>you press a code button it doesn't click properly, and also occasionally
>the code unit does not play when it should. Is this a known problem when
>playing sounds from Logix? Maybe I should have made an individual Logix
>for clicking each code button rather than one for all. ....I just did
>that change, and it helps, and it should be easier for the Wizard as well.
>As best as I currently understand the classic USS CTC panel, this
>example follows its operation quite closely. One thing I did not do was
>to serialize the code commands. It would have added a lot of complexity
>and increased the delays to the point of frustration on a model RR.
>Instead it just plays the sounds as if each plant had its own dedicated
>code line instead of a single line for everything per the prototype.
>(the result is that you can create a lot more clattering than the
>prototype ever did) <g>
>The 'time' feature for changing a signal indication in the face of a
>train is set to just 10 seconds in this demo. In actual operation it
>needs to be 20% longer than the time required for a train to pass
>through a block from one signal to the next.
>Am I on the right track, or is someone else working on a simpler
>solution? All I know is that manually creating all the Logix required
>for this job is not something for newbies to tackle.
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems? Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >> http://get.splunk.com/
>Jmri-developers mailing list
Bob Jacobsen, UC Berkeley
jacobsen@... +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG