Looking at JMRI Logix, this is a non-script click-o-drome if-this-then-that.

Conditions range from block, sensors. Actions are signals, turnouts, scripts or warrants.

Conditions can act when set or on change.

No direct throttle control, maybe indirectly via warrant scripts to run "auto trains".

One possibility is starting a script when some condition happen.

Seems interesting for people who don't want to write scripts. Tons of clicking to get things done.

Seems ideally suited for simple linear decision trees, not for free-form scripting.

Examples would be signals or turnouts set depending on block usage.

For my automation purposes, it seems fairly weak and I’ll design my own software that uses a text file for configuration. Somehow it makes non-tech people very nervous and Windows users especially seem to enjoy clicking ad nauseum in poorly designed modal dialog boxes instead of having a single text file script they can look at quickly.

https://ncedcc.zendesk.com/hc/en-us/articles/200933425-Common-Cab-Questions 

• The NCE PowerCab / DCC Twin can only use cab bus addresses up to 10.
• 0-1 are the internal twin cabs.
• 2-7 are for throttles.
• 8-9-10 are for cab devices.
• The NCE AIU01 can use only cab bus address 4 or 48-63. That means effectively on a PowerCab bus it can only use address 4, there can't be more than one on the whole bus. Quite disappointing but OK enough for home since I had no plan to have more.

I got an NCE Switch-8 to learn what I can (and cannot) do with it for Randall.

Looking at the electronics on the board… If there’s one thing I like about the NCE electronics, it is that they are not fancy. This is the tech I grew up with and I can look at the board and recognize the components and understand what they do. I hope it will stay like that.

Microproc: PIC16F1936

http://www.microchip.com/wwwproducts/en/PIC16F1936

http://ww1.microchip.com/downloads/en/DeviceDoc/41364E.pdf

Pin 1 = Vpp (programing voltage)

Pin 8 = Vss (-)

Pin 20 = Vdd (+)

Power: MCC 7805CT

http://www.mccsemi.com/up_pdf/MC7805CT(TO-220).pdf

Front Left to Right : Pin 1 / 2 / 3

Pin 1 = Input / Left

Pin 2 = GND

Pin 3 = Output / Right

On the Switch-8, the large programming header can be used to get the +5 from the 7805.

From top, #2 is the +5 and #3 is the Gnd from 7805 (shared with the GND headers).

NCE AIU01: there's a similar 7805. A +5V can be soldered on the little through-hole just on top of the 7805 on the board. Measures 5V. For a single IR sensor, use a 220 Ω resistor.

From both the NCE USB v7 doc (see NCE website) or from

http://jmri.sourceforge.net/help/en/package/jmri/jmrix/nce/packetgen/NcePacketGenFrame.shtml

Example: 0xAD is for switching an Accy/Signal. There is no provision to read the state.

• E.g. 0xAD 0x00 0x03 0x03 0x00 ⇒ throw 0x0003 in normal direction
• E.g. 0xAD 0x00 0x03 0x04 0x00 ⇒ throw 0x0003 in reverse direction
• 0 is an invalid address.
• Max address is 2044 (0x7FC) which is a broadcast address for Accy.

Note: when trying in JMRI > NCE Command, "Binary" means hex without x, seriously \o/ ?

Lockout CV 556:

• Use on Address of input #1, which is 4 for my home one.
• 556 = 0x022C
• 0xAF is Ops ACCY programming.
• AF 00 04 02 2C [0=unlocked | 1=locked]
• This works. It locks buttons out.
• ACCY on controller can still be used to throw turnouts.

That means I can trivially command that from an Arduino and bypass JMRI if needed.

Experiment from tonight: control the EZTrack #6 crossovers using the NCE Q-Snap. ⇒ Failed.

I have 2 EZTrack #6 turnouts mounted in cross-over configuration. The idea was to power them from a single Q-Snap output to save one output for each cross-over.

The Q-Snap has no problem driving a single #6. But ever the largest timing I tried does not make the crossover (2 turnouts in parallel) toggle properly. They either bounce or switch half-way.

I also tried using a 9V DC power brick instead of the DCC power. That didn't help. Supposedly that way the turnout should get 9x2-2 = 16 VDC. However from experience I remember I always failed to trigger them in DC, which is why I previously used the AC from the EZTrack ACC power brick.

DigiX: 11 x 6 in

NCE Q-Snap: 4 x 3 in (DCC bus)

NCE AIU01: 4 x 3 (2 RJ12, comes with one cable)

XminiLab scope + board: 2 x 3 // 3.5 x 3 in

NCE UTP: 3 x 2 x 2 in deep

Notes:

• Q-Snap really needs 3 outputs per turnouts, it carries its own common per twin-coil. It's not clear whether I can share the commons since each one has its own capacitor.
• The DigiX relays OTOH work by sharing the AC common so I have 2 outputs per turnouts plus one common.

Yard Design 10 Rules: http://www.housatonicrr.com/yard_des.html very good intro.

        Somewhat unrelated, very interesting read on Housatonic Railroad Design Philosophy.

Tips of Freight Yard design: http://www.featherrivertrains.com/documents/kal_12248.pdf

Yard Operations and Design: https://www.x2011west.org/handouts/ldBootcamp-YardOps.pdf

Many LayoutVision pages relevant: http://www.layoutvision.com/id18.html 

        Love for the yard: http://www.layoutvision.com/id19.html 

        How to classification yard: http://www.layoutvision.com/id20.html

        Ops on a classic 4x8: http://www.layoutvision.com/id39.html

        Beware of CAD: http://www.layoutvision.com/id40.html (agreed on the S curves!)

Interesting design. Note that according to LayoutVison, typical west yards don't have an A/D.

Since I have IR reflective sensors, the idea would be to connect them to an NCE AIU01 to detect position in 2 or 3 spots for speed control and automation.

(Also I got an NCE Q-Snap to control 4 twin-coils, This would cover the front cross-over (2 turnouts), the yard entrance Y1 and the Y1/Y2 yard turnout. Really the point is learning and see what it’s good for since I can already control these turnouts with the Arduino/DigiX).

One idea is for speed matching, using one NCE AIU and 2 sensors.

• Embed the sensors in the EZTrack pointing up rather than side mounted.
• Use these directly using JMRI/jython.
• This leaves 12 unused inputs on the AIU.

This is my own understanding of the JMRI WiThrottle protocol based on reading the JMRI source code and connecting to a local JMRI server. I apologize in advance for the highly condensed notation style. I originally started looking into this to create my own python program; then back in 2014/2015 I used this  to create a Python extension of Scratch running on a Raspberry Pi to control JMRI. It was pointless yet it was absolutely cool and totally worth it. Eventually I used that same information to create my own Cab Engineer: DCC Throttle android app.

-- (start of info dump) --

JRMI WiThrottle protocol in action using [WiThrottle protocol doc].

Server code:

• DeviceServer.java for main codes (old sourceforge link: DeviceServer.java).
• ThrottleController.java for single throttle (T and S codes) (old sourceforge link: ThrottleController.java):

[2020 update: code now at https://github.com/JMRI/JMRI. Also note that all T/S throttle commands are now considered obsolete, using the MT multi-throttle commands is pretty much a given.]