I love the CMRI on Arduino + i2C and MC23017 expansion plan! A friend and I designed and built a system like that 4 years and have been using it and installing it for friends for 4 years. Check out the Arduini yahoo group. We’ve presented this at various NRMA regional and National (2014,2015,2016) conventions and the presentations, CAD designs and code are available at www.modelrailroadcontrolsystems.com.
We did the address assignments in the sketch to save hardware. We used Arduino the Leonardo and used the standard assignments for SDA, SCK, TX and RX. This left 16 lines for i/o on the “cpNode” and we provided optional pads for resistors to current limit the signal drivers. Then we made IO expanders,(IOX) with one or 2 MCP23017s each for 16 or 32 lines, also with optional resistor pads. That gives up to 128 lines of expansion --like you say: enough for any interlocking – or 144 lines total = 2 SMINI.
anyway, we’ve got 100s of these out in the field and people seem to love them, please take a look!
The big advantage of using the 4 wire version is that you can be having different events going on in each direction. Since the polls are about 50mS per node, this can get to a lengthy poll cycle with inexpensive Arduino based nodes (since they’re cheap you can have lots of small ones, close to the devices being controlled). My partner Chuck Catrania has added some code (in the forthcoming JMRI release but you could implement it in VBASIC pretty easily) where if a node has no changes it simply returns an ACK and the master can move on much more quickly.
We usually run at 28,800 or 56K to keep the polling intervals reasonable on systems with 10 or more nodes.
This is an easy and inexpensive way to set up a layout control bus, and we’ve found it very robust. I’m glad to see you doing this and I hope you’ll share your designs and code on a forum like CMRI-USERS or Arduini!
I was wondering if I would attract you tot his thread Seth. I freely admit I have cribbed many of my idea from cpNode. Not sure why this is, but I prefer SPI to I2C so that’s why I am using the MCP23S17 instead of the 23017 you did. Maybe because for the expense of one more IO line, I can add 8 more chips, 128 bits more, though the only place I can foresee ever needing that much IO in one place might be a physical CTC panel (which I DO want to build - but that comes very late in the process, as it’s much easier to tweak a virtual panel than rearrange a physical one if I need to make changes.).
The idea of adding a simple ACK to indicate no changes sounds interesting, as I will have somewhere around 10-12 nodes. More than I should for a layout the size of my plan, but my plan is also double tracked (which I know wouldn’t normally have CTC but I like CTC so…). I also contemplated another of your ideas, to put the local logic in the node more like the prototype, but then I realized how complex the Arduino sketch would get - commands over the CMRI line, plus I would have to get status from adjacent nodes and… while I don’t mind programming, it’s not my primary thing, I’m more of a hardware guy.
I’m planning to use plain ATMegas328 chips in mine, originally I was going to use Arduino Nanos and just socket them like you did with the Leonardo, but it’s just as easy to put a 28 pin DIP socket, a resonator, and a couple of capacitors and just use the bare chip. I did the same in designing my servo controllers. There’s a bunch of extra hardware on most Arduinos that I just don’t need - multiple supply voltage input, the 3.3v regulator I won’t be using, etc. There is an advantage with the Leonardo since it uses a different micro - it has 2 serial ports so you can have the debugging via serial as well as the CMRI interface. That I will be giving up.
Code too I will shareThe Arduino side will look awfully much like the code in the cpN
I was more likely than not going with the hardcode approach. As I get deeper into it that may change. Given that at least at first there will be a virtual disoatcher console in my program, it will be pretty much specific to my layout and not a generic program like JMRI. I have no desire to recreate JMRI with a drag and drop panel editor and all that. Plus there will be no logic restrictions, as far as how many conditions I can have on a given element - and if there are only 2, then only 2 will apply, not 2 plus some number of blanks.
randy, what kind of bus are you planning? i see several possibilities
2-wire RS-485. each card taps onto the bus like the NCE cab bus and can be removed without disrupting service to other nodes. both master and slaves need to be enable TX. This is required to be half-duplex
4-wire RS-422 (duplex transmission is possible)
Fig-3 in the CMRInet spec suggests that packets are received and forwarded to the next up/downstream node. Presumably two RS-422 interface are required and each node forwards packets not addresses to it either up or downstream. A node cannot be removed without affecting downstream nodes. No need to enable transmission of responses.
common buss that each node taps onto. Node plugs into a socket providing power and access to the bus (like NCE panel jacks). Nodes can be removed without affecting other nodes. Slaves must enable transmission. (think you suggested this approach).
common buss with daisy chained connections. Each node has multiple sockets for 2 or more boards to be connected to it as suggested by the cpNode schematic you posted. Special cables between nodes. With more than two connections, the network does not need to be linear. Removing a node disrupts downstream nodes.
I think a 2-wire RS-485 bus like NCE cab-bus is the simplist. You mentioned that Bruce Chubb advocated a 4-wire bus for easier debugging. But I think RS-485 is less complicated today.
That figure 3 is misleading. The Chubb booards are wired exactly as the cpNode schematic shows, there are two connectors on every board, wired in parallel. It is a multi drop bus, there is no forwarding. The schematics for the SMINI and SUSIC are on the jlcenterprises web site and clearly show the same wiring as the cpNode. The updated SUSIC was also in MR, late 90’s or early 2000’s I think. The old one int he original mid-80’s articles was a straight RS-232 board, no multiple drops at all. Even the current one supports either, depending on which components you populate. On a smaller layout, or where centralizing all the hardware (why?) is desired, the RS-232 option would work. They are ALL like your number 3, except there are no special cables, all cables are the same. Various types of cables are supported, I was considering using UTP, in which case a simple coupler could be inserted in place of a removed board to keep the bus continuous. But unlike a DCC throttle this isn;t something where you would willy-nilly plug and unplug nodes - any change in the nodes, would also require changes in the master program, either because the same node was reused for a different OS section, mening the address is still the same but the logic applied to the various inputs and outputs would need to change, or you are adding a new node which means adding a new address to the polling routine AND the logic associated with the I/O on this new node.
2-wire and 4-wire is not the only definition difference between RS422 and RS485. In fact the is s spec for 4-wire RS485, but the only prime differnce is the RS422 is generally only a 1 to 1 communications. One device talking to one other device, just over longer distances and higher speeds than RS232 because of the differential signalling. And more noise immunity as well. RS485 is based on RS422 but designed for multiple drops, as is used here. Chubb’s design is simply two RS485 interfaces on each card. Yes, it can work with a single pair of wires, if
I’ve been off line chasing the eclipse for the past week, so I’m a little behind. Just a couple of impressions as I think you’ve got a good handle on it. There are lots of AtMega options and a number of serial expansion options, too. We chose the Leonardo because it has a completely separate port for programming and serial monitoring, and the Modern Device module was cost competitive at the time. Subsequently the Arduino IDE support for Leonardo has not been too good and less expensive alternatives have emerged due to widespread piracy of some good designs. If I were to do it today I would use a Pro-Mino or Nano as they are very cheap (in fact I’d soilder them in, not socket, as commodity pro-minis and Nanos cost less than the sockets!). Chuck has written some nice CMRI code that will be in the next JMRI release that knows about cpNode and IOX expanders and provides some good diagnostics, provisioning and metrics for all CMRI nodes, but in any case you can just tell JMRI (or VB Code for that matter) that you’re a SUSIC with a given configuration. The only issue with the serial comms scheme (RS485 multidrop) is managing the poll cycle. It’s best to keep it to 500mS or less (that is 2Hz or better). You can do that by running at higher speed, we like 28,800 but you can go up to either 56 or 112K (I can’t remember which). By separating the input and output streams you can easily live with the latency in the node (between 25 and 50mS depending on a lot of implementation factors).
I was originally planning to use nanos in all my designs. In fact I got a few packs of them, like 5 Nanos for $8 (that’s cheaper than bare ATMega328P chips!). OK, I had to solder the pin headers on myself–whoopie!. I actually was going to socket them - but just using cheap pin headers because a wide format socket is, as you mentioned, more expensive than the Nano. However, while I coontinue to use them as my development platform, plopping in a plain ATMega328 makes it cleaner, IMO.
I’m not so sure I would call it piracy, the Arduino hardware design is open source hardware, so anyone can (and does) make and sell them. The only illegal bit with some of them is they use the Arduino name and logo, but most of them don’t, and call their boards something-duino so it sound the same but isn’t actually Arduino. Quality does vary quite a bit, I don’t know that I’d trust some of the ones I have in a long-term circuit, though they all do work and I only had one failure. It was a little flakey when disconnecting the USB, I found a capacitor on the bottom almost tombstoned. So tried to fix it - my eye, despite using both a fairly high power magnifier AND a rather nice but cheap USB microscope, and SMD do not get along - so I ended up making it worse. Eh, less than $1.50 lost.
That’s another good point about using a 4 wire connection and splitting out the TX and RX onto their own lines. Kind of wonder what sort of speeds Bruce uses on his own layout, he’s got far more nodes than I will ever have and his system appears to work just fine. The slew rate limited 1/4 load RS485 chips can theoretically do a maximum of 250Kbps, 115k should be comfortably within the chip capabilities and be plenty fast enough. The older stuff never went that fast yet works well for many people.
Hopefully I’ll have some time this weekend to work on this a little. I did receive some MCP23S17’s so I cna breadboard a prototype. I need to work up my master comp
Sorry to say this thread is several years old, and that Randy passed away some months ago. He was very helpful to many of us with his knowledge of electronics and Arduinos, and he is greatly missed.
By the way, the info says you’ve been a member here for a while, but that this is your first post. If that’s correct, welcome to the forums. Hopefully someone else will read this and give you some more information that you’re looking for.
I’ve got Arduinos controlling my layout in a vaguely similar manner to what Randy was describing, albeit much simpler because I made no attempt to integrate with JMRI.
I ended up using a network of “Arduino” Pro Minis connected on a RS485 bus. I experimented with port expanders like MCP23017, shift registers, etc. Eventually I found that using them is more effort than it’s worth. It’s easier, simpler, cheaper, and less wiring to just use more Pro Minis instead. I was spending way too much time messing around with port expanders.
Pro Minis are so cheap and need minimal modification. I solder a MAX487 chip directly onto pins 6 7 8 or a Pro Mini. I pull off the Pro Mini’s onboard regulator and solder on a L7805 instead. And that’s it… it’s ready to attach to the RS485 bus and do whatever it needs to do.
Example. Say I’ve got a crossover to automate, I’d dedicate a Pro Mini to it, installing it right beside the crossover so wires are short. I/O needs are four pins for motors, five pins for sensors, three pins for RS485, and I leave the two pins 0 and 1 empty for easy reprogramming. That leaves six pins for LED signals (though you could get an additional two pins if you’re desperate by using A6 and A7). Six pins can control a lot of LEDs if you multiplex them.
Thank you for your post. I have been doing some investigation of using RS485 to communicate between several Arduino based RFID readers and a server. The club I belong to does not use JMRI (except for Decoder Pro), so that is not an issue. The additional I/O made available by the port expanders looked like a good idea, but is not the central requirement I am looking to find a solution for.
I will look at the Pro Minis before I get too far along.
it won’t matter which processor board is used running C/MRI protocol running over rs-485, you could certainly use different boards based on the needs, using the same data driven code on each with different table data depending on the need of each
one of the biggest benefits of node is reducing the amount of wire and better organization of I/O
i developed a board using MCP23017 I2C expanders. the board uses 8 i/o pins to drive lm324 op-amps to drive 8 tortise swich machines and 8 i/o pins as simple GPIOs I2C allows up to 8 board to be daisy chained together.
somewhere Randy posted his code. i exchanged some PMs with in in feb 2020 but am unable to find his listing
