CANopen, TPDO and RPDO behavior? - can-bus

Say I have deviceA(NodeID 1) and deviceB(NodeID2)
Does deviceA send TxPDO 180+2 and deviceB receive data by RxPDO 200+2
Does deviceA send TxPDO 280+2 and deviceB receive data by RxPDO 300+2
Does RxPDO send data to cable? Or it just eds file?
PS, photo is from https://en.wikipedia.org/wiki/CANopen

The NodeIDs are only added to PDOs sent, not received by the associated node.
Therefore:
Does deviceA send TxPDO 180+2 and deviceB receive data by RxPDO 200+2
No, DeviceA sends 180+1, and DeviceB receives 200+1 (because if he receives, he cannot be sender, and you said only 2 nodes are on the bus, thus the only ID possible to be added is 1).
Does deviceA send TxPDO 280+2 and deviceB receive data by RxPDO 300+2
No, same explanation as above.
Does RxPDO send data to cable? Or it just eds file?
RxPDO was sent by cable.

The COB-ID list for PDOs shows only the default values. If all devices in a network have default COB-IDs for their PDOs, it means that they are not linked together and no device listens to any PDO sent on the bus (well, actually the PDOs they listen to simply don't exist on the bus). Default COB-IDs ensure that there is no COB-ID conflict on the bus.
Usually, a CANopen master configures the bus using SDO request by changing TPDO and RPDO COB-IDs in each device. So, DeviceA sends TPDO with 180+1 and if you want DeviceB to listen to DeviceA, you set DeviceB's RPDO COB-ID to 180+1 as well.
One may think that after the nodes are connected together, some default RPDO COB-IDs become unused (or wasted). Devices can use them as TPDO COB-IDs, if there are more than 4 TPDOs are needed. Of course, there are other ways to increase the number of TPDOs.

Related

CAN bus sending data from two masters with equal balance

I have two master nodes connected to the same CAN bus, both send data to my PC.
first master ID = 0xFFA1
second master ID = 0xFFA2
Since the first master ID is lower than the second it takes control of the bus more than the second master. And this causes some delay in the data.
Is there a way to make load balancing between two nodes so that each node send an almost equal amount of messages.
I tried making the first node send data while switching between two IDs 0xFFA1 and 0xFFB2,
and the second node sends data with ID 0xFFB1. And it didn't help.
There is no such thing as "masters" in CAN, nor in higher layer protocols like CANopen for that matter (a "master" in CANopen is just a supervisor node). Who gets to send what is defined by the CAN identifiers - CAN is primarily focusing on data, not nodes. What matters is what is sent, rather than who is sending/receiving, since every message is broadcasted.
It sounds as if you have 2 nodes that wildly spam the bus with identifier 0xFFA1 and 0xFFA2 messages, as fast as they are able, leading to 100% bus load. Then the node sending 0xFFA2 will "starve". Sending data "as fast as you are able" is never the correct way to use CAN.
Instead you need to define a higher layer protocol that dictates real-time characteristics. In control systems, this is most commonly done by having nodes send data at fixed intervals, such as once per 10ms or 100ms. This alone should fix your starvation problem.
If you want to prevent nodes from sending at the same time, then you could provide a means for them to synchronize. A trick used in CANopen and other protocols, is to have one node send out a "sync" message at given fixed time intervals.
After reading this sync message, all nodes should act within x ms from receiving it.

can I modify ACK field or CRC field in CAN frame?

To generate error on CAN, I've done change data field. But It seems just change numerical things.
I want to know how to modify ACK or CRC field to inject error.
Can I change that field with software?
No, you cannot change that from software, since that part of the message is always constructed on CAN Communication Controller level and down (Physical Layer).
Basically, the ACK field is not set in SW. It is "completed" by other nodes while the message is sent, and the bitstream arrived to the ACK bit slot.
The CRC is constructed on Communication Controler level, upon the payload the application wishes to send.
So in order to inject such faults in a CAN message, you need a special HIL (Hardware in the Loop) device, which will forcefully overwrite fields of your choosing.
One such device is a CANSTress from Vector, but there are many others.
Regarding NACK error, you can simulate that without HIL, if you have a simulation environment.Or, simply do not turn on the other nodes on the cluster, ensuring there is no other node to ACK the message. Beware, disconnecting CANH and CANL cables will result in a different error type.

adressing in can protocol and dbc format?

Am I correct that in can ecus/nodes receive all mesaages on the bus, and they filter the messages by message ID?
In my dbc file (when openend in vector canoe) I see node name and node address. What is this address good for?
Thx
In CAN protocol messages are broadcasted to the bus. Each ECU is configured to receive only particular messages based on the CAN DBC. A DBC file contains details of all TX and RX messages for all nodes. These nodes are nothing but different ECUs. The address is used for arbitration on the bus. CAN uses CSMA/CA (Carrier Sense Multiple Access Collision Avoidance). So, if two ECUs want to send message at the same time, only one will be able to send based on arbitration.
Am I correct that in can ecus/nodes receive all mesaages on the bus, and they filter the messages by message ID?
Yes.
In my dbc file (when openend in vector canoe) I see node name and node address. What is this address good for?
ID and address are the same thing. The name is just a help for humans beings.

CAN BUS - ACK field

When a receiving node would like to ACK acknowledge the receipt of a frame, what exactly is it supposed to transmit?
The same frame just with a dominant bit for ACK?
No, every CAN node controller on the bus will usually listen to a message transferred and will automatically check this frame for correctness (CRC).
And it will usually also acknowledge the message by overwriting the recessive ACK=1 ("send" by the transmitter) with a dominant ACK=0 during message transfer. So there is no second message needed to acknowledge the first one.
That's also why you can't have any CAN bus with just one node, because there is no one else to acknowledge and check its sent frames.
Of course, in some controllers these checks can be deactivated or ignored, but not in the common use case.

Multipeer connectivity framework via bluetooth in iOS: how to determine if the message is "old"?

I have one device (server) which can send messages and they should appear on other devices.
The problem is all the devices are connected via bluetooth. It means the server can't send the messages directly to a destination but it may send messages via a number other of devices.
But the following situation may occur:
1)S (server) sends message1 to A.
2)S sends message1 to B.
3)S don't see A so it sends message2 to B only (message2 should overwrite message1).
4)Finally B sees A and sends message2. So how should A define is message2 is older than message1 or vice versa?
The only way I found is to add to each message a timestamp from server. Is it really the only one way?
I see two general options:
If the server is the only origin of messages you could also use sequence numbers instead of a timestamp.
If there are multiple origins the sequence could be bound to a unique identification of the server so both values are still unique in their combination.
Example for multiple origins (A, B):
A:1, A:2, A:3, A:4, ...
B:1, B:2, B:3, ...
Each origin could have individual (overlapping) sequence numbers.
The combination of origin id + sequence makes them unique again (compound key).
Pros/Cons:
timestamp: +easy to generate, -possible duplicates on high traffic and low granularity
sequence: +probably shorter than timestamp, +always unique, -requires compound key for multiple origins

Resources