Discussion and questions related to the course CAN Bus Communications Decoded
I've finished the course and from what I learn here, the nodes in CAN only trasmit and/or receive data but never asks for it. Is this true?
For example, let's say that the ABS module for whatever reason needs to know the ECT information but at random times. Can it asks for this information, broadcasting its request to all nodes and the responsible module (in this case ECM) answer it by broadcasting the data?
Because from what I understand, we'll configure what data will be transmitted and received by each nodes, in what frame, the PID etc at certain frequency and the transmitting node will send that message in the configured frequency even when nobody asks for it. And the receiving node will listen to PID it's interested in even though it didn't need that info at the moment.
Is my understanding correct?
Normal CAN protocols do not request data -- but it's possible to run additional protocols on top of CAN. So for example OBD2, sends a query with a specific CAN ID (0x7DF) and the responding device sends a response with a different CAN ID (often 0x7E8, but can be others).
That is used for diagnostics, but not for the normal operation. The normal operation is ECUs broadcast information like Engine Speed, and Throttle Position, ECT and other vehicle modules like ABS (or the dash) use this information if they are interested.
To be clear the notion of PID (Parameter ID) is a concept normally used by OBD2 or other query/response protocols.
Perhaps armed with this info, this page will be useful:
David is on point, CAN is not usually used as a request-reply network, but it is a thing that is possible.
Your understanding is correct, we configure out devices to output the required data at a particular frequency, and the listening devices update their internal values when they receive those messages, on a continuous basis.
Using your example, when something happened inside the ABS module that required ECT information, it would look at its internal recording of what this was as read from the last CAN message that contained it, it wouldn't put out a request for this over the network.
Hi David and Zac, thanks for the replies! Now I understand better about the inner workings of CAN and I sure misunderstood what's going on for a long time! Can't thank you guys enough for the answers and the great course!