I have a project where CAN bus is being proposed for connecting several custom instruments together on a 200Ft long single twisted pair.
I am no serial protocol expert but when CAN was brought up in two seperate other venues, it got shot down right away. I remember something about being non-standard or several different flavors so it isn't really a universal standard. Don't know!
I'm looking for 500K - 1Mbit of data throughput on this bus. CAN tops out at
1Mb at 40meters which is just short of this application but can do 500K at
100meters which fits the bill. I originally looked at ethernet once single twisted pair (half duplex) but a 3rd party is proposing CAN.
Looking for some experinece from those that have impelemented CAN bus and if they would do it again.
I've used it in a couple of products so far and will do so again.
The physical layer is standardized. However, there are indeed several flavors of higher-level, standard protocols for the CAN bus. If you are targeting a custom setup (as I did) you don't necessarily need to implement any of them, though. It's quite easy to set up your own addressing and packet identification scheme.
The data throughput you mention could imply that you're passing around large binary objects. That is not a particularly comfortable use for CAN, since individual packets are limited to no more than 8 bytes.
You also can't count on equating bit-rate with throughput. I'd not start out aiming higher than 1/3 or so, 300KBPS over a 1MBPS channel.
Seems like the common theme is that CAN is suited for smaller packets sue to the 8 byte payload size of a standard packet. Can a non-standard packet size be easily implemented to increase the max data packet size to say 1K bytes.
The # of instruments on the bus will vary from 5 to 20. For the worst case the packt sizes will be as the following
Ten 4 byte devices each with a unique address Five 30 byte devices and five 512 byte devices
My simple analysis is as follows
4 bytes for command to request data from each device(address, command, CRC) Once the addressed command is received by the device, it outputs its data.
So to scan the string that would be
10 * 4 + 10 * 4 = 80 bytes for the 4 byte devices (high overhead I know)
5 * 4 + 5 * 30 = 170 bytes for the 30 byte tools
5 * 4 + 5 * 512 = 2580 bytes for the 512 byte tools
Total bytes = 2830 Total command bytes = 80 = 2.9% of data traffic. Acceptable
I want to sample this string at 100S/sec so thats 2580 * 200 = 258K bytes/sec payload data throughput.
Could a 1Mbit CAN bus do this task reliably?
My personal preference is either half duplex ethernet or half duplex 485/422 the questions are being raised about CAN. There is only a single twisted pair avaialble.
CAN/Ethernet/RS485 all have multiple protocols layered on top. In that sense there are multiple flavours.
CAN is suited to small messages, it's optimized for control. The largest amount of data per message is 8 bytes and in use 0 bytes is not unheard of (data can be implicit or contained in the 'address' bits). As such the iverhead is large compared to the data. If you are looking to transfer large amounts of data then I'd look for soemthing else.
Flexray build on it with higher speeds and as I recall large data size capabilities.
Posted via a free Usenet account from http://www.teranews.com
No. The data portions of CAN packets can be no larger than eight bytes.
For higher-level messages larger than 8 bytes, one of the eight in each packet would typically be designated as a counter, which would result in a combined total payload max size of 1785 bytes -- assuming that packet 0 is used to send a preamble with the expected total packet count and, perhaps, how many bytes are used in the last packet.
The CAN does include "remote" frames, zero data length but with the RTR (remote transmission request) bit asserted.
You also have eleven (or 29) bits in the address field that are yours to specify. You could use those for source ID (5 bits), destination ID (5 bits), content ID (n bits), and command (19 - n bits).
One nice feature of CAN is that it handles collisions and retransmissions automagically. You also get for "free" a CRC test on each packet (no processor overhead - it's handled by the CAN peripheral).
I agree with most of what has been said: The real data rate max's out about 250k. 500k-1Mbit and you will not make it with CAN. Building the universal interface is a management pipe-dream. Settle for one that is widely supported. Make the software object oriented; that is with the ability to exchange hardware devices and protocols under the main program without reworking the main program. We used to call it modular programing:) It does behoove you to make up a comparison spread sheet with the requirements in one direction and alternatives in another. I had experience with CAN at Chrysler and my last job. It's a bit sluggish but very noise immune. CAN is pretty good for a car, but overkill for our small instrument (but it worked out okay). For a closed instrument and several drops I would probably recommend RS485 with the ROBIN packet protocol:
But it all depends on the particular problem you are addressing. Do the comparison worksheet in order to document the decision reasons, and to keep silly statements like "not universal" out of the conversation. Force quantification; make the programmers actually plan their work, and managers justify their opinions in writing. Alternatives are: I2C, SPI, Ethernet, USB, Firewire, RS232, CAN, RS485 Accept the fact that the programmers are going to actually have to do some work no matter which protocol is made, and have them estimate how much. Allow at least 100% safety margin in the data rate. Once again make an objective comparison sheet: noise immunity required, data rate, amount of software support available and needed, architecture (multi-drop, duplex, etc...).
No, The max packet size is pretty well fixed in HW.
One other small point. In CAN devices don't have address's messages do.
Often (usually?) data is not requested on a CAN bus setup. It is supplied by the originating device(s) as it is available. Say one device measured voltage and current (od something a) then it might send out two messages with different message IDs as each measurement was available. A different device measuring temperture would send that information via a third message ID. This has the advantage that devices can be split and combined w/o any other device on the bus needing any knoledge of the devices. What matters are the data and control messages not the device IDs. Also if half the deives need to know the temperature than they all just listen for its message. They don't each need to ask for it. This may affect your bandwisth requirements calculation.
You are leaving off the protocol overhead. It's significant for CAN.
If it's regular data collection I would expect lower than that. If you need to sync than a single 0 byte message will suffice.
String? Tell me you are not sending actual strings but binary data instead.
OK lets try this (brute force message splitting but no handshake overhead for the large blocks)
Sync command 0 bytes + 6 bytes overhead
Assuming 4 byte devices are single message devices then they have 5 bytes + 6 bytes overhead = 11 bytes
Assuming the 40 byte devices can be handled as 4, 8 byte messages then thay have 4 *(8 bytes + 6 bytes overhead) = 56 bytes
Assuming the 512 byte devices are handled in 64 - 8 byte message then they have 64 *(8 bytes + 6 bytes overhead) = 896 bytes
For a total of 6 + 10 * 11 + 5 * 56 + 5 * 896 = 4896 bytes/cycle =
487600 bytes/sec = 3.9 Mbits/sec
and 1 + 10 + 5 * 4 + 5 * 64 = 351 message IDs
Not even close. You may well be able to state the problem differently to reduce your bandwidth requirements but if it really is as you state there is no chance. Those large data sets are killing you.
Moving some of the data into the message IDs might help too but I doubt enough.
Posted via a free Usenet account from http://www.teranews.com