Some interesting project for a SMINI by a French modelrailroader "nopxor")
https://www.trainboard.com/highball/index.php?threads/24-in-48-out-card-for-jmri.116454/
A 24IN 48OUT node complete with hardware schematics and software. Impressive.
I made my own pcb's, they are available in the link; software is written by nopxor.
I concur with most here that DCC++ is great for running loco's; anything else I delegate to C/MRI.
And the default 9.6kbps is good enough. And if not the baud rate can be increased.
Just make sure to properly terminate the RS485 transmisson line (preferably twisted pair, with shielding) with 120R on both ends.
srlI 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
speedybeeI 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 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
greg - Philadelphia & Reading / Reading
Speedy Bee,
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.
Steve
York1 York1, thankd you for responding. I am sorry to hear this information. Randy clearly understood what he was trying to accomplish. I read this entire thread closely, and was amazed at his ability to explain what he was doing. A real loss for sure. srl Randy, Did you ever get this working? I was wondering if you have implemented this on a PCB yet. Thanks, Steve, 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.
York1, thankd you for responding. I am sorry to hear this information. Randy clearly understood what he was trying to accomplish. I read this entire thread closely, and was amazed at his ability to explain what he was doing. A real loss for sure.
srl Randy, Did you ever get this working? I was wondering if you have implemented this on a PCB yet. Thanks,
Steve,
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.
srlRandy, Did you ever get this working? I was wondering if you have implemented this on a PCB yet. Thanks,
York1 John
Randy,
Did you ever get this working? I was wondering if you have implemented this on a PCB yet. Thanks,
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 computer software, for a quick and dirty test it doesn;t need to do anything fancy outside of handle the CMRI protocol, but I'm getting hung up on writing classes for US&S style signal and switch levers for a virtual CTC panel. Getting ahead of myself as usual. The other thing that's been puzzling me is just how to handle CTC on double track. Examples of this are few and far between since very few double track mains needed it. I would like to see what the machine looked like as well as just knowing how the signals were handled. I think I have a decent idea on how the signals should tumble down from one home signal at an OS section to the next. Maybe I'm overcomplicating things by trying to signal a double track main for bidirectional traffic. I'd almost be willing to make the whole layout single tracked - would save a lot of space - but pretty much the entire core of the Reading system was all double tracked. Decisions, decisions. Continuous run would be much easier if it were all double tracked. But signalling would be much easier if it were just single track...
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
Randy:
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).
Seth
Great info, thanks for sharing!! Brgds, Rene
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 you use a different driver chip (or reqire what's there accordingly, and use only 1 chip instead of two. A look at the SMINI schematic will show you how he designed it, and it's fairly obvious how the schamtic could be altered to use just the one chip since the whole protocol is, in fact, half duplex. No one talks unless polled, and when the master talks, all are listening. There is no periodic access granted to every device, ala token ring, or no state in which everyone is trying to talk ala ethernet. It's like the polled DCC systems. The reduction in throughput as you add mode nodes (cabs) is steady and predictable, but even the gastest speed is kind of slow relative to other methods. Ones that use a CSMA/CD type system are very fast with few nodes, but as more are added, the drop is not linear like a polled system due to too many factors out of the system's control - for example the knob twiddler operator who constantly clicks the speed control between two settings generates a lot mooore network traffic than the operator whoo just leaves the speed control alone until needed based on track conditions or signals or whatever. The old way of using JMRI to do flashing aspects on Loconet for example - signal on....signal off.....signal on...<repeat> absolutely KILLED the network, flooding it with packets just to make oe signal flash. It made it hard to control trains, which is why our club layout has 2 Loconets, one for signals and one for throttles. The modern method has the flashign done by the device, so all that gets sent is a packet that says flashing yellow on signal 35. Once and done, the signal controller flashes the appropriate output. But this is getting off topic.
randy, what kind of bus are you planning? i see several possibilities
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.
gregc Randy I believe i understand the nodes and protocol for communicating with them. A big benefit of using serial communication and I/O nodes is to reduce the amount of wiring, allowing a PC to communicate with a railroad of any size with a single serial port. How about discussing how your master is organized. I'm familiar with a system on a large layout where there is a lot of hardcoded logic. In other words, the control program is unique to that railroad. Another approach is to describe the railroad in a table (file) containing descriptions of the relationships between blocks, turnouts, signals and I/O bits in tables. I don't know if this is what JMRI is capable of. Which approach are you planning? i assume transmission and handling responses to/from nodes is handled as a background process and a foreground process monitors inputs and updates outputs which are transmitted periodically (?). Do you think main (foreground) processing is simply 1) updating signalling by sequentially scanning each block for occupancy and turnout positions and 2) monitoring turnout controls on panels and switching turnouts based on interlocking rules?
Randy
I believe i understand the nodes and protocol for communicating with them. A big benefit of using serial communication and I/O nodes is to reduce the amount of wiring, allowing a PC to communicate with a railroad of any size with a single serial port.
How about discussing how your master is organized.
I'm familiar with a system on a large layout where there is a lot of hardcoded logic. In other words, the control program is unique to that railroad.
Another approach is to describe the railroad in a table (file) containing descriptions of the relationships between blocks, turnouts, signals and I/O bits in tables. I don't know if this is what JMRI is capable of. Which approach are you planning?
i assume transmission and handling responses to/from nodes is handled as a background process and a foreground process monitors inputs and updates outputs which are transmitted periodically (?).
Do you think main (foreground) processing is simply 1) updating signalling by sequentially scanning each block for occupancy and turnout positions and 2) monitoring turnout controls on panels and switching turnouts based on interlocking rules?
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.
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 cpNode. The master side - one thing I DON'T see is CMRI code in modern .NET languages. Old Visual Basic, and even older MSBASIC is all over. I'm not one to put together a computer of obsolete parts just because it's cheap - I used to be a huge tinkerer that way, ran lots of stuff at home, but since that's also my day job, I hit the point where I just want stuff that works at home, I don't want to come home and spend still more hours maintaining servers and old equipment. Otherwise I probably would have automated several layouts ago using my old Super Elf. In the early 90's I was going to build an original CMRI type system, but alas I had no working bootable disks for my old TRS-80. I actually just acquired a machine that would be perfect for old school CMRI - a NEC PC8801A, which can run CP/M and 8 bit MSBASIC, or MSDOS and 16 bit QBASIC. It even has a serial port, so the interface is there. The only thing is it's an incredibly rare machine in the US, and while it runs 100% at the moment, it IS 36 years old and if I set up a layout that depends on this pretty much unfixable one of a kind machine, I think I am setting myself up for failure, or a lot of headaches. So, modern machine with a .NET implementation is the way I'm going. That way I have the ability to do a virtual CTC panel as well as all the logic. I MIGHT even just use the machine on my workbench upstairs as the railroad computer, it's right above one end of the proposed layout so no long cable run, and it would mean the dispatcher truly can't cheat and look at the layout.
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!
Seth Neumann
www.modelrailroadcontrolsystems.com
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!
CSX RobertRS-485 is basially just RS-422 with the send and receive pairs tied together.
that's my understanding, RS-422 is 4-wire and RS-485 is 2-wire. I don't understand why a 4-wire interface is decribed as RS-485.
http://www.modelrailroadcontrolsystems.com/content/cpNode_Schematic_v20.pdf
gregcstill confused about RS-422 vs. 485.
RS-485 is basially just RS-422 with the send and receive pairs tied together.
For both directions, all bits are sent. Trying to do just changed bits makes for an unecessarily complicated decode process - you'd need to send a lot more than 2 bytes in order to send just the 4 bits that changed since the last poll. By just sending the whole thing every time, it's a simple operation to shift them to the 23S17's, or read from the input ones. On the output side, SE(4)'s red LED will always be bit 5 of the 4th byte. On the input side, Block 2 East detector will always be bit 2 of the second byte. If this were all compressed down to only send that one bit if the only thing that happened was that block became occupied, there would have to be a bunch more data to somehow encode that. Not worth the effort, in increased packet size or processing at either end.
If you look at the code for cpNode, look at the bottom for their Loop() function. There's just 2 lines: Check CMRI (well, the serial buffer) to see if there is any data, and then a call to their function which reads all the input ports and makes the byte stream. Under the CMRI processing, if the message detected is a poll, it does one more read of the input ports, then builds the R message (adds the header infor, inserts DLEs where needed, puts the ETX on the end) and send it. Super simple.
That's the beauty of CMRI - it's a very simple protocol but it can be used for nearly anything. Being polled, there's no need for any sort of collision detection or avoidance. Plenty fast for detection and signalling - modern stuff may be faster, but in the era I model and earlier, the signal and detection systems were relatively slow. A signal would drop relatively quickly, because the track circuit was local, but the indication would take noticeable time to reach the dispatcher's console. All those heavy gravity operated relays were slow. CMRI is, or at least can be, fast in comparison. Seems most people don't run it past 19.2kbps even with many many nodes and ports in use. Don't really have to.
rrinkerI don't have to design a protocol and the implementation both in C++ on the Arduino and VB or VC# for the PC side.
ok, you're using existing libraries for both you master (PC) and nodes
rrinkerI think you're missing part of how it works. It's designed to run with the nodes being purely slaves, answering only when polled.
i believe i understand. that's why i said it's intended for more sophisticated applications
rrinker When polled, the node will send a 2 bytes, even if there are only 8 input devices attached. The master program has to know the number and location of the bits for a given device regardless if there is a fixed packet size or the packet size varies per node.
you didn't respond to this. Do the 2 bytes contain all input bits or coding for only the bits that have changed?
I'm lazy? Since someone has already done it, I don't have to design a protocol and the implementation both in C++ on the Arduino and VB or VC# for the PC side.
I actually was initially considering using Loconet, as there is an Arduino library for that as well, since I will already have a Loconet connecting my DCC system. There is even a .Net library, Percli's RR-Automation, so I wouldn't be stuck with JMRI (I despise Java as a programming language). However, compared to CMRI, the Loconet protocol is a hundred times more complex. I also considered Ethernet and also various wireless systems, but the last thing I think I need is MORE stuff trying to share the 2.4GHz spectrum, plus there's still the issue of complexity of the protocol.
Yes, Chubb had many other uses envisioned for CMRI, many of them are int he original 80's series in MR, like Computer Block Control and Computer Cab Control (this being pre-DCC, the object was to let the computer handle all the block toggle flipping so you could just drive the train). But even those boards were controlled via the exact same protocol.
I think you're missing part of how it works. It's designed to run with the nodes being purely slaves, answering only when polled. There's no requirements for the conversation to be TX, Poll, Receive. In fact, the more typical way it works is that the nodes are polled until a node requires an output update, in which case a TX is done. Even if sequential - things are still read plenty fast enough. The inputs are latching, so even a pushbutton press won't be missed. Even if there is an error on one read, with multiple reads per second, a good value will get through more than fast enough to properly update signals and so forth. There are lots of VERY large layouts using CMRI with no lag issues or bad data.
still confused about RS-422 vs. 485. That can wait
Chubb obviously had other applications in mind. Again, what is the benefit of implementing C/MRI instead of just developing you're own apporoach?
rrinkerEverything is controlled from the master. Typically it is sequential, send to node 1, 2, 3, etc then poll node 1, 2, 3, etc.
for this type of application, receiving updates from the nodes is critical. The master knows when outputs need to change, but it doesn't know when inputs change. It doesn't need to send a TX message, but what if there's a transmission error. So why not just transmit an update which serves as a poll?
A minimum packet is 6 bytes. A poll requires 6 bytes. Instead of a TX packet (14 bytes), a Poll (6) and a response (8) for each node, total 28 bytes, a TX + response is only 22 bytes and eliminates processing (both generating and recognizing) of the poll packets.
at a modest 9600 bps (1 byte / ~msec) there can be ~35 (with poll) and ~45 (w/o poll) nodes serviced every second.
I assure you, it is multi-drop RS485. The nodes are all in parallel along the transmision line. There is no retransmission from node to node to pass the data.
See here:
https://cdn.shopify.com/s/files/1/0947/9088/files/CHG04_SMINI.pdf?4186001288561530172
This is the information (including schematic and parts list) for the SMINI. The main reason for the seperate receive and transmit lines is, as described by Bruce Chubb, to make it easier to debug. One pin of the micro is used to enable the transmit on the serial driver chip of the node that needs to respond to a poll request. All others are held tri-stated.
If you look at the cpNode, they do it differently. They don;t use a controlled pin for TX Enable, they built in what they call AutoRTS using a 555 timer to periodically assert the transmit enable on the MAX489 they use for interface. Schematic here:
Note they use a 14 pin MAX489 full duiplex chip while the Chubb design uses a pair of MAX487 half duplex chips. Also you can see how the serial lines connect through the pair of connectors on each board. You wire them point to point, one board to the next, but the topology is a multi-drop bus. The tap is on the board so you don't have to rig up feeder drops off the signal bus.
Yes, I will still use DLE, you have to, to handle cases where the data happens to match the STX or ETX. SYN is not escaped, the SYN serves miostly as a spacer in the data stream, the code doesn't look for it, only the STX to start a data stream, so an in-stream SYN wouldn't throw the processing loop off like an STX or ETX would.
As for the packet sizes - fromt he host tot he node I would send 8 bytes, that's kind of the idea, to make them all the same. There are 64 bits of output on each card, so 8 bytes gets send, always. If there is no train near the area controlled by a particular card, the signals and turnouts would not change, so it would in many cases be 8 bytes unchanged fromt he last time it updated that node, but in general that's how it works - it doesn't just send changed data, it sends the whole thing. Sending only changed data would greatly complicate the protocol, sending all of it every time means the receive code just has to chift it to the MCP23S17's and that's all. Data sent back in response to a poll would send 2 bytes, fromt he 16 bits of input on each node. There's no need to send back the output bits, the master already knows what those values are, and the same thing goes for sending all vs just changed, just changed data would mean complex encoding and decoding and in the end the protocol overhead would mean it has to send a lot more than if it just sent all 16 bits each time, changed or not.
That's the beauty of what Dr. Chubb came up with here - it's really dead simple. On the JLC web site there are other freely downloadable parts of the various CMRI books that show BASIC code for the master side, and there are at least 2 CMRI libraries for Arduino that are open source, plus the code for the cpNode is also released under Creative Commons so you can look at that. The nodes really do nothing other than take an input data stream and shift it to output drivers, and read the input ports and create an outgoing data stream. Though the Arduinoo CMRI code is non-blocking, so the loop() continues to run and you can add additional code.
Everything is controlled from the master. Typically it is sequential, send to node 1, 2, 3, etc then poll node 1, 2, 3, etc. However, nothing prevents mixing this up if needed, althought here is little need. I calculated out some transmission rates, although I don't have the document here, it might be on my laptop. Even at a modest 19.2k baud rate with 20 nodes, each one gets read and written several times per second, which is more than sufficient. There's a 6 byte fixed overhead (2 SYN, STX, Node Address, Message Type, ETX) so assuming a message that requires no DLEs, it's 14 bytes send, 112 bits, and the node would send back 6 + 2 bytes or 64 bits. There's no need for super high speed, and the slower you can run it, the longer the line can be. Distance limitations, unless the layout is airplane hanger size, don't really come in to play and the driver chip has a limit of 250kbps although there are others that go up to 2.5mbps. Even sticking with say 115.2kbps, each node would be updates well over 10x a second. The amount of data being transmitted is tiny, there is no need for multi-mbps or gbps speeds. Had a similar discussion with my friend the other week - they keep trying t push everyone into using these newer 32 bit ARM core microcontrollers for everything, because they are fast. Yes, but not everything actually needs to run that fast, there are still plenty of applications where a simple 8 bit micro running at 16 or 20MHz is PLENTY fast enough. Do you really need GHz speed and 32 bit ptocessign power to read 40 buttons on a remote control and generate a data stream on an IR LED or an RF module?
rrinkerYes, Bruce uses 4 wires for the connection - but it's still half duplex RS485.
my understanding is that 4-wire RS-422 can be used half-duplex but separate wires are used for transmission in each direction. RS-485 has only 2-wires and transmission in both directions uses the same wires.
RS-422 and RS-485 line interfaces are different. Looks like C/MRI and CMRInet require RS_422.
in your original post you identify an I/O (D2) to be used for the RS-485 transmit enable
rrinkerEach Transmit from the host will send 8 bytes in the data portion, even if the particular node only has 5 bytes worth connected to hardware.
are you going use the data link escape when sending date bytes that have the same values as SYN, STX or ETX, or are you not going to worry about synchronization?
rrinkerWhen polled, the node will send a 2 bytes, even if there are only 8 input devices attached.
rrinkerSo if Signal East 4 is a standard 3 LED signal attached to the the first 3 bits second port of node 3, it's value might be something like 3,1,0,3 meaning node 3, second byte, bit 0, for 3 bits.
It's not clear if polling only reports inputs that have changed or if a separate msg is sent for each group of input bits that have changed.
why not just send 8 bytes back? Is bandwidth a concern? is each node sequentially updated and polled?
Is the future benefit of being CMRInet compatble that you can possibly use complient boards in the future? But such board would require RS-422
Yes, Bruce uses 4 wires for the connection - but it's still half duplex RS485. The node and master never transmit and receive at the same time. It's all polled, there is no "input changed, so send a packet to the master" mechanism at all. So there are no collision issues. If you look on the actual hardware, like the SUSIC, SMINI, or cpNode, the TX in and TX out on the boards is tied together, as ire the RX In and RX Out pins. So TX from the master is connected to the RX of all slaves, and the TX of all slaves is connected to the RX of the master.
Any varying transmissioon size must be managed by the master - there is no parameter in the protocol for total packet size. All you have is the start (STX), an address, a command, the data bytes, and an end (ETX). It's actually ridiculously simple - look at the source for either the CMRI Arduino library, or the cpNode. All I'm really doing is dropping the Initialization message since my sketch will hard code the number of input and output ports on the node. Each Transmit from the host will send 8 bytes in the data portion, even if the particular node only has 5 bytes worth connected to hardware. When polled, the node will send a 2 bytes, even if there are only 8 input devices attached. The master program has to know the number and location of the bits for a given device regardless if there is a fixed packet size or the packet size varies per node. I'm thinking along the lines of a multidimensional array in the master to store each device. 4 dimensions, in fact - one for the node address, one for the byte, one for the starting bit position, and one for the number of bits. So if Signal East 4 is a standard 3 LED signal attached to the the first 3 bits second port of node 3, it's value might be something like 3,1,0,3 meaning node 3, second byte, bit 0, for 3 bits. The start bit position and number of bits is used directly to extract the values for a specific object.
Other than not using an I message type, the packets will be the same format as standard CMRI.
rrinkerCMRI defines the protocol over an RS-485 interface. It's actually been adopted by the NMRA as an alternative LCB protocol - and it's WAY easier than CAN. The full specs are in the various CMRI articles Bruce Chubb has published, and also at the NMRA: https://nmra.org/sites/default/files/standards/sandrp/Other_Specifications/lcs-9.10.1_cmrinet_v1.1.pdf
https://nmra.org/sites/default/files/standards/sandrp/Other_Specifications/lcs-9.10.1_cmrinet_v1.1.pdf
thanks for the reference. Not sure this is exactly C/MRI
they describe an RS-422 inteface which is 4-wire, duplex transmission in both directions. They show nodes wired in a daisy chain, so devices must re-transmit packets not intended for them to the next device, in both directions.
You mention using RS-485, which is half-duplex, and I believe more common. Every device sits on the bus and no retransmission is required
Their packet size appears dependent on the reception of an end-of-transmission (ETX) byte. This is why they use a data link escape (DLE) byte, so that data with the same value of ETX can be sent. Adding a packet size byte to the header might simplify things. Not sure about synchronization.
they have 4 types of packets: initialization, poll, transmit and read.
I think CMRInet is a bit complicated for the things being discussed and based on my understanding of the Pacific Southern control system. It's intended to simplify wiring to obtain state that is constantly in flux which is different than receiving infrequent commands from a device such as a DCC handheld.
Sounds like you're borrowing ideas from it, not implementing it exactly. Do you intend to have the slaves sends responses only when its input state changes? If so, what happens if the response packet is corrupted?
rrinkerThe CMRI protocol does provide for a configure packet but my goal was to simplify it and used fixed packet sizes - any unused bits would juet be 0, or 1, whichever. My master computer program (or anyone's, really) needs to know what devices use what bits on what node
Not sure if you plan on having both address and type bytes in the header. An address might would be sufficient if a single bit were used to indicate that the packet is not common data, a command/configuration packet.
A configuration packet can be used to configure the number of I/O and which are outputs. This would avoid the need to have a fixed number of I/O or number of inputs vs outputs. This would allow all configuration information to be in the master. The master could query the node to verify it has the correct number of I/Os (multiple of 8) and then confgure GPIOs as input or output.
flexibility will be important during early development and installation when plans need to change.
CMRInet either transmits data to the node or sends a poll and receives a packet back from the node.
I think a more common approach for this type of application is for the master, as you said, to send the number of bytes the node supports regardless of whether they are outputs or inputs and with each transmission, the node immediately sends back a packet with the same number of bytes containing all the input data.
You mention fixed byte packets but not whether you intend to poll each time or have the node respond to each transmission. Would you describe the packet structure and protocol you intend to use, if different than CMRInet?
have some questions about the MCP interface that can wait
Inline replies..
gregc could you summarize what CMRI defines? I assume it's rs-485 based, so what is the packet structure/size? CMRI defines the protocol over an RS-485 interface. It's actually been adopted by the NMRA as an alternative LCB protocol - and it's WAY easier than CAN. The full specs are in the various CMRI articles Bruce Chubb has published, and also at the NMRA: https://nmra.org/sites/default/files/standards/sandrp/Other_Specifications/lcs-9.10.1_cmrinet_v1.1.pdf
could you summarize what CMRI defines? I assume it's rs-485 based, so what is the packet structure/size?
CMRI defines the protocol over an RS-485 interface. It's actually been adopted by the NMRA as an alternative LCB protocol - and it's WAY easier than CAN. The full specs are in the various CMRI articles Bruce Chubb has published, and also at the NMRA:
gregc is each node fixed? Have you considered making the number of inputs/outputs configurable at startup through a configuratoin command? The CMRI protocol does provide for a configure packet but my goal was to simplify it and used fixed packet sizes - any unused bits would juet be 0, or 1, whichever. My master computer program (or anyone's, really) needs to know what devices use what bits on what node - ie, it needs to be programmed such that Signal East 5 is bits 0,1, and 2 of byte 3 on node 6. Rather than customize each node's definition and have the corresponding code to build the transmission strings of different sizes, I was planning to just always send 64 bits, and the node to always send 16. Even if the node only drives a simple passing siding with 20 LEDs (3+2 on points side, 2 head dwarf on exit to siding, 3 head on main side, x2) , 2 turnouts, 2 locks, and 6 detectors (main in, OS section, siding between turnouts, main between turnouts, other OS section, and other main). My layout will be double tracked so every OS section will have more outputs needed. This is all subject to change, but my main goal was simplification.
is each node fixed? Have you considered making the number of inputs/outputs configurable at startup through a configuratoin command?
The CMRI protocol does provide for a configure packet but my goal was to simplify it and used fixed packet sizes - any unused bits would juet be 0, or 1, whichever. My master computer program (or anyone's, really) needs to know what devices use what bits on what node - ie, it needs to be programmed such that Signal East 5 is bits 0,1, and 2 of byte 3 on node 6. Rather than customize each node's definition and have the corresponding code to build the transmission strings of different sizes, I was planning to just always send 64 bits, and the node to always send 16. Even if the node only drives a simple passing siding with 20 LEDs (3+2 on points side, 2 head dwarf on exit to siding, 3 head on main side, x2) , 2 turnouts, 2 locks, and 6 detectors (main in, OS section, siding between turnouts, main between turnouts, other OS section, and other main). My layout will be double tracked so every OS section will have more outputs needed. This is all subject to change, but my main goal was simplification.
gregc are you dedicating 5 inputs for address? you could use optional pull-up/pull-downs on 5 of the outputs that are read at start up to determine the address before programming the I/O pins as outputs another alternative is to program the address in the atmel EEPROM Since even after I do that, I have 7 pins unused, 'wasting' 6 for an address switch doesn't seem so bad. I originally was going to do it the same way the cpNode is designed, which is set in the firmware by a defined constant. But then I'd have to program each node's micro individually and change the address. Same if I stored the address in the EEPROM. The SMINI actually has 7 pins used just for setting the address, all of PA on the PIC plis PC4. Since nothing on the board uses analog, using the analog pins as inputs seems like a decent plan. And 6 bits is plenty, since I will never need more than 64 nodes.
are you dedicating 5 inputs for address?
you could use optional pull-up/pull-downs on 5 of the outputs that are read at start up to determine the address before programming the I/O pins as outputs
another alternative is to program the address in the atmel EEPROM
Since even after I do that, I have 7 pins unused, 'wasting' 6 for an address switch doesn't seem so bad. I originally was going to do it the same way the cpNode is designed, which is set in the firmware by a defined constant. But then I'd have to program each node's micro individually and change the address. Same if I stored the address in the EEPROM. The SMINI actually has 7 pins used just for setting the address, all of PA on the PIC plis PC4. Since nothing on the board uses analog, using the analog pins as inputs seems like a decent plan. And 6 bits is plenty, since I will never need more than 64 nodes.
gregc can you explain the purpose of these? can explain this more? why divide the inputs and outputs? I assume there are 16-bit transmitted to/from the device during each interval. The master (arduinoe) sends an output bit while the salve (MCP) sends the corresponding input. It's been a while since I worked on I2c. Doesn't it precede data with an address. I see the 23S17 uses a !CS. Does this require a separate data pin to select each chip? The MCP23S17 uses SPI, not I2C. So you have 3 lines, Master Out,Slave In; Master In,Slave Out; and SCK, the clock. All slave devices are wired in parallel with those 3 lines, and then there is a chip select on each one that is how it determines which device you are talking to. Thus the use of D10 and D9 as selects. The 23S17 ALSO has an address so like I2C, you send an address first so it knows which chip to talk to. The chip select gets connected in parallel like the other 3 lines. The 23S17 has 3 pins for address select, so you can have up to 8 in one chain. But those are address bits 1, 2, and 3 - internally the 23x17 chips are dual 8 port, each with it's own address. I wanted to split out the input and outputs because initially I was planning a lot more outputs and inputs as the standard device - I've actually pared it back. I originally would have had more than 8 chips. So I split inputs and outputs. It also simplifies programming - on each power up the chip registers have to be initialized for input and output, and the driver library has a handy function that reads or writes all 16 bits of a given chip in the string.
can you explain the purpose of these?
can explain this more? why divide the inputs and outputs?
I assume there are 16-bit transmitted to/from the device during each interval. The master (arduinoe) sends an output bit while the salve (MCP) sends the corresponding input.
It's been a while since I worked on I2c. Doesn't it precede data with an address. I see the 23S17 uses a !CS. Does this require a separate data pin to select each chip?
The MCP23S17 uses SPI, not I2C. So you have 3 lines, Master Out,Slave In; Master In,Slave Out; and SCK, the clock. All slave devices are wired in parallel with those 3 lines, and then there is a chip select on each one that is how it determines which device you are talking to. Thus the use of D10 and D9 as selects. The 23S17 ALSO has an address so like I2C, you send an address first so it knows which chip to talk to. The chip select gets connected in parallel like the other 3 lines. The 23S17 has 3 pins for address select, so you can have up to 8 in one chain. But those are address bits 1, 2, and 3 - internally the 23x17 chips are dual 8 port, each with it's own address.
I wanted to split out the input and outputs because initially I was planning a lot more outputs and inputs as the standard device - I've actually pared it back. I originally would have had more than 8 chips. So I split inputs and outputs. It also simplifies programming - on each power up the chip registers have to be initialized for input and output, and the driver library has a handy function that reads or writes all 16 bits of a given chip in the string.
rrinker Mel - I would think the key would be to count the steps and hope the motor you are using has good repeatability. Another way would be to use a servo, you'd have to run linkage up the post but you could definitely stop it facing the right way. --Randy
Mel - I would think the key would be to count the steps and hope the motor you are using has good repeatability. Another way would be to use a servo, you'd have to run linkage up the post but you could definitely stop it facing the right way.