Post by thread:[EE] CAN on linux

On 10/19/07, Rolf <spam_OUTlearrTakeThisOuTrogers.com> wrote: > I came across this in my web travels. May be of interest to some. > > http://www.pcworld.idg.com.au/index.php/id;11338500 > > In summary, it appears that VW (VolksWagen) is submitting a new > network-like implementation of a CAN interface that makes the CAN bus > look like a network socket, and uses the same sorts of concepts. This is > incontrast to prior CAN implementations in Linux which tend to keep > things at a very low level. > > The article says this support is used extensively in their R&D, but not > to expect Linux delivered with your next beetle. > Nice. How many people here use CAN? I have not used it but my colleagues are using CAN (DeviceNet). Xiaofan

On 10/20/07, Xiaofan Chen <xiaofancKILLspamgmail.com> wrote: > On 10/19/07, Rolf <.....learrKILLspam.....rogers.com> wrote: > > I came across this in my web travels. May be of interest to some. > Nice. > > How many people here use CAN? I have not used it but my > colleagues are using CAN (DeviceNet). > I use it both as a consultant and as the maintainer of one of the CAN kernel drivers for Linux and CANAL (CAN abstraction layer) and the higher level protocol VSCP. We see a lot of interest in CAN nowadays and not only from the automotive industry as it was before. CANOPEN is hot in Europe in all fields but also different custom protocols. As I see it it's a cost effective protocol that can replace most 422/485 solutions and that allows solves the standard complex arbitration solutions we all have come up with in 485 environments. Cheers /Ake -- --- Ake Hedman (YAP - Yet Another Programmer) eurosource, Brattbergavagen 17, 820 50 LOS, Sweden Phone: (46) 657 413430 Cellular: (46) 73 0533 146 Company home: http://www.dofscandinavia.com Kryddor/Te/Kaffe: http://www.brattberg.com Personal homepage: http://www.dofscandinavia.com/akhe Automated home: http://www.vscp.org

> > Just curious, What do you mean by "strange" and "limited"? > > I know the data rate may be a bit limited (500kbps for DeviceNet, > 1Mbps for some other CAN based network). The data packet size > is also a bit limited (8 Bytes). > > Xiaofan Key thing to understand about CAN is that it can use 100% of the bus time. Unlike Ethernet which starts to bog down with collisions and retries CSMA/CD, the CAN bus uses CSMA/CR (collision recovery). Each node reads what it sends and if a higher priority bit shows up in the ID part of the message the sender backs off and continues as a receiver rather than a transmitter. Once that message is done, it tries again. So the bus can be utilized 100%. Networks like RS485 master/slave need to be polled and so the master determines priority and async events could be delayed. Token ring networks also have a delay and suffer if the node with the token takes too long to pass it on. Both master/slave and token ring require a master. CAN systems do not. They may have one but it's not a requirement. The down side is that CAN is a topology that is 'one to many' and not 'many to one' or 'one to one'. The ID is not the address of a node. It can contain the address of a node but it must also contain something unique that no other node sends (usually the sender's ID). Two nodes sending the same ID information with different data will cause a bit error, and retries until both units go bus off. This is a bad thing!!! There are lots interesting ways to use CAN. One place to look is http://www.milCAN.com I did a port of that to 9S12 CAN hardware. Interesting project. John Dammeyer

On 10/23/07, John Dammeyer <KILLspamjohndKILLspamautoartisans.com> wrote: > The down side is that CAN is a topology that is 'one to many' and not > 'many to one' or 'one to one'. The ID is not the address of a node. It > can contain the address of a node but it must also contain something > unique that no other node sends (usually the sender's ID). Two nodes > sending the same ID information with different data will cause a bit > error, and retries until both units go bus off. This is a bad thing!!! I have not done much on CAN other than have some training on DeviceNet (based on CAN). I am not so sure how two nodes can send the same ID information with different data. I think the upper layer protocol will take care of this. For example, a duplicate MAC ID check can be used to prevent this situation. If two nodes have the same Mac ID, the lower proiority node (say the one far away) will get rejected. Xiaofan

Hi, You're assuming a new user to CAN is going to use an existing protocol stack. A few years ago, a company flew me halfway across the country to figure out why their $1M machines were unreliable. They had two more partly assembled and orders for 10 more and couldn't ship the first 3. They designed their own protocol stack. It took an 1/2 hour to figure out what was wrong after I arrived. The next morning a couple of hours with the programmers and we'd figured out a work-around without them having to rewrite too much. Once they implemented that, a new bug showed up that had been masked by the first. Once that was fixed the machine worked 100% with all 100 nodes. I left the next day ( a day early ) because there was nothing else to do. A CAN protocol stack is easy to write but you have to keep in mind 'many to one'. Forget that at your peril. There are lots of HLPs out there: CANOpen, DeviceNet, SDS, CANKingdom, J1939, NMEA2000, MilCAN to name a few. I believe OBD-II requires CAN as one of the interface links which means every single car manufacturer has their own proprietary CAN HLP and is extremely reluctant to share that information. (Too bad really). I wrote an article for Circuit Cellar way back in Aug2003 which described a message hopping CANRF protocol. The sender NodeID, receiver NodeID and Family were buried in the 29 bit ID. Also the first two bits described the priority of the messages. Equivalent to Interrupt Events, Device Drivers, Application Threads and File data in order of priority. For instance, messages to/from device drivers always had priority over messages to file devices for obvious reasons. ESTOP or STOP or RUN type interrupt events had highest priority. John Dammeyer > I have not done much on CAN other than have some training on DeviceNet > (based on CAN). I am not so sure how two nodes can send the same > ID information with different data. I think the upper layer > protocol will > take care of this. For example, a duplicate MAC ID check can be used > to prevent this situation. If two nodes have the same Mac ID, > the lower > proiority node (say the one far away) will get rejected. > > Xiaofan > --

On 10/23/07, John Dammeyer <RemoveMEjohndTakeThisOuTautoartisans.com> wrote: > I wrote an article for Circuit Cellar way back in Aug2003 which > described a message hopping CANRF protocol. The sender NodeID, receiver > NodeID and Family were buried in the 29 bit ID. Also the first two bits > described the priority of the messages. Equivalent to Interrupt Events, > Device Drivers, Application Threads and File data in order of priority. > For instance, messages to/from device drivers always had priority over > messages to file devices for obvious reasons. ESTOP or STOP or RUN type > interrupt events had highest priority. > Interesting. Now it seems to be that Safety protocols (DeviceNet Safety, ProfiSafe --Profibus for Safety, Ethernet/IP Safety, CC-Link Safety, CANOpen Safety, ...). But I am not sure if any of these safety protocol allows wireless. It seems to me other than Remote RTU, the industrial automation world are still sceptical about wireless. Xiaofan (who works in the industrial automation field)

Hi, > Now it seems to be that Safety protocols (DeviceNet Safety, > ProfiSafe --Profibus > for Safety, Ethernet/IP Safety, CC-Link Safety, CANOpen Safety, ...). > > But I am not sure if any of these safety protocol allows > wireless. It seems > to me other than Remote RTU, the industrial automation world are still > sceptical about wireless. > > Xiaofan (who works in the industrial automation field) There's a fundamental premise about CAN that I haven't mentioned. There is an assumption that every node can reach every other node. That's why the maximum distance shortens as the bit rate goes up. When I say reach, I mean that every node can hear every other node. When they can't the bus is broken and error flags are transmitted. It's up to the application to determine what to do next. With that in mind, there is an understanding that the ACK a node receives is from all nodes that are active on the bus. However, even in a network of 100 nodes, it's quite possible that only one node provided the ACK in the ACK Slot. You just don't know who or how many provided the ACK. That's why Toggle Bit messages are considered to be an bad design. I send out a toggle. Did the bit change? Don't know. All I know is that I sent the message and someone provided an ACK; might not have been the target node. That's one reason. The other reason is the spec. has an anomaly where a node can miss an ACK, and resend the message automatically in effect sending the toggle bit message twice. That too would wipe out the toggle. What that means is that CAN by itself isn't intrinsicly safe without an HLP verifying messages. That's why TT_CAN was developed as an extension to make it work for Antilock brakes for example. So I agree. Wireless too cannot be guaranteed to deliver a message reliably. My CANRF modules were potentially even worse because they had to run OOK (On Off Keying) in order to handle bit wise arbitration. And OOK or even AM is very prone to noise interference or multi-path distortions. The point I was tring to make though was that the High Level Protocol has to take into account the medium and low level protocol. To deal with messages not getting through I added a lifetime value to each message inside the 29 bit ID. Each node receiving the message would resend it, substituting the sender Node ID part of the header with its' own ID and decrement the lifetime count. The original sender ID was also maintained in the 8 byte data area so the original sender wouldn't resend it. After N bounces the message would die because the lifetime on a received message was zero and so it wouldn't be retransmitted but by then it may well have made it out through a series of expanding rings. It was interesting to watch. A single message would generate a burst of messages from all nodes in range which caused an additional burst of messages in nodes out of range of the initiator. The rebroadcasting could also be done on a periodic time interval rather than as a burst. This allowed clock synchronization between nodes even if they were receiving a TOD message after 5 bounces. John Dammeyer > --

> If it does not receive an ACK what will it do? Bus off. Funny ----- Original Message ---- From: Luis Moreira <spamBeGoneLuis.MoreiraspamBeGonejet.uk> To: Microcontroller discussion list - Public. <TakeThisOuTpiclistEraseMEspam_OUTmit.edu> Sent: Tuesday, October 23, 2007 4:05:15 AM Subject: RE: [EE] CAN on linux Hi John, I am just starting with CAN, I am not sure where this is going to take me, as I am only looking at it because a friend of mine as a seat for is car where all the motors and such are controlled by CAN, but I am finding it very interesting. I have two questions: On the ACK slot, is the transmitter expecting any receiver that is using that identifier to go Dominant to acknowledge that it as received the packet? If it does not receive an ACK what will it do? Thanks for the help. Best regards Luis {Original Message removed}

some of the RTU still runs on wire, RS-485/422, CAN etc. Funny ----- Original Message ---- From: Xiaofan Chen <RemoveMExiaofancTakeThisOuTgmail.com> To: Microcontroller discussion list - Public. <piclistEraseME.....mit.edu> Sent: Tuesday, October 23, 2007 2:52:02 AM Subject: Re: [EE] CAN on linux On 10/23/07, John Dammeyer <EraseMEjohndautoartisans.com> wrote: > I wrote an article for Circuit Cellar way back in Aug2003 which > described a message hopping CANRF protocol. The sender NodeID, receiver > NodeID and Family were buried in the 29 bit ID. Also the first two bits > described the priority of the messages. Equivalent to Interrupt Events, > Device Drivers, Application Threads and File data in order of priority. > For instance, messages to/from device drivers always had priority over > messages to file devices for obvious reasons. ESTOP or STOP or RUN type > interrupt events had highest priority. > Interesting. Now it seems to be that Safety protocols (DeviceNet Safety, ProfiSafe --Profibus for Safety, Ethernet/IP Safety, CC-Link Safety, CANOpen Safety, ...). But I am not sure if any of these safety protocol allows wireless. It seems to me other than Remote RTU, the industrial automation world are still sceptical about wireless. Xiaofan (who works in the industrial automation field)

What's the max baud rate on wireless signal and CAN signal with a healthy signal channel? I can see the value for long range (e.g. 30-40 Miles) communication since you don't have to add the hardware wiring to the network. Especially for those of area which cannot be covered by cell phone in the USA (I was told only about 17% of the territory was covered by cell phone signal years ago, not sure what's the situation now). So a long range wireless CAN communication system does see a good value for gen-set remote control, etc. Funny ----- Original Message ---- From: John Dammeyer <RemoveMEjohndspam_OUTKILLspamautoartisans.com> To: Microcontroller discussion list - Public. <RemoveMEpiclistTakeThisOuTspammit.edu> Sent: Tuesday, October 23, 2007 11:07:27 AM Subject: RE: [EE] CAN on linux And all of those systems, when they talk about wireless CAN, take the CAN packet, bundle it inside a wireless message, transmit using their wireless protocol, and then in the receiver, remove the CAN packet, stick it back into a CAN device and send it over wire. John Dammeyer Automation Artisans Inc. http://www.autoartisans.com Ph. 1 250 544 4950 > {Original Message removed}

Given that you can do more than 1Mbps with wireless Ethernet (carrying a small CAN packet), and the range is substantial with the right antenna setup, you can work out what's legal an not. For my CANRF the range was the typical max 300m at 916Mhz with 20kbps. What made CANRF difficult was bit wise arbitration in the wireless world. For example, the transmitter has to send a dominant (Carrier ON), then a recessive (Carrier OFF) and the on board receiver has to be able to recover from it's local transmitter noise and then be able to detect a dominant bit (Carrier ON) from a different receiver. Look at the various RF devices out there and check the spec on Transmitter OFF to receiver ON time and the 20kbps suddenly looks pretty good. John Dammeyer Automation Artisans Inc. http://www.autoartisans.com Ph. 1 250 544 4950 > {Original Message removed}

On 10/24/07, Funny NYPD <EraseMEfunnynypdspamspamBeGoneyahoo.com> wrote: > Zigbee and bluetooth are good candidates. Zigbee is good for sensor network, industry automation , bluetooth is a bit expensive and target to in-office environment (voice, printing, etc). > > Funny I still wounder if Zigbee really will be a good candidate in the end. This has been said about Bluetooth as well in the past but still prices for chips are way to high for the big markets. Both also demands to much firmware support before you even start to do even the most simple thing. Cheers /Ake --- Ake Hedman (YAP - Yet Another Programmer) eurosource, Brattbergavagen 17, 820 50 LOS, Sweden Phone: (46) 657 413430 Cellular: (46) 73 0533 146 Company home: http://www.dofscandinavia.com Kryddor/Te/Kaffe: http://www.brattberg.com Personal homepage: http://www.dofscandinavia.com/akhe Automated home: http://www.vscp.org

On 10/24/07, John Dammeyer <RemoveMEjohndKILLspamautoartisans.com> wrote: > Given that you can do more than 1Mbps with wireless Ethernet (carrying a > small CAN packet), and the range is substantial with the right antenna > setup, you can work out what's legal an not. > > For my CANRF the range was the typical max 300m at 916Mhz with 20kbps. > What made CANRF difficult was bit wise arbitration in the wireless > world. For example, the transmitter has to send a dominant (Carrier > ON), then a recessive (Carrier OFF) and the on board receiver has to be > able to recover from it's local transmitter noise and then be able to > detect a dominant bit (Carrier ON) from a different receiver. Look at > the various RF devices out there and check the spec on Transmitter OFF > to receiver ON time and the 20kbps suddenly looks pretty good. > Omrom seems to have wireless DeviceNet working at 125kbps/250kbps/500kbps. Not so sure the real performance. http://www.odva.org/tabid/151/ctl/Detail/mid/512/xmid/17149/xmfid/7/Default.aspx Xiaofan

On 10/24/07, Xiaofan Chen <xiaofancSTOPspamspam_OUTgmail.com> wrote: {Quote hidden}> On 10/24/07, John Dammeyer <spamBeGonejohndSTOPspamEraseMEautoartisans.com> wrote: > > Given that you can do more than 1Mbps with wireless Ethernet (carrying a > > small CAN packet), and the range is substantial with the right antenna > > setup, you can work out what's legal an not. > > > > For my CANRF the range was the typical max 300m at 916Mhz with 20kbps. > > What made CANRF difficult was bit wise arbitration in the wireless > > world. For example, the transmitter has to send a dominant (Carrier > > ON), then a recessive (Carrier OFF) and the on board receiver has to be > > able to recover from it's local transmitter noise and then be able to > > detect a dominant bit (Carrier ON) from a different receiver. Look at > > the various RF devices out there and check the spec on Transmitter OFF > > to receiver ON time and the 20kbps suddenly looks pretty good. > > > > *Omron* seems to have wireless DeviceNet working at > 125kbps/250kbps/500kbps. Not so sure the real performance. > > http://www.odva.org/tabid/151/ctl/Detail/mid/512/xmid/17149/xmfid/7/Default.aspx > > Xiaofan >

Hi, Luis, Here is some description from Microchip user manual: "The PIC18F2480/2580/4480/4580 devices are error-active if both error counters are below the error-passive limit of 128. They are error-passive if at least one of the error counters equals or exceeds 128. They go to bus-off if the transmit error counter equals or exceeds the bus-off limit of 256. The devices remain in this state until the bus-off recovery sequence is received. The bus-off recovery sequence consists of 128 occurrences of 11 consecutive recessive bits (see Figure 23-8). Note that the CAN module, after going bus-off, will recover back to error-active without any intervention by the MCU if the bus remains Idle for 128 x 11 bit times." Resending happens at a collision situation and error conditions (ACK error, form error, etc.). I don't think the pic will go to sleep by itself. For the ACK question, any nodes which received the frame correctly will send the ACK at the same time slot. As of your original question, Microchip user manual has the following description: "23.14.2 ACKNOWLEDGE ERROR In the Acknowledge field of a message, the transmitter checks if the Acknowledge slot (which was sent out as a recessive bit) contains a dominant bit. If not, no other node has received the frame correctly. An Acknowl- edge error has occurred, an error frame is generated and the message will have to be repeated." "23.14.6 ERROR STATES Detected errors are made public to all other nodes via error frames. The transmission of the erroneous mes- sage is aborted and the frame is repeated as soon as possible. Furthermore, each CAN node is in one of the three error states; “error-active”, “error-passive” or “bus-off”, according to the value of the internal error counters. The error-active state is the usual state where the bus node can transmit messages and acti- vate error frames (made of dominant bits) without any restrictions. In the error-passive state, messages and passive error frames (made of recessive bits) may be transmitted. The bus-off state makes it temporarily impossible for the station to participate in the bus com- munication. During this state, messages can neither be received nor transmitted." When the errors accumulate to certain level, it will enter the error passive state, and finally the bus-off state. After 128 occurrences of 11 consecutive recessive bits on bus-off state, the node will back to error active state and try to send new messages again if Tx buffer are loaded. Funny ----- Original Message ---- From: Luis Moreira <KILLspamLuis.MoreiraspamBeGonejet.uk> To: Microcontroller discussion list - Public. <EraseMEpiclistEraseMEmit.edu> Sent: Tuesday, October 23, 2007 11:07:22 AM Subject: RE: [EE] CAN on linux Hi Funny, What do you mean with "Bus off", does it try to resend a few times? Does it go to sleep? What I meant with the original question was, does it get an ACK from every node that received the frame or only from the one who recognised the frame as the one it requires? Best regards Luis {Original Message removed}

> > On 10/24/07, John Dammeyer <@spam@johnd@spam@spam_OUTautoartisans.com> wrote: > > Given that you can do more than 1Mbps with wireless > Ethernet (carrying a > > small CAN packet), and the range is substantial with the > right antenna > > setup, you can work out what's legal an not. > > <snip> > Omrom seems to have wireless DeviceNet working at > 125kbps/250kbps/500kbps. Not so sure the real performance. > > www.odva.org/tabid/151/ctl/Detail/mid/512/xmid/17149/xm fid/7/Default.aspx Xiaofan -- That is a bridge device which is different from the CANRF. Below are links to a couple of screen captures of three wireless CANRF nodes and the CAN messages showing arbitration. But alas, I couldn't compete with the ZIGBEE dollars so I've discontinued the product. www.autoartisans.com/canrf/images/rf-arb.jpg http://www.autoartisans.com/canrf/images/rf-msg.jpg John Dammeyer

With the federal regulation (both frequency and power) here in the USA, I am wondering how far can the wireless network go? Funny > > On 10/24/07, John Dammeyer <spamBeGonejohndKILLspamautoartisans.com> wrote: > > Given that you can do more than 1Mbps with wireless > Ethernet (carrying a > > small CAN packet), and the range is substantial with the > right antenna > > setup, you can work out what's legal an not. > > <snip> > Omrom seems to have wireless DeviceNet working at > 125kbps/250kbps/500kbps. Not so sure the real performance. > > www.odva.org/tabid/151/ctl/Detail/mid/512/xmid/17149/xm fid/7/Default.aspx Xiaofan -- That is a bridge device which is different from the CANRF. Below are links to a couple of screen captures of three wireless CANRF nodes and the CAN messages showing arbitration. But alas, I couldn't compete with the ZIGBEE dollars so I've discontinued the product. www.autoartisans.com/canrf/images/rf-arb.jpg http://www.autoartisans.com/canrf/images/rf-msg.jpg John Dammeyer