|
From: john p. <pl...@us...> - 2009-06-30 22:41:58
|
Update of /cvsroot/jmri/help/en/html/apps/PanelPro In directory fdv4jf1.ch3.sourceforge.com:/tmp/cvs-serv1920/help/en/html/apps/PanelPro Modified Files: FAQ.shtml Log Message: Updated main page teaser to include info from #howto and #moreinfo, moved the rest of those sections to the technical homepage, added Jim Betz's overview to FAQ Index: FAQ.shtml =================================================================== RCS file: /cvsroot/jmri/help/en/html/apps/PanelPro/FAQ.shtml,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -d -r1.4 -r1.5 *** FAQ.shtml 5 Jun 2008 18:23:03 -0000 1.4 --- FAQ.shtml 30 Jun 2009 22:39:35 -0000 1.5 *************** *** 24,27 **** --- 24,131 ---- <h1>JMRI: PanelPro Frequently Asked Questions</h1> + <a name="context"><h3>How does PanelPro fit into the rest of my layout?</h3></a> + <p>Jim Betz provided this overview when asked for an overview:</p> + + + <ol> + <li> JMRI works like a throttle - it sends and listens to the + messages on the "command bus". Nothing more, nothing less. + And that is actually - A LOT - and is the true beauty of + JMRI. + In the case of DecoderPro the commands that are being used + and monitored are those related to programming a loco. In + the case of PanelPro the messages/commands that are being + used are those pertinent to block occupancy, turnouts, etc. + + <li> Each system has its own "command bus" or "computer + interface" - i.e. its own + set of commands (think 'command format') that it uses. This + is why you can't use a Digitrax throttle on an NCE system. + Many people refer to the command bus as a "throttle net" - to + distinguish it from the track bus. And it is important to + note that the messages on the two are not identical in all + cases. + Some systems are similar enough to each other in order to + make it possible to use a throttle from one on another ... + but this is relatively rare (very few layouts actually make + use of it). + Another solution is CMRI - which has its own command set. + JMRI also is smart enough to "speak CMRI" (as well as the + ability to "speak" Digitrax and NCE and Lenz ... etc.) The + difference being is that CMRI is a command set and hardware + that is focused only on the RR support systems (signals, + turnouts, etc.) and does not have the ability to control + or program trains. And, in point of fact, does not "know" + whether the layout is DC or DCC. Most of the layouts that + have implemented CMRI recently have used the CMRI hardware + and JMRI (PanelPro) for the human interface. + + <li> On DCC layouts the command station is the interface + between the track and the throttle/command bus. You use + the throttle bus to acquire a loco ... and to send control + messages to the command station - which 'forwards' your + throttle changes to the locos ... and to the stationary + decoders ... via either the track -or- command bus (or + both). + + <li> It is possible - some will even say desirable - to separate + your train support (track bus) from your layout control support. + Although it may not be intuitive - you don't have to use the + same system that you use to control trains to control the + turnouts and signals - simply because messages don't need to + cross that boundary. This is why some have recommended you + consider an environment such as NCE for the trains and CMRI + or Digitrax for the layout support (PanelPro). + + <li> Because Digitrax and CMRI have published their interfaces + there are more products available for layout control for + those two systems than for NCE. Both RR-Cirkits and + Team Digital have excellent products out that work for + Digitrax (for instance). As far as I know there are no + such products for NCE. I do not know what is/isn't + available for Lenz. + + <li> PanelPro is still developing at a rapid rate. Many layouts + are already up and running using PanelPro - but the most + recent developments that have just recently been made + available in PanelPro make using it a -lot- easier than it + used to be. Actually, if you are talking just turnouts and + block occupancy then PanelPro has been usable for some time. + Signaling is getting better all the time. + + <li> When you start doing signaling then "everything changes". + Because signaling requires that the block occupancy and + turnout status be used in the decision process of "what + aspect should be displayed on which signals at this point + in time". This requires layout specific code/logic. + I'm assuming that you want a computer to make these + decisions. It is possible to implement a system where a + human being, usually the dispatcher, does all of the + decisions ... the more complex the layout/signaling system + the more errors the dispatcher will make. And there is + also the "workload" issue(s) ... but a computer running + PanelPro is usually loafing and has more than enough + power to keep ahead of the needs of the layout. + <p> + Implementing layout control (turnouts, block occupancy, signals, + etc.) is not an "easy deal". And, in my opinion, it is not + something you should attempt to teach yourself - or to do it alone + with just the help/guidance of online lists such as this one. I + am not saying "don't use online" ... I'm saying that if you want to + do this as easily as possible then you should seek out those who + have gone before and enlist their face-to-face support/guidance. + Yes, you can do it your self - no, that's not the best way to do + this and you will find you make -many- mistakes that will cause + considerable delays and rework. Many layout automation projects + have gotten stalled for just this very reason. + <p> + And just so this gets mentioned ... adding capabilities such as + block occupancy detection, computer controlled turnouts, and signals + is not inexpensive and needs to be budgeted/spec'd out. And you + may find that you will need to re-wire some or even major portions + of your layout in order to support them correctly/at all. + </ol> + + <a name="store"><h3>How do I save my work?</h3></a> |