The CAN Protocol Tour
		CAN Messages, page 2 of 3
		The Remote Frame Summary: "Hello everyone, can somebody please produce the data labeled X?" The Remote Frame is just like the Data Frame, with two important differences: it is explicitly marked as a Remote Frame (the RTR bit in the Arbitration Field is recessive), and there is no Data Field. The intended purpose of the Remote Frame is to solicit the transmission of the corresponding Data Frame. If, say, node A transmits a Remote Frame with the Arbitration Field set to 234, then node B, if properly initialized, might respond with a Data Frame with the Arbitration Field also set to 234. Remote Frames can be used to implement a type of request-response type of bus traffic management. In practice, however, the Remote Frame is little used. It is also worth noting that the CAN standard does not prescribe the behaviour outlined here. Most CAN controllers can be programmed either to automatically respond to a Remote Frame, or to notify the local CPU instead. There's one catch with the Remote Frame: the Data Length Code must be set to the length of the expected response message. Otherwise the arbitration will not work. Sometimes it is claimed that the node responding to the Remote Frame is starting its transmission as soon as the identifier is recognized, thereby "filling up" the empty Remote Frame. This is not the case. A Remote Frame (2.0A type): The Error Frame Summary: (everyone, aloud) "OH DEAR, LET'S TRY AGAIN" Simply put, the Error Frame is a special message that violates the framing rules of a CAN message. It is transmitted when a node detects a fault and will cause all other nodes to detect a fault - so they will send Error Frames, too. The transmitter will then automatically try to retransmit the message. There is an elaborate scheme of error counters that ensures that a node can't destroy the bus traffic by repeatedly transmitting Error Frames. The Error Frame consists of an Error Flag, which is 6 bits of the same value (thus violating the bit-stuffing rule) and an Error Delimiter, which is 8 recessive bits. The Error Delimiter provides some space in which the other nodes on the bus can send their Error Flags when they detect the first Error Flag. Here's the Error Frame: The Overload Frame Summary: "I'm a very busy little 82526, could you please wait for a moment?" The Overload Frame is mentioned here just for completeness. It is very similar to the Error Frame with regard to the format and it is transmitted by a node that becomes too busy. The Overload Frame is not used very often, as today's CAN controllers are clever enough not to use it. In fact, the only controller that will generate Overload Frames is the now obsolete 82526.   Standard vs. Extended CAN Originally, the CAN standard defined the length of the Identifier in the Arbitration Field to eleven (11) bits. Later on, customer demand forced an extension of the standard. The new format is often called Extended CAN and allows no less than twenty-nine (29) bits in the Identifier. To differentiate between the two frame types, a reserved bit in the Control Field was used. The standards are formally called - 2.0A, with 11-bit Identifiers only, 2.0B, extended version with the full 29-bit Identifiers (or the 11-bit, you can mix them.) A 2.0B node can be "2.0B active", i.e. it can transmit and receive extended frames, or "2.0B passive", i.e. it will silently discard received extended frames (but see below.) 1.x refers to the original specification and its revisions. New CAN controllers today are usually of the 2.0B type. A 1.x or 2.0A type controller will get very upset if it receives messages with 29 arbitration bits. A 2.0B passive type controller will tolerate them, acknowledge them if they are correct and then - discard them; a 2.0B active type controller can both transmit and receive them. Controllers implementing 2.0B and 2.0A (and 1.x) are compatible - and may be used on the same bus - as long as the controllers implementing 2.0B refrain from sending extended frames! Sometimes people advocate that standard CAN is "better" than Extended CAN because there is more overhead in the Extended CAN messages. This is not necessarily true. If you use the Arbitration Field for transmitting data, then Extended CAN may actually have a lower overhead than Standard CAN has.   << CAN Messages, page 1 of 3 - (2/9) CAN Messages page 3 of 3 - (4/9) >>