For turnout control I am considering JMRI as the central controller with fascia panel switches connected to JMRI (using C/MRI RS485) and being read as inputs. And JMRI controlling outputs to the turnouts also over C/MRI to servo controllers. My questions: 1. what type of switches can be used for above purpose? A. per turnout 2 pushbuttons, one for each direction (and 2 JMRI inputs)? B. per turnout 1 pushbutton, toggling between directions (and 1 JMRI input)? C. DPDT or SPDT ON - ON switches, one tab per direction (and 2 JMRI inputs)? D. Others? 2. When receiving a signal on a JMRI input, how are outputs best be triggered/handled for turnout control? A. If per turnout two inputs, JMRI handles two corresponding outputs per turnout, one for each direction? Pulsed or permanent? B. If per turnout two inputs, JMRI handles one corresponding output per turnout, high level for one direction, low level for the other direction? C. If per turnout one input, JMRI handles the corresponding turnout over 2 outputs? Or over one output? If JMRI can handle pulsed outputs for turnout control, can the pulse length be programmed? Or is it better practice to send either high or low signal level on a control line? And if so, would it be better to use two outputs per turnout, one for each direction? And have both lines either LOW/HIGH or HIGH/LOW, depending on direction? Or are there better ideas?
I've never looked into C/MRI much but I would suspect you could use any of the listed methods. I know that with DCC accessory decoders that have input ports, all of these options are available - not on all decoders, but there are decoders that support each option. Different people have their preference, so I would just pick the one you like and go with it. One thing to keep in mind if considering a toggle switch - the advantage of the toggle is it normally shows the alignment of the turnout, but if you throw the turnout from somewhere else, i.e. a throttle or computer, the toggle direction will no longer match the turnout direction. Again, not familiar with C/MRI, but I suspect the logic works similar to DCC. When controlling DCC turnouts JMRI simply sends a command - "thrown" or "closed". Whether the output is pulsed (and for how long) or constant, bipolar or unipolar, or even PWM for servo control, is all handled by the decoder.
Hi Roberrt, thank you for your extensive reply; I know the decoder option, but as stated in OP I prefer to use C/MRI concept because: 1. proven data bus concept (RS485), simple and effective 2. I already have C/MRI hard- and software available 3. JMRI support On point 3 I have a number of questions stated in OP; they relate to the way a fascia panel should interface with JMRI and to the way JMRI handles turnout output.
Attached are notes on how I used JMRI LogixNG to set turnouts and LEDs on a mimic panel. Momentary contact buttons appear as sensors to JMRI and LogixNG toggles the turnouts and sets LEDs. The MCP23017 output pins for LEDs were included in the JMRI turnouts table. Note the related Closed/Thrown terminology for LEDs with LogixNG: If Sensor D2S167 is Active (Button pressed) Then set turnout DT34 to state ToggleIf Turnout DT34 is closed Then set turnout D2T174 to state Closed (Green LED on) Else set turnout D2T174 to state Thrown (Red LED on) With the LEDs controlled thru JMRI LogixNG, they will remain consistent with the turnout. Diode circuit enables a single output pin to switch the LEDs between Red/Green. (Two 1N4148 diodes in series.) 470R resistor was selected as I have 5V power on the board. Darlington transistor array ULN2803 provides switching to GND. Wiring and LogixNG is also applicable to CMRI. These notes are from testing with DCC++EX as accessory controller, using JMRI Ethernet/WiFi connection DCC++2. The primary DCC++EX command station with motor board is USB connected. Turnouts could be connected to JMRI via CMRI, DCC++EX, or other methods.
To be clear, I wasn't advocating that you use DCC, I was using it as a reference to describe the general logic of turnout control in JMRI. Again, I would expect the C/MRI logic to be the same as or similar to DCC, but it is possible that the C/MRI hardware is more rudimentary, requiring more complex logic from JMRI.
If I understand correctly you use a single momentary pushbutton to toggle a signal to JMRI? And in turn JMRI decides to throw a turnout in a different state than the previous state (and corresponding LED)? 6 Red LED's on PB2-PB7; what about the green LED's? Why 5 buttons but 6 red LED pins? Do you use active = 5V? How/where is DT34 linked to D2T174? Where is the designation "D2T174" derived from? A single input drives either a green or a red LED: is this a bistable circuit (ie bistable multivibrator)?
Yes I understand that my concept places a higher load on JMRI then if DCC were used. It is a bit of my conceived idea that I would like to give more centralised control via JMRI for accessory control. I know this goes against DC++ EX philosophy, but I am still in pre planning stages for my layout control, so things may evolve. And I love Ash's approach to accessory control, as well as his use of the MCP23017 chip which is a very powerful yet approachable "piece of hardware".
Refer to the PDF for an example of what the two LogixNG records will show. The momentary pushbutton is a sensor to JMRI. LogixNG 'Always Execute' is watching the sensor for the Active state and then Toggles the turnout state. LogixNG 'Execute on Change' sees the turnout change, and sets the pin assigned to MCP23017 (for the LED). When the Red LED is on, the Green LED is off. (see below) There is one crossover, controlled by one button. But it has two turnouts and two red LED pins. The LogixNG will set two pins. I could have used a separate power supply for the LEDs, but decided to adjust the resistor so that 5V could be used to supply power to both the Arduino and the LED's -- but I avoid taking the power from a pin on the Arduino. D = first DCC++EX Arduino connected via USB D2 = second DCC++EX connected via WiFi (select JMRI Ethernet) 34 = turnout ID 174 = ID of virtual pin as defined in mySetup.h SETUP("<Z 174 174 0>"); DCC++EX has the first MCP23017 pre-defined to use virtual pins 164-179. When you use CMRI, your JMRI IDs will be as you have defined them. While JMRI logic could be used to switch each LED separately, the Green LED’s higher forward voltage drop means that turning on the Red LED will automatically turn off the Green LED. Look about one-third down this link for the solution I found: Simple circuit that alternates between Red and Green LEDs with only a single switch & resistor: https://electronics.stackexchange.com/questions/121038/alternating-between-two-leds-using-bjts
1. For the red/green LED's, is this the circuit used? 2. With "active" I mean that pushing a button gives 5V to JMRI, released button = 0V to JMRI? 3. Do you give a default (start-up preferred) state (thrown or straight) to each turnout? I.e. by means of wiring, for each turnout, give each of them either straight or thrown status? 4. I have one 3-way Wye turnout with 2 motors, which would need following logic on the motors: 10 utmost left 11 center 01 utmost right 00: must be forbidden because the legs for left and right contradict each other Is it possible to generate this logic in JMRI?
I think he meant the next one down (the circuit one the right): The one on the left can be used with a switch, but with a digital output you would need the one on the right. The circuit you posted would also work, but this one is a little simpler (one less transistor). This circuit relies on the different voltage drop of a red LED vs. a green LED, so if you wanted to use two LEDs with the same voltage drop you would need the circuit you posted (or you could use this one with an added diode to increase the voltage drop of one LED).
1. @CSX Robert is correct on the circuit I started from. One pin is used from MCP23017, with Darlington transistor to switch Red LED to GND. Two diodes added between Green LED and GND. 2. With sensors, JMRI tables show Active/Inactive state. There is a checkbox to invert, as some sensors are inactive when high. 3. I would prefer that sensors do not move at startup. - JMRI has a jython script available, which can save sensor state at shutdown and restore state at startup. Since the LED's are in the Turnout table, the LED's state should also be restored. - I have a separate power supply for the +5V on the PCA9685 for servo turnouts, and turn it on after the rest of the system is started and the sensor states are initialized. - And sometimes it all works as planned; sometimes I turn on turnout power too soon. - Where I am today; quite likely to be different as I work on route automation. - With my DCC++EX EXRAIL based mimic panel, I set turnouts closed at startup and use one pin for each LED. No JMRI LogixNG, unless you will use JMRI to relay the EXRAIL turnout info -- so that JMRI can set the turnout connected by CMRI, etc. (file attached) 4. No experience with 3-way Wye.
You mean "turnouts"? I found the same: when starting up power on a controller linked to PCA9685 then the connected servo's move if power and control are connected same time. Is this the reason you apply servo power, delayed, after startup? Would there be no way to be able to apply servo power without delay and without this initial movement?
You are correct. Turnouts. I have 4 power switches: 1. CMRI Arduinos (RS485) and DCC++EX mimic panels (WiFi) 2. RPi3b JMRI and DCC++EX command station (USB) 3. DC power supply for tracks 4. Turnouts/LEDs In the EXRAIL example, turnouts are set CLOSED at startup, and some will cycle. With CMRI, the servos may cycle when CMRI sketch initializes, and some will move again when the JMRI script is run to restore turnout state. So I delay power. I am open to suggestion.
Hi Ash, I could not quiet figure out how the following would work in your setup: 1. do you program your servo control for slow movement? 2. can you, if at all, program routes, ie with the push of one button move more than one servo? PS: applying servo power without delay and without unsollicited movement, if even you throw in the towel, I for sure would not find it.
Erik. You give me too much credit. I have slept since working with servo turnouts, in the CMRI sketch. I do recall that whatever I did was not optimum, but got the turnouts working. One day I may update the CMRI sketch for some of the capabilities in DCC++EX. When using DCC++EX as accessory controller, there are parameters which define turnout speed. The transition between states is defined by PROFILE, as 0 (immediate), 1 (fast=0.5 sec), 2 (medium=1 sec), 3 (slow=2 sec) or 4 (bounce, for semaphore signals). https://dcc-ex.com/reference/software/command-reference.html#defining-setting-up-a-turnout There are also turnout definitions available in EXRAIL automation which include a description field, which is shown when Engine Driver connects directly to a DCC++EX command station. https://dcc-ex.com/automation/EX-RAIL-summary.html#automations-routes-and-sequences --- and to trigger multiple turnouts with a single button, I might use JMRI LogixNG. EXRAIL automation could also be used for this.
