I need to add this to the JMRI Help pages. There are two ways to do this in JMRI... If you want to use DCC to command a Stationary Decoder without using the DCC++ Base Station's predefined turnout feature (I think this is what you are wanting to do...) 1) Write down the address/sub-address for each turnout 2) Launch JMRI's PanelPro app. 3) In PanelPro, select Tools->Turnout Control 4) Enter the address of one of the turnouts and click Thrown or Closed. With a little luck it will "just work". To create more permanent turnout definitions in PanelPro, for use with a dispatcher panel, for example... 5) In PanelPro, select Tools->Tables->Turnouts 6) In the Turnout table, Add (use the "Add" button) each turnout, giving it the hardware address and whatever user name you want. 7) For each turnout in the table, click the Edit button 7-a) In the Edit window, select the FEEDBACK tab and set the feedback mode to DIRECT. Now, if you want to set up predefined Turnouts in the Base Station, you do things a little differently... 1) Write down the address/sub-address for each turnout 2) Launch JMRI's PanelPro app. 3) In PanelPro, select DCC++->Configure Sensors and Turnouts, and click on the Turnouts tab. 4) For each turnout, click "Add", then edit the new table row to put in an index number, the address and subaddress 5) Click "Save" and then "Close". The turnouts are now defined in the Base Station... To create definitions to use the predefined turnouts in PanelPro... 6) In PanelPro, select Tools->Tables->Turnouts 7) In the Turnout table, Add (use the "Add" button) each turnout. Set the "Hardware Address" to the Index number you used in the Configure table in step 4 above. Use whatever user name you want. 8) For each turnout in the table, click the Edit button 8-a) In the Edit window, select the FEEDBACK tab and set the feedback mode to MONITORING. A bunch of steps, I know.
Great. I want to use the second option, using the Base Station. Sorry, but what means index number, address and sub-address of turnout?
ID is just an index number between 1 and 32767 that you assign to the turnout. It's the number that the Base Station uses to "name" the turnout. The address and sub-address is the DCC address of the turnout. Exactly what this means depends upon the accessory decoder you are using. For example, a Digitrax DS64 can control 4 turnouts, so it responds to an address between 0 and 511, and then the subaddress (0-3) tells which of the four turnouts the DS64 is connected to. Some other brands of accessory decoders assign a separate address to each turnout connected to it, so they combine the address and subaddress into one number, using a bit of math: combined_address = (address * 4) + subaddress, giving a combined address between 0-2047. So, if your accessory decoder handles it the second way, with a separate address for each turnout, you can reverse the math... the address is combined_address / 4 (drop the fractional part), and the subaddress is the remainder of the division. Which accessory decoder are you using to drive the turnouts? If I know which one you are using, I can maybe give more specific directions. Anyway, in JMRI, you use the "Configure Sensors & Turnouts" dialog to tell the Base Station how to associate the Index number with the Address/Subaddress pair. Once that is done, JMRI uses the Index number (as part of the "hardware address" in the Turnouts table) to control the turnouts, and the Base Station translates that index number into an address/subaddress pair to control the turnout.
OK. I am using a 51802 SwitchPilot Servo belongs from ESU. It is in compliance with NRMA standard. In the past when it is used with Dinamis from Bachmann, to program turnout I just push the program button, set the number of turnout (by blinking of leds), and then adjust the velocity and the travel of servo with the help of two buttons + and -. It is the same procedure with DCC++ Base Station ?
If you are feeling adventurous, you can download the packages from the latest JMRI development Jenkins build here: http://builds.jmri.org/jenkins/job/Development/job/Packages/ No warrantees whatsoever about whether something else might be broken in the build, but my fix does appear to get the network connection working. One other problem I'm working on is that Gregg's change to the status message has broken the base station identification in JMRI. It doesn't really affect anything operationally, but you might get an error message when booting.
Ok... so to translate from the ESU turnout number to the Address/Subaddress for the Base Station... Turnout #s 1, 2, 3, 4 -> Address 1, Subaddress 0, 1, 2, 3 Turnouts # 5, 6, 7, 8 -> Address 2, Subaddress 0, 1, 2, 3 Turnouts # 9, 10, 11, 12 -> Address 3, Subaddress 0, 1, 2, 3 (etc.) You will note that the Address for JMRI is the same as the Address for the SwitchPilot, and the subaddress is the SwitchPilot output # minus 1.
TwinDad Possible Estop button inconsistency. 1st Throttle PC based JMRI running cab 1 2nd Throttle smartphone JMRI EngineDriver running Cab 2 &Cab 3 When I press estop on one throttle it only stops the cabs assigned to it Not all Cabs running through JMRI software. Platform; DCC++ 1.6.7 JMRI 4.3.2 R2edd195 Java 1.8.0_66 SurfacePro Win10 JMRI EngineDriver 2.11 GalaxyS5 Bug or as designed. Regards, Kevin
By design, the "STOP!" button on the software throttle and (I'm pretty sure) the emergency stop button(s) on the WiThrottle locos (including I believe both WiThrottle and Engine Driver) affects only the assigned locomotive. It's meant more as a "Oh no, my loco is headed toward that open lift gate!" rather than "Oh no! The whole layout has gone crazy!" button.
As Designed got it.. I only asked because when you hover over the estop button it says "Stops All JMRI Managed Throttles"' Thanks, KC
Hello all! I got my DCC++ supplies in the mail today (ArduinoUno and a clone of the Arduino Motor Shield), and after following the tutorial on the GitHub wiki page, I was up and running with JMRI! Great work, Gregg and TD (and others)! On a less important side note, occasionally while reading CVs JMRI will hang on a CV for a minute or so before returning a "Programmer error: Timeout talking to command station (306)". I'm guessing this happens when the loco momentarily loses contact while reading? I'm not certain on that, but I haven't noticed this issue with my DCS50. Any ideas? Andrew
Hey Andrew! Are you connected by USB? Generally the timeout error indicates that JMRI hasn't received a response from the Base Station... Since the base station doesn't send the reply until it has completed the read process, which can be somewhat slow. I may need to adjust the timeout somewhat...
What is going on with the builds server? I have been trying to download the linux version of the ethernet fix and I am not able to connect.
Yes, I am connected via USB. Ah, that makes sense. Normally the base station reads the CV nearly instantly, but when it loses contact with the loco (I think?), that's when it gets slow. A shorter timeout would be nice. Would it help if I programmed a CV to every possible value, one at a time, and read it back while timing it so we know how long it takes to read the longest possible value, and you could adjust the timeout to be a bit longer than that? Andrew
