The one time I've used CAN for a serious product it provided exactly what I needed, and part of providing that was the enforcement of short messages.
Of course, I was working on something that all lived in a box one could get one's arms around, and which closed a bunch of analog control loops. Guaranteed-short runs meant high speed, and short messages meant that the high-priority ones always got through in a timely manner. We reduced the wiring harness by more than a factor of two because of all the low- frequency, formerly analog signals that were all put onto CAN.
One thing I've wondered about for a long time is can the slots get re-used after they're "vacated"? For example, if bits X-Y contain data sourced by the controller and destined for node A, can that those bits then be re-used for data sourced from node B or C (assuming B and C are downstream from A)?
There doesn't seem to be any technical reason why it couldn't be set up that way, but all the fancy animate graphical demos I've seen always seem show each slot being used exactly once.
--
Grant Edwards grant.b.edwards Yow! ... the HIGHWAY is
at made out of LIME JELLO and
gmail.com my HONDA is a barbequeued
OYSTER! Yum!
... which is of course exactly the kind of application CAN was originally designed for.
The late 80s and early 90s saw the use electronics in luxury cars grow at a rate that in the foreseeable future the sheer weight of all the cables, let alone the complexity of the cable harness, would have become untenable. Mercedes-Benz was among the first to see they would run into this limitation in their "S" line, and so they asked Bosch for a solution. The result was CAN: instead of an n:m distribution tree, one signal per wire, you run them all on a single pair of wires, strung run once around the entire thing.
Cars have since outgrown this scheme quite a bit, both in the absolute number of signals and the timing they need. That's why most current models have more than 1 cAN network, with a central gateway to cross-connect data that is needed on more than one network.
To get back to what others have suggested here: keep in mind that CAN has one major advantage over shared-medium Ethernet (e.g. 10base2): its collision handling is a whole lot friendlier. CSMA/CD really sucks if bus load ever goes above ca. 20%. CSMA/CR still works quite well at 70%.
If you want that Ethernet to offer latencies in the range that 1Mbit/s CAN does (~100 microseconds maximum frame duration), the Ethernet frames have to be quite short (~128 Bytes), and that, in turn, will hurt your usable bandwidth.
Those would make it quite a challenge for a 10base2 Ethernet to actually outperform a 1MBit/s CAN bus in terms of effectively usable bandwidth.
Sure. CAN messages look suspiciously like ATM cells. Same basic premise.
But we all know what's happened there...
That must have been faster than 10msec/100Hz sampling then. I've not been so privileged yet.
I've not run into too many cases where the message length put performance at risk.
CAN is a huge improvement on that front.
It just doesn't scale, and the marshalling/unmarshalling is always a PITA. Of course, you accrue a set of converter routines for that and it stops being quite so painful. you're still left with some unpleasant CM duties - when a sensor goes out, for example.
I will bet that if there were small concentrators of analog inputs and asynchronous UDP from them to a central box that replaces the box you used to put your arms around, it'd be cheaper ( ignoring Ethernet switches and power ).
Well not much anyway. They used to come in a DPI14 (or was it 16) back in 1992 when I designed them into the first Nukeman... At the cost of some elevation perhaps the footprint could be halved, this being just a guess really.
Preserving the galvanic isolation would be beneficial in medium sized environments where such an interface would be useful. Then I am not suggesting this could be a CAN replacement, apparently CAN is meant for lower level/closer range communication. I am not familiar with it, back in 1992-a on that same Nukeman design I would have used it had it been available. As it was not - not widely at least - I defined an SPI based link, system to each slot - in order to not need huge latches for all signals one changes once a day (had many of them). Was not so straight forward as SPI is meant to be unidirectional, I ended up making the link 7 bit over 8; the 8-th bit (bit 7) used to tell the slaves the host is sending data or is just polling for new data from the slave, and it used to tell the host the slave did actually send data in this byte. Worked (still does) fine, there was no I2C back then either.
Modbus is basically just request/response so there are going to be latencies and increasing the line speed doesn't help much.
Using Modbus/TCP framing with a message sequence number, the master can send multiple frames at once. The slave processes each request, copies the sequence number to the response, thus the master knows to which request the received response belongs, thus eliminating much of the latencies.
The main problem with putting an Ethernet PHY inside an MCU is that the idea process for a PHY is very different from that for an MCU. This means you need to compromise on the quality (speed, die cost, power efficiency, analogue characteristics, etc.) of one or other parts, or both, in order to put both onto the same die.
Magnetics can be integrated into the RJ45 connector, making it only slightly larger than normal.
With USB3, USB to Ethernet adapters are full speed - the latency is not worse than you would normally live with on the average PC. But with USB2 adaptors (the fastest practical for embedded systems), there is a bit of extra delay and you are a fair way off GBit speeds.
That question makes no sense - MODBUS is a master/slave or question/response protocol. The master sends a question, and the slave cannot send the response before the question arrives, so it is necessarily half-duplex.
But being Ethernet, the connection itself is full duplex (normally). That means you have have multiple master-slave connections and transfers going on at the same time. And since you don't have to have a single bus master at a time, it is quite possible to have multiple Modbus masters on the same network at the same time.
Using UDP reduces the packet overhead a little in comparison to UDP (you don't need ACK's and connection handshaking), but typically it makes very little real-world difference. And TCP/IP is /far/ easier if you are doing something beyond a simple closed network, such as routing traffic around, passing it through firewalls, VPNs, wireless bridges, etc.
And turnaround times are /not/ an issue for carefully implemented MODBUS RTU. Unless you have very special bus hardware, the RS485 bus can be turned around in a bittime or two. The issue here is how fast the master can guarantee to switch off its bus drivers - that gives the minimum latency before the slave can start its reply. And of course slave reaction time and latency can be an issue. So while it is common to have long delays before slave replies, in order to handle slow masters, it is certainly not necessary.
Whether or not that's actually shorter depends a whole lot on where all those nodes are, and where cables can go without being in the way.
In somewhat a typical office environment, if you want it to be even remotely flexible, coaxial cable tends to have to run from some boundary (wall, floor, ceiling) to every node _and_back_again_.
And then of course there's the old one-fault-kills-it-all issue. Finding out which of 50 "T"s, spread over 10 offices, is the flaky one is really no fun at all.
Not necessarily. The true limiting factor is essentially the same as it is for shared-medium Ethernet, and basically every non-synchronized multi-drop network: the diameter of the net must be small enough for a signal to make the double round trip in time for collision handling to work.
Huh? How do you arrive at classifying a full duplex link like SPI as "unidirectional"?
Like I said before I just do not know CAN, this is only the feeling I get about it at the few glances I have had. I still think it is meant for lower level communications than Ethernet (and perhaps misused to put higher level on top of it) but I am certainly not the person to listen to about CAN.
I am not sure how you define full duplex but it _is_ unidirectional in that the master has no way of knowing - other that the data contents it receives from the slave - whether the slave had something to say or not. Likewise, the slave has no way of knowing other than the contents of the data byte (word etc., whatever) whether the master did mean to send data or was just polling the slave for some output. Try to figure out how you would implement an equivalent of a UART over SPI - to figure it out down to the lowest detail, that is - and you will see what I mean.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.