-
-
I second on CAN.
One can buy many microcontrollers with built-in CAN controllers today, and the software you'll have to write is way more simple than e.g. I2C or RS485, as the CAN controller does all the work for you.
The CAN transceiver chip doesn't cost more than a good RS485 transceiver anyway, so there should no reason not to use CAN. For the 10 to 20m range, a multi-drop configuration of the bus isn't an issue at all. And CAN is multi-master by design.
-
-
I implemented a system like this ~20 years ago. One thing to consider is ground shifts and noise, I used a single ended signalling system with very wide noise margins by using relatively high voltages (15V) and a transistor/zener detector with a threshold ~8V (critically the MPU input was a schmit-trigger). All nodes were connected to the same single wire bus that they also pulled up with ~1-5mA, TX was interfaced by an open-collector transistor so any node could pull the bus down but not hard up. The protocol was CSMA (from Ethernet) collisions being detected by the transmitting node checking that when it TXed a '1' that was the result on the bus (nobody else was pulling it down). Messages were kept as simple as possible (not much ram in a PIC16C84) and always repeated, the receiving node detecting errors by comparing the two copies. If the transmitter detected an error it used a random backoff timer before attempting to transmit again. The MPU interface was the standard UART that I seem to recall could clock at up to ~500Kbps. All messages were always repeated at fairly infrequent intervals so data loss at the receiver from an error was only momentary. The system ran on a large layout for around 10 years before life intervened and the whole thing was scrapped
It used geographic rather than physical addressing and was fast and reliable enough to communicate loco speed settings from hand controllers to the layout without any jerking during shunting. Control panel displays simply slurped up interesting info from the bus as did an ancient DOS-PC that ran the block signalling and route selection again due to the tiny memory limitations of then available micro-controllers, the PC placing an upper limit on communications speed.
Good luck and have fun
-
#27 Reply
Posted by
danners430
on 15 Oct, 2018 08:52
-
That sounds interesting!!
I don't think ground shifts will be too much of an issue, as each module will have its own power supply - but each fed from the DCC bus. I'll be running a separate ground line to each module too, so any ground transients will have a path.
As for the MCU itself, I'm thinking a Teensy 3.6 for the main controller, with most other modules which actually control points and signals etc. Being PICAXE chips - easy to program, easy BASIC language and perfectly adequate for this application IMO - just overclock them to 64MHz
The exception to that rule will be my interlocking, which will probably use a PIC18 family processor for speed and RAM space.
Sent from my ONEPLUS A3003 using Tapatalk
-
-
I don't think ground shifts will be too much of an issue, as each module will have its own power supply - but each fed from the DCC bus. I'll be running a separate ground line to each module too, so any ground transients will have a path.
That all depends upon what sort of loads are switched using ground as a return path to the power supply, in my case in a common return DC layout that was practically everything, locomotives, point solenoids, turntable motors and any amount of led's! Also radial grounds are not good for communications, better to have a bus that follows the communication path. In my case a heavy ground bus followed the main part of the layout around with stubs into the likes of island terminus stations. You don't say how large your layout is, mine was about 25ft square at the extremes N gauge with around 350 points to give an idea. Points in particular would have local group decoupling (large capacitors) to reduce ground transients.
-
#29 Reply
Posted by
danners430
on 15 Oct, 2018 09:26
-
My layout is approximately the size of a large bedroom, but will be using DCC. The power supply for the electronics will come from the DCC bus, which is effectively 16V DC square wave, so I'll just rectify it using fast reaction diodes, then put it through voltage regulators. As for the points, they'll be Cobalt stall motors, not solenoids, so no large ground transients there - they only draw up to 100mA when operating!
Sent from my ONEPLUS A3003 using Tapatalk
-
#30 Reply
Posted by
danners430
on 15 Oct, 2018 12:32
-
Just a bit of info - I'm thinking I could go with CAN - if I stick with the Teensy 3.6, which has CAN, and PIC18F25/26K83 MCUs for the peripherals, I should be dancing, as they all have native CAN support - makes life nice and easy. Debating now whether to use CAN for the control panel too... In theory it would be a decent idea, because then it can operate by essentially "snooping" on the bus to get statuses etc. It doesn't need data specifically sent to it... If I were really clever with programming, which wouldn't be too hard with such high-end chips, I might even be able to do away with the control module altogether, with individual modules simply working side by side...
Thoughts?
Sent from my ONEPLUS A3003 using Tapatalk
-
-
Yes, of course CAN would be the natural choice to interface the control panel. Otherwise you'd have to provide a gateway to whatever protocol you'd intend to use for the control panel.
BTW there are implementations that just forward CAN packets over ethernet (UDP wise), so you could build or buy a CAN to ethernet gateway and still use your protocol implementation on the control panel side, having just some other layer (UDP) in between to forward the CAN packets. Or one could use some CAN device that is supported by your host OS to interface with your bus. Some of the Banana Pi SBCs have CAN built-in and working linux drivers available.
As most of the STM32 controllers have CAN on board, many of their discovery kits could be used as a control panel. There's quite a choice of rather inexpensive STM32 discovery modules offering graphical LCDs of various sizes on board. Some of them need some fantasy to "free" the CAN controller, but it's feasible.
-
#32 Reply
Posted by
NorthGuy
on 15 Oct, 2018 14:08
-
I might even be able to do away with the control module altogether, with individual modules simply working side by side...
Thoughts?
Typically, devices on the CAN bus transmit informational messages at regular intervals. For example, a sensor may transmit the results of the measurements every second. Other devices, which are interested in this information, catch these messages and store the values locally. CAN module on any device should give you an ability to filter out the messages you're not interested in. This works, in a way, as variables shared over the CAN bus. The devices also respond to control messages which may change their behaviour and/or provoke a response.
There are protocols which lets devices negotiate their ids when new devices get connected. Thus, you can build networks with varying sets of devices. If your list of devices is fixed, you do not need this.
When debugging, you just connect a sniffer device which lists all the traffic for you and may inject control messages as needed. There's no real security, the debugging device can impersonate messages and they look exactly as if they were transmitted by real nodes. This is what OBD II devices do in the cars.
-
#33 Reply
Posted by
danners430
on 15 Oct, 2018 14:10
-
I'd suggest for the control panel a simple MCU would be ideal... Something like a Teensy or a PIC with CAN connectivity. Allows me to easily multiplex switches and indicators :-)
Sent from my ONEPLUS A3003 using Tapatalk
-
#34 Reply
Posted by
danners430
on 15 Oct, 2018 14:19
-
So how about this:
A mixture of Teensy 3.6 or PIC18F25/26K83 MCUs, all communicating with one another over CAN. No control module, just UI (control panels), interlocking module and "actuation" modules (track circuits, signals, points etc).
The only question I have then is how to do one particular thing:
On startup, I obviously need the actuators to transmit their current status (point direction, track circuit status), so that the user interface and interlocking can be updated. How would I best do this - should the interlocking poll each device on startup before the system reverts to broadcast?
Sent from my ONEPLUS A3003 using Tapatalk
-
-
Each device (no matter if actuator or input) would report its status continously (repeated in short but not too short intervals).
So one could attach or power on any device any time later and it'll sync automatically to the whole system status.
You'll have to think about CAN bus addressing, since CAN addresses are limited and each packet has a maximum payload of 8 bytes, and what to do if there's more than 8 bytes to transmit. My approach is to split larger data into a series of packets with the first (or first two) byte as an index and the rest 6 or 7 bytes representing the data structure at the offset pointed to by the first (first two) bytes. Maybe you won't need that as I believe your payload data is mostly just a few bits for an actuator or input device.
-
#36 Reply
Posted by
danners430
on 15 Oct, 2018 14:38
-
Each device (no matter if actuator or input) would report its status continously (repeated in short but not too short intervals).
So one could attach or power on any device any time later and it'll sync automatically to the whole system status.
That makes sense... So if each device transmitted its status every, say, 1 second (speed isn't really critical when it's just continuous updating), or instantly if there's a change in status, then eventually everything would be updated. As for startup, if I simply programmed each module to send a status on startup, but with a delay unique to each module - for example module 1 transmitted after 1ms, module 2 after 2ms etc. - then I'd eventually have all the statuses after starting up.
You'll have to think about CAN bus addressing, since CAN addresses are limited and each packet has a maximum payload of 8 bytes, and what to do if there's more than 8 bytes to transmit. My approach is to split larger data into a series of packets with the first (or first two) byte as an index and the rest 6 or 7 bytes representing the data structure at the offset pointed to by the first (first two) bytes. Maybe you won't need that as I believe your payload data is mostly just a few bits for an actuator or input device.
Aye, 8 bytes is more than enough. Each command packet will be 2 bytes as far as I can work out - one address byte for each device (point, signal, track circuit) followed by a status - for track circuits that's obviously just a bitvalue, but signals could contain multiple states. In the future I could always expand on this by adding an additional address byte, and an additional data byte - but I doubt I'll ever reach 8 bytes, let alone exceed it.
Status packets will be a bit different... But again, 8 bytes will be more than enough.
Sent from my ONEPLUS A3003 using Tapatalk
-
#37 Reply
Posted by
NorthGuy
on 15 Oct, 2018 16:19
-
As for startup, if I simply programmed each module to send a status on startup, but with a delay unique to each module - for example module 1 transmitted after 1ms, module 2 after 2ms etc. - then I'd eventually have all the statuses after starting up.
You don't need to worry about delays. You just prepare a packed and queue it. The controller will take care of the rest. However, it will not work unless there's at least one more device on the CAN bus. Otherwise there will be no ACK.
-
-
Yes, that looks good. You won't need a different delay on startup, the CAN controller will handle that for you. Anyway, choose higher priority CAN addresses for the "fast" status change and command packets and low priority addresses for the cyclic updates. As NorthGuy pointed out, maybe you need to take care of the controller going "permanent offline" if it is the only one on the bus. Usually this is an configuration issue.
-
#39 Reply
Posted by
danners430
on 15 Oct, 2018 16:35
-
Sounds good - time, I think to do some proper learning for CAN!
Sent from my ONEPLUS A3003 using Tapatalk
-
-
ethernet is so easy, Just plug it in, and start communicting between the various devices at what ever speed you need. easy to program some UDP sockets.. and so cheap these days.. No special interfaces requried to plug into a PC either..
-
#41 Reply
Posted by
jnz
on 15 Oct, 2018 20:27
-
ethernet is so easy,
Ethernet is not multimaster.
IMO, if you have work to do and get done, CAN. If you have more time to tinker or need a specific chip / lower cost, RS485.
There are issues with CAN specifically that you should be using it in a cyclic mode where each module has it's own address or range. This becomes an issue when you have lots of modules programmed identically and need to negotiate their own IDs at boot.
-
-
Ethernet is not multimaster.
or which other protocol would be recommended? Preferably one which can easily be implemented on many different MCUs :-)
Lots of differnet MCU's, no real distance limits.. And the OP asked for other protocols. So much code avaialble to do the job, and lots of people who know how to make it work. Cheaper to implement than RS485.
-
#43 Reply
Posted by
ogden
on 15 Oct, 2018 21:22
-
Cheaper to implement than RS485.
Please explain why you think so.
-
-
Cheaper to implement than RS485.
Please explain why you think so.
because the sum of cost of parts is less than doing RS485. Adding Galvanic Isolation ( which you shoudl do ) to RS485 adds considerable cost to building it. Yeah, you can just bang a transceiver on the end, but then its not really built properly. ethernet is isolated by the transformer. You can create a ethernet attached Micro Controller for under $5. Try doign a properly contructed 485 for that cost.
-
#45 Reply
Posted by
ogden
on 15 Oct, 2018 23:08
-
Adding Galvanic Isolation ( which you shoudl do ) to RS485 adds considerable cost to building it.
Yeah, you can just bang a transceiver on the end, but then its not really built properly.
Please don't invent nonexistent requirements. "Properly built" rs485 does not mean galvanic isolation, nor OP mentioned such.
You can create a ethernet attached Micro Controller for under $5.
Would be nice that you show BOM as well. rs485 transceiver: 1.3$, many kinds of MCU with UART: <= 1$, connector 0.1$. That's it for rs485, ~2.5$
-
#46 Reply
Posted by
nctnico
on 15 Oct, 2018 23:38
-
Cheaper to implement than RS485.
Please explain why you think so.
because the sum of cost of parts is less than doing RS485. Adding Galvanic Isolation ( which you shoudl do ) to RS485 adds considerable cost to building it. Yeah, you can just bang a transceiver on the end, but then its not really built properly. ethernet is isolated by the transformer. You can create a ethernet attached Micro Controller for under $5. Try doign a properly contructed 485 for that cost.
RS485 isn't supposed to be isolated. But if you want you can use an NRZ modulated transmission signal and add a small (&cheap) signal transformer in between. Another option is to use optocouplers (like in Midi) which allows to create an isolated interface between two UARTs very cheaply.
-
#47 Reply
Posted by
danners430
on 16 Oct, 2018 08:22
-
Just saying by the way, whatever protocol gets chosen, and at the moment I'm looking very hard at CAN, it's going to be transmitted over twister pair ethernet cable - probably CAT5 or higher, so it'll be shielded anyway.
Sent from my ONEPLUS A3003 using Tapatalk
-
#48 Reply
Posted by
danners430
on 16 Oct, 2018 13:58
-
So I've been researching the CAN standard, and have discovered something in the physical layer: namely that the characteristic impedance should be 120 ohm. Is that achieved by the 120 ohm terminations, or do I have to find a cable with that impedance? For example cat 5 only has 100 ohm...
Sent from my ONEPLUS A3003 using Tapatalk
-
#49 Reply
Posted by
ogden
on 16 Oct, 2018 14:27
-
So I've been researching the CAN standard, and have discovered something in the physical layer: namely that the characteristic impedance should be 120 ohm. Is that achieved by the 120 ohm terminations, or do I have to find a cable with that impedance? For example cat 5 only has 100 ohm...
Ideal impedance match is not needed. Note that most Cat5 cables are specified 100 +/- 15 Ohms. Just terminate using 110 ohm resistors or so. BTW I would use 2-pair Cat3 UTP cable which is not so bulky as Cat5 4-pair.