Introducing DCC++ ---a complete open-source DCC station and interface

Gregg Aug 25, 2015

  1. KE4NYV

    KE4NYV TrainBoard Member

    219
    281
    17
    Mark, thanks for the suggestion. I didn't realize this would be much of an issue because I assume most people have the Uno/Mega connected to a computer for JMRI/Gregg's Software control, so the +5VDC is already there via the USB buss.
     
    Scott Eric Catalano likes this.
  2. Gregg

    Gregg TrainBoard Member

    237
    311
    18
    I think a regulator would be very useful when using an Ethernet Shield or Wifi Shield, in which case you would only be using the serial cable for power. On my own layout I have a separate 12v supply for lights, sensors, and the Arduino itself. Why 12? I have no idea. At some point I must have bought a 12v accessory. But 5v would be just as fine.

    -Gregg
     
    Scott Eric Catalano likes this.
  3. Keith Tucker

    Keith Tucker New Member

    3
    3
    1
    Gregg
    I have found the DCC++ on YouTube and got the information off GitHub and setup my test N gauge layout and connected it to a ARDUINO Mega with Arduino Motor Shield and setup the DCC Controller on my laptop. The system is all working well and i think it is brilliant. I am currently converting the Controller layout map to my layout and track configuration. What I have been using was an EZ Command and wanted to upgrade but what I looked at seemed a bit too costly. But as I already had ARDUINO I started to look that way, and I found your answer to the problem which I think is superb. I am looking forward to the videos from you for answer on how to change the setup.
     
    Last edited: Jan 1, 2016
    Scott Eric Catalano and DwayneG like this.
  4. mayhaw9999

    mayhaw9999 TrainBoard Member

    27
    28
    5
    Gregg, et al.,

    Having problems. You may recall that I was concerned about my power supply having excess voltage. I ordered a LM338T regulator and now have a functional power supply set at 16.5 volts. When I finally got everything wired up and connected to my module that has two separate tracts for testing, I'm not getting track power from the Pololu shield. 0 volts on each output.

    I have double checked the wiring and the jumpers, everything seems to be in order. I have proper serial connection from both the Base Station and the Controller. Both indicate that track power is on and can be turned off. I tried with the original power supply that had worked in the past, still no luck.

    I have recycled the programs and the computer and downloaded the software again – nothing has helped. Anyone have suggestions about what I can check further? I do have an old Uno that I can breakout and try; the Mega is a clone I got through Amazon that has been working well until now.

    Was really hoping that I could get things working tonight!



    David
     
    Scott Eric Catalano likes this.
  5. Keith Tucker

    Keith Tucker New Member

    3
    3
    1
    I had problems to get my Base Station to start, Main track output on the Arduino Motor Shield came up with two lights but the Programming track output only had one light. My MEGA was also a clone through Amazon from SINTRON and my next step was to remove the DCC++BaseStation and Controller and uninstall all reference to the Programme.
    Then downloaded the zip files and Extracted a complete new set of files which when installed worked for me, so somewhere i think i must had currupted something.

    Keith.
     
    Scott Eric Catalano likes this.
  6. Gregg

    Gregg TrainBoard Member

    237
    311
    18
    David, just to confirm - you had the system working with a different power supply and when you switched to the new supply it stopped working? If you've re-downloaded and re-installed the Base Station software, note you'll need to change the the settings in Config.h once again to reflect the Pololu (the default is for the Arduino Motor Shield). Also, do the lights on the Pololu near each output turn on when you send a <1> command?

    -Gregg
     
    Scott Eric Catalano likes this.
  7. mayhaw9999

    mayhaw9999 TrainBoard Member

    27
    28
    5
    Hi Gregg,
    Yes, the system was working before I changed to the new supply, but the voltage was too high with a 20 V input to the Pololu. The lights on both outputs would light up. I decreased the voltage temporarily with 3 diodes in series - the output lights worked ( I had not been able to get a Loco moving - other issues may have been present) . The new supply is the same 20V switching supply run through an adjustable regulator. The regulator is set at 16.5V as measured at the Pololu input. The power LED on the Pololu is lit. I did take out the regulator supply and tried the original setup. No output lights.
    I downloaded the Base Station software, changed the Config.h setting for the Pololu, reloaded it to the Mega and both the Base Station and Controller programs report serial connection . When I turn power on with the Controller, it reports "Track Power On". The Base Station gives me the proper indication that it is communicating with the <1> command. The lights don't turn on with either.
    My thought is that I have a hardware failure, probably on the Mega side. I can try my old Uno board. I reviewed the different connections that need to be made on the Pololu and that won't be a problem. What do you think?
    David
     
    Scott Eric Catalano likes this.
  8. TwinDad

    TwinDad TrainBoard Member

    1,844
    551
    34
    No, I have not stopped development, per se. I am working on getting my wireless shield to work... I need a bigger power supply, and some budget issues have slowed me down.

    I guess I could tidy up the code and publish it, in case one of you who has a working wifi shield would be willing to test it for me and provide debug info...
     
    Scott Eric Catalano likes this.
  9. esfeld

    esfeld TrainBoard Member

    442
    382
    17
    I have a working set-up and an Arduino Wireless shield. I can give it a full test when you are ready.
    Steve
     
    Scott Eric Catalano likes this.
  10. HVT

    HVT TrainBoard Member

    74
    93
    15
    Gregg, TwinDad, et al,

    While waiting for the Mega boards and Pololu motor shield to arrive I started a pin-out list to help keep track of which pins on the multiple Megas do what. I anticipate ending up with 7 Megas and 2 Pololus. Each section (module) of the layout will have its own Mega which will handle the local turnouts/sensors/signals. The layout is divided into 3 power districts with the Pololu on the Master Mega powering staging and the helix, and the second Pololu powering districts 2 and 3. The only connections required between modules (I believe) are the power bus, i2c bus and a common ground between boards.

    Gregg mentioned creating a "serving code" sketch for the additional Megas and I'll have to wait for that to firm up pin assignments on the satellite board with the second Pololu. (No pressure, Gregg) Also the JMRI address DCCPPxxx as I understand it is shown on pins that are outputs or inputs, different than the LTxxx and LSxxx used with LocoNet.

    Here's the list. Please review it and feel free to make any corrections, additions or suggestions.

    Mega board 1 - Master
    Pin # - Description
    0 - Rx to USB
    1 - Tx to USB
    2 - Jumper to pin 8 - DCC signal pin programming
    3 - Digital I/O
    4 - Jumper to VDD 5v+
    5 - Digital I/O
    6 - Digital I/O
    7 - Jumper to pin 12
    8 - Jumper from pin 2
    9 - Signal enable main - Power district #1
    10 - Signal enable programming track
    11 - Digital I/O
    12 - Jumper from pin 7 - DCC signal pin main
    13 - Digital output (JMRI DCCPP13) - Signal head 1 red LED (typ)
    14 - Digital output (JMRI DCCPP14) - Signal head 1 yellow LED (typ)
    15 - Digital output (JMRI DCCPP15) - Signal head 1 green LED (typ)
    16 - Digital output (JMRI DCCPP16) - Servo turnout 1 (typ)
    17-19 - Digital I/O
    20 - i2c SDA data
    21 - i2c SCL clock
    22-53 - Digital I/O
    54 - A0 - Current monitor main - power district #1
    55 - A1 - Current monitor programming
    54 - A2 - Analog input - (JMRI DCCPP54) - block detection current sensor (typ)
    55-69 - A3-A15 - Analog input - or - Digital I/O

    Mega board 2 - satellite board 1
    Pin # - Description
    70 - Rx to USB for updating sketch
    71 - Tx to USB for updating sketch
    72 - Digital output (JMRI DCCPP72) - Servo turnout 2 (typ)
    73-89 - Digital I/O
    90 - i2c SDA data
    91 - i2c SCL clock
    92-123 - Digital I/O
    124-139 - A0-A15 Analog input - or - Digital I/O

    Mega board 3 - satellite board 2 with Pololu board 2 attached
    Pin # - Description
    140 - Rx to USB for updating sketch
    141 - Tx to USB for updating sketch
    142-152 - Waiting for "Serving sketch" to make pin assignments.
    153 - Digital output (JMRI DCCPP153) - Servo turnout 2 (typ)
    154-159 - Digital I/O
    160 - i2c SDA data
    161 - i2c SCL clock
    162-193 - Digital I/O
    194 - A0 - Current monitor main - power district #2
    195 - A1 - Current monitor main - power district #3
    196-209 - A2-A15 Analog input - or - Digital I/O

    Mega boards 4-7 follow the numbering scheme of board #2

    Again, thanks to Gregg for creating such a great program and to TwinDad for adapting JMRI to work with DCC++.

    Dave (HVT)
     
    Scott Eric Catalano likes this.
  11. mayhaw9999

    mayhaw9999 TrainBoard Member

    27
    28
    5
    Gregg,
    Here is an update. I decided to get a new genuine Arduino Uno and redo the shield for it according to your directions. Now I have power on the programming output (lights lit) but not on the main. Voltages 16.5 VDC input, 17.5 VAC on the programming track and 0 on the main. I have serial connectivity from both the Base Station and the Controller.

    David
     
    Scott Eric Catalano likes this.
  12. markwr

    markwr TrainBoard Member

    339
    6
    11
    I haven't received the Pololu shield I ordered yet but the Arduino Mega 2650 showed up today. I was playing around and got the Arduino code uploaded and tried playing around with the interface. Should the turnout displays on the controller appear to function with just the Arduino present?
     
    Scott Eric Catalano likes this.
  13. lnxlnx

    lnxlnx TrainBoard Member

    24
    20
    7
    @markwr

    As DCC is a one way protocol (excluding programming), every command you issue will be sent successfully by the Arduino; it has no idea what is connected, it is just manipulating a set of pins on the Arduino and recording the fact that it was able to do so and feeds that back to the Controller software. It doesn't know that you haven't connected it up or that you don't actually have any turnouts for example if you were using Gregg's layout plan in the controller.
     
    Scott Eric Catalano likes this.
  14. Gregg

    Gregg TrainBoard Member

    237
    311
    18
    It's actually a "one-and-a-half" way protocol. It is correct that the Controller only knows about the Arduino, and not whether or not the Arduino is actually connected to a railroad (with the one exception, as you correctly noted, that reading/writing CVs on the programming track will return an error if no programing track exists). As long as the Controller is correctly communicating with the Base Station software, it will operate as if a model railroad is connected.

    However, many of the DCC++ commands are two-way because once the Base Station receives a command, it sends immediate feedback to the Controller. The Controller is designed to only update its own status based on feedback received from the Base Station. This provides for a much more stable operation, allows for storage of certain settings within the Arduino EEPROM, and also enables the automatic synchronization of multiple interfaces when connected to the Base Station at the same time (can only do this via Ethernet/Wifi, not serial -- but it's really cool to change a turnout on one interface and see it update on the other, or change the throttle for two different cabs at the same time and see them update on both interfaces).

    After a new install of both the Controller and Base Station, the Controller's POWER Button, CAB Buttons, and THROTTLE, should all operate correctly provided communication between the Controller and Base Station is operating correctly. This is because: (a) Base Station is hard-coded to provide feedback for the POWER Button (which is a special function); (b) feedback is not needed to just select a CAB Button (the CAB Button will light even without Base Station); and (c) feedback for the THROTTLE is automatic and not tied to whether or not a given CAB really exists --- Base Station keeps track of the internal registers to use for each Cab's Throttle setting, but does not index this, and thus does not care about the actual CAB Address (it's actually built into the THROTTLE command).

    BUT... TURNOUTS are a bit different. Though a turnout is nothing more than an accessory with a pre-defined stationary DCC address, TURNOUTS in Controller are set up to utilize feedback from the Base Station software. This feedback is not generic --- Base Station needs to be aware of every TURNOUT it is being asked to operate through the Controller's TURNOUT command (if you operate turnouts just using the Controller's Accessory Window, Base Station simply passes that through and no feedback is needed). The rationale behind this logic is that Base Station can keep track of the status of each TURNOUT and store this data in its EEPROM so that after the power is shut and turned back on, Base Station can read each of the TURNOUT'S settings from the EEPROM and send that to the Controller upon initialization of communication so that all the TURNOUTS in the interface are updated to reflect their actual status. Also, since turnouts are not something you add and subtract from a layout on an every-day basis (unlike, perhaps, adding/removing a new locomotive), it makes sense to have Base Station be aware of as many "static" portions of the model railroad as possible.

    Which means that Base Station must be "programmed" with a list of TURNOUTS to control. In the original version of the software, a list of TURNOUTS IDs and their corresponding stationary DCC addresses were hard-coded into an array in the main Dccpp_Uno.ino file. But this was less than optimal because it meant having to change the actual software whenever a new TURNOUT was added, or an existing one was edited or deleted. This also makes distributing an open-source version of Base Station tricky since it would have my layout-specific data hard-coded into the system.

    The latest version of Base Station does away with the hard-coded array list of TURNOUTS, and instead adds extensions to the <T> command that allows you to create/add/edit/delete TURNOUT definitions in Base Station dynamically through the Arduino IDE Serial Monitor window. Please see the comments in the Accessories.cpp file for details on how to use the different forms of the <T> to create your own TURNOUT definitions. Once all TURNOUT definitions are created, you then use the <E> command (see the SerialCommand.cpp file for instructions on this) to save these definition in the Arduino's EEPROM. You can always add/delete/change and re-save these definitions in the Arduino any time you want. More so, you can update the Base Station code without disturbing the contents of the EEPROM, which means new functions can be added to the master code base that you can use without having to re-define all your TURNOUTS.

    Once TURNOUTS have been defined via the <T> command and stored in the Arduino EEPROM using the <E> command, Controller will receive feedback every time it sends a <T> commands to the Base Station using an ID that matches one of the pre-defined TURNOUTS. Since a fresh Arduino does not have any TURNOUTS stored in it EEPROM, Controller TURNOUTS will not yet appear to operate in the interface.

    Unlike Base Station, which is quite generic, Controller is indeed hard-coded to my layout. I hope to create a more generic (and dynamically-editable) version of Controller in the future, but for now the code needs to be modified to match your own layout and turnouts. If you just want to see how the TURNOUTS that come with Controller work with the Arduino, you'll need to first define those TURNOUTS in Base Station as per above (a new function in Controller that does this automatically would of course be very helpful, and it's something I'll put into a upcoming version).

    Every TURNOUTS definition has three components: an ID, a DCC Address, and a DCC SubAddress (this is the way NMRA stationary decoders actually work, though normally these two addresses are combined into one in commercial DCC systems). Within the Controller codebase, if you look in controllerConfig.pde starting at line 513 you'll find all of the TURNOUTS. In Controller they are called TrackButtons, and each TrackButton takes three parameters: the first is the height of the button, the second is the width, and the third (the important one) is the ID. It's this ID that Controller will send to the Base Station as part of a <T> command when you activate the TURNOUT on the screen. For each TURNOUT defined in Controller, you'll need to define a TURNOUT with the same ID in Base Station. Since these are just "hypothetical" turnouts, when you define them in Base Station you can just make up an Address and SubAddress for each (of course these DO matter if you actually have real turnouts connected to stationary decoders!).

    Note that instead of looking through the code to find the IDs of each TURNOUT defined in Controller, you can also control-click on any of the TURNOUTS in the interface and Controller will provide you with the ID by showing you the name on top of the screen. TURNOUTS have automatically-generated names of T-ID (e.g. a TURNOUT with an ID of 20 is named T20). If you control-click a TURNOUT to find its ID, you can then optionally look in the controllerConfig.pde file to find that ID in one of the TrackButton declarations to see how I included the tracks that make up the given TURNOUT.

    A few final points in this very long posting... First, if you use Controller in "Emulator" mode (selected through the Arduino Port window which is opened by hitting "s" in Controller), all TURNOUTS will always appear to operate. This is because in emulator mode, the "simulator" always provides feedback for all TURNOUT IDs -- no need to define them in a "simulated" Arduino EEPROM :). Also, you may be curious as to why there there are no location parameters for the TURNOUTS when defined in controllerConfig.pde using the TrackButton class. This is because the TrackButton class determines the location of the actual button (which is itself invisible on the screen), by determining the center point of all the tracks you include in the TURNOUT. It's what makes creating TURNOUTS so each in Controller -- they are just collection of overlapping tracks of any size of shape -- no need to have a list of real-world components or parts libraries since this is just a graphical representation of a layout, rather than an actual model of the design.

    Hope this helps!

    -Gregg
     
  15. Gregg

    Gregg TrainBoard Member

    237
    311
    18
    David (mayhaw9999),

    Since its not uncommon for user to have initial problems with configuring the Base Station, I added a new diagnostics <D> command to the Base Station code that will help in debugging issues. Here's the steps I would recommend:

    1) Remove the Motor Shield ---we are going to test just the Arduino first.
    2) Download and install the most current version of Base Station from GitHub (not the latest named release, which is about a week old, but rather the latest version with the new commit I just uploaded this morning).
    3) Open the Serial Monitor Window in the Arduino IDE and establish communication with the Arduino.

    Next, we are going to utilize the built-in on-board LED attached to pin 13 to test the Arduino and Base Station code. This series of tests only works if you are NOT using pin 13 for any sort of output (using it as an input is okay).

    4) Connect a jumper from pin 13 to whatever pin you have defined (or was already defined in the software) for SIGNAL_ENABLE_PIN_MAIN
    5) The LED next to pin 13 should go off (or remain off, if it was already off)
    6) Send a <1> command to turn on track power --- the LED should go on.
    7) Send a <0> (that's a zero) command to turn off track power --- the LED should go off.
    8) Repeat this a few times to check for robustness.
    9) Assuming this works, now perform the same test for the the programming track by connecting the jumper from pin 13 to whatever pin is defined for SIGNAL_ENABLE_PIN_PROG.

    If either of these tests fail, first review the DCCpp_Uno.h file to make sure you are indeed testing the right pins and matching SIGNAL_ENABLE_PIN_MAIN and SIGNAL_ENABLE_PIN_PROG. If one or both of these pins is not able to control the LED attached to pin 13, there is likely something amiss with the Arduino itself.

    If both tests pass, it means the Arduino should be able to correctly enable/disable track power, at least from its perspective.

    Now the fun part -- we are going to test the generation of the DCC signal itself.

    10) Move the jumper once again so you are now connecting pin 13 to whatever pin is defined as DCC_SIGNAL_PIN_MAIN.
    11) The LED next to pin 13 should go on, regardless of whether track power is set on (<1>) or off (<0>). Track power control does not alter the actual DCC signal generation on the Arduino.
    12) Now send a <D> command to the Arduino --- this SLOWS DOWN the entire system clock by a factor of 256, and also slows down the speed of the timers generating the DCC signal.
    13) The LED next to pin 13 should now be blinking --- mostly fast, but sometimes a little slower for just one or a handful of blinks. This is the actual DCC signal. Fast blinks represent a one-bit, slow blinks represent a zero-bit.
    14) You'll note that once you send the <D> command, the Arduino will respond with a message indicating "Entering diagnostic mode..." This is the last communication you will be able to send or receive while the window is open. To re-establish communication and reset the clock speed you will need to close and re-open the window, or cycle power on the Arduino, or hit the reset button on the Arduino. But don't do that just yet.
    15) Repeat the test for for programming track DCC signal by moving the jumper to connect pin 13 to whatever pin is defined as DCC_SIGNAL_PIN_PROG.
    16) You do not (actually cannot) need to send the <D> command again --- the Arduino will still be in diagnostic mode unless you've close and re-opened the window.
    17) As before, the pin-13 LED should now be blinking. The program-track DCC signal defaults to the same as the main-track DCC signal when the system first starts so the blinking pattern of ones and zeros should be the same. However on the UNO (but not the MEGA), the entire pattern will be twice as fast for the programming track than for the main track DCC signal. This is not normally the case, but the diagnostic mode can't slow the two signals down to the same rates on the UNO.

    If either of these tests fail, first review the DCCpp_Uno.h file to make sure you are indeed testing the right pins and matching DCC_SIGNAL_PIN_MAIN and DCC_SIGNAL_PIN_PROG. If you are and one or both of these pins is not causing the pin-13 LED to blink, then that suggests there is something wrong with the Arduino timers or interrupts. But before drawing that conclusion, run the entire test a few more times to double-check, since the new diagnostic command is...well, new.

    If both tests pass, then the Arduino is functioning correctly and it's time to test the Motor Shield.

    18) Power down the Arudino
    19) Install the Motor Shield, and make sure it has power, though do not connect to the tracks
    20) Verify that all of the mappings are correct, and that the signals on the Motor Shield are properly being mapped to the enable and signals pins you identified above.
    21) Open (or re-open) the Arduino Serial window
    22) Send a <1> command.
    23) All 4 lights next to the outputs of the Motor Shield should be on
    24) Send a <D> command to enter diagnostic mode
    25) All 4 lights should now be blinking --- the two attached to one output channel should blink in alternation, and the two attached to the other output channel should also blink in alternation.

    If neither of the LEDs attached to one of the output channels comes on when you send a <1> command, this indicates you are not correctly mapping either the SIGNAL_ENABLE_PIN_MAIN or SIGNAL_ENABLE_PIN_PROG pins from the Arduino (depending on which output channel does not appear to be working). From the above tests, we know those pins on the Arduino are working, so it must be in the wiring or jumpers between that Arduino pin and the pin used to enable to the Motor Shield for that channel (if indeed a wire or jumper was needed at all).

    If only one of the LEDs attached to the one of the output channels comes on when you send a <1> command, but the other does not, this suggests that either the DCC signal is not getting through to the Motor Shield, in which case it is a mapping/wiring/jumper problem, OR that the signal is getting through but the H-bridge on the Motor Shield itself is not functioning (and the Motor Shield may need to be replaced). To see which is the case, check whether the lone-LED begins to blink once you send the <D> command. If it does not, that indicates that problem is in mapping the DCC signal generation pin (which we know is working from the above tests), to the Direction pin on the Motor Shield. If the lone-LED does start to blink after sending a <D> command, but the opposing LED does not blink in alternation, then something is wrong with the Motor Shield and it likely needs to be replaced.

    I hope this helps with your diagnosis --- please let us know what you find.

    -Gregg
     
    bigsmooth, KC Smith, ISCOLD and 2 others like this.
  16. w8one

    w8one TrainBoard Member

    89
    109
    5
  17. Malahini

    Malahini TrainBoard Member

    26
    14
    7
    Thank you. I received all the components this week and look forward to diving into the deep end. Hoping all the work you guys have done will flatten the learning curve a bit :)

    Neil
     
    Scott Eric Catalano likes this.
  18. HVT

    HVT TrainBoard Member

    74
    93
    15
    How difficult will it be to create a DCC++ “Jump Throttle”?

    The objective is a simple Arduino based wireless throttle for grandchildren and guest operators. The concept is based on the Digitrax Jump Throttle that uses an analog signal from a DC controller to operate a loco which is assigned from the command station.

    The physical part, phase one, would be a project box with a linear pot connected to an analog pin on the DCC++ Arduino for throttle speed and a couple of switches connected to digital input pins for direction and horn.

    In JMRI an existing throttle window could be modified to accept speed inputs from the Arduino analog pin and F1 & F2 inputs from the Arduino digital pins. The DCC++ jump throttle window would be opened, a loco selected, and any desired F keys activated from a computer running JMRI.

    In Controller a small window might be added where the loco can be selected.

    Once the wired jump throttle was working the next phase would be to make it wireless. One method would be to use a pair of Moteino (Arduino with built-in wireless) boards similar to the remote control loco project shown by Geoff Bunza in the Nov 2014 MRH beginning on page 93. The battery powered transmitting board is in a handheld project box. Rather than being installed in a loco the receiving board PWM output would go to the DCC++ analog input, or perhaps the Moteino board could be connected via the i2c bus.

    One last thought, the name “Jump” appears to be trademarked by Digitrax so another name would be needed.

    The simple Arduino based wireless throttle would be an asset to just about any layout. Your thoughts and comments are welcomed.

    Dave
     
    Scott Eric Catalano and DwayneG like this.
  19. DwayneG

    DwayneG New Member

    8
    12
    5
    One of the big downsides to using a phone app with JMRI and DCC++ I found is having to look at the phone between changes to speed etc. Having a device in hand which had either an analog or clicker knob you can change with your thumb and maybe a button or two so you can control without having to glance at the device would be very cool.

    EDIT:- You could probably create an Arduino device that connects to the existing WIFI throttle interface.
     
    Scott Eric Catalano likes this.
  20. DwayneG

    DwayneG New Member

    8
    12
    5
    Hi Dave,

    What's your thinking on needing multiple Megas?

    For the multiple power districts, I would think connecting multiple motor shields to one mega would be fine (I am no expert though!), the only connection that is needed is ground and the pin that outputs the DCC signal. I presume the Pololu shield has two outputs the same as the Arduino one. So motor shield 1 can have 1 DCC output and 1 programming track output, a second shield could have 2 DCC outputs etc.

    For signals and turnouts can you not use a breakout\extender board to add more inputs\outputs/

    Dwayne
     
    Scott Eric Catalano likes this.

Share This Page