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
Related
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.
I basically understand the concept of PDO mapping in CANopen networks. It allows to to broadcast real-time data with small header.
how it is made? How do I setup my devices to know how to send/receive PDO's? Do I need some kind of software for that?
A lot the answers to your questions depend on the specific devices you are using, but in general...
Do I need some kind of software for that?
You do not need specialized software to configure a CANopen device. They can be configured over CANbus using SDOs. A USB CANbus dongle is more than sufficient although manuually constructing SDOs is tedious. Companies exist that provide software to configure any CANopen device e.g. Vector. Often vendors will provide a specialized GUI to configure their devices e.g. AMC's DriveWare. If one is available you should probably use it.
How is it made?
PDOs (Process Data Objects) in contrast to SDOs (Service Data Objects) do not include meta-data about the contents of the message and TPDOs may be transmitted without a specific request from the master. This allows PDOs to use the bus more efficiently. The trick is that the contents of PDO messages must be agreed upon ahead of time. This agreement is specified using the PDO Communications Parameters and PDO Mapping Parameters entries of your devices Object Dictionary. How they may be configured or if they can be configured at all is device dependent. Most commonly PDOs can be configured at run-time during pre-operational mode through SDOs. Though this may be (and is likely to be) unnecessary if the defaults provided by your device are sufficient.
The contents of a PDO is configured through its corresponding "Mapping Parameters" in the devices Object Dictionary. TPDO Mapping parameters start at index 0x1A00. TPDO0 corresponds to 0x1A00, TPDO1 to 0x1A01 etc.
The mappings are held in the sub-indexes and are encoded as 32-bit unsigned integers. The format is first the 16-bit index then the 8-bit sub-index and lastly the size in bits of the parameter to use. The granularity of the size is device dependent. Some may only provide byte level granularity. E.g. if you had a REAL32 variable in the object dictionary at 0x2000,0x02 you wanted sent as the only parameter of TPDO0 you would set 0x1A00,0x01 to 0x20000220. RPDOs are configured in the same fashion with their indexes starting at 0x1600.
The next piece in the puzzle are the communication parameters. RPDOs usually do not need to be configured in this fashion. TPDOs do need configuration. The indexes start at 0x1800 and correspond to the TPDOs in the same fashion as the mapping parameter indexes.
COBID (0x01) UNSIGNED32 Arbitration/COB-ID PDO will use.
XMIT_TYPE (0x02) UNSIGNED8 When PDO is transmitted
INHIBIT_TIME (0x03) UNSIGNED16 Minimum time between PDO messages (useconds)
EVENT_TIME (0x05) UNSIGNED16 Timeout for sending (mseconds)
PDO message layout takes the associated TPDOnCOMPARAM,COBID for the arbitration ID and appends each of the mapped parameters from TPDOnMAPPARAMS. For TPDOs this is done internally by the device and is sent. For RPDOs the master does this, sends the PDO and device decodes the message writing each parameter to its Object Dictionary.
How do I setup my devices to know how to send/receive PDO's?
The default connection set includes four TPDOs (transmitted from node), and four RPDOs (received by node). More can be specified (up to 512 each) depending on your device.
PDOs are only transmitted/received when a CANopen node is brought into "Operational Mode". To do this you need to send an NMT (Network ManagemenT) start command (Code Specifier = 1). Using 0 for the node ID indicates a broadcast message that all nodes will respond to.
NMT Messages:
Have a COB-ID of 0
Have a payload of 2 bytes
NMT Message Format (CAN-bus payload):
+--------------------------+
| Code Specifier | Node ID |
+----------------+---------+
| ff | ff |
+----------------+---------+
How a CAN Bus controller decides based on message identifier that this particular message belongs to it?Is it like the receiver already know that if identifier has suppose value 5 then its for me . And we program receiver to tell it that you should be interested in value 5 ?
The software in the CAN node must decide what message IDs it is interested in, based on the network specification which is usually some kind of document or other electronic representation of which messages contain what sorts of information. If a message arrives that is of no interest, it simply does not process it and the software returns to what it was doing just before the message arrived (assuming interrupt driven CAN handling).
Some CAN controllers (ie the part of the chip which does the CAN protocol transmission and reception) have message filtering which means that uninteresting messages can be dropped before they reach the software. Other controllers have message filtering which can be set to accept only a single message ID in a particular "message box", and these can be configured to accept the messages you are interested in. Again, other messages are dropped. Some controllers have both filters and message boxes.
At the CAN protocol level all nodes in a CAN network are equal and make a decision about whether to process a message or not. A "CAN controller" is a higher-level concept; it still needs to examine the message identifier like any other node.
Note that "processing" a message is different to the CAN protocol message check and acknowledgement. All nodes take part in that processing unless they're in "listen only" mode.
Update:
How you decide which message to process depends on what you are trying to do and the higher level protocol in use over CAN. In principle you mask out the ID bits that are relevant and then test them to see whether the message should be processed.
For example if you want to process all messages with 5 (binary 0101) in the low order four bits, your mask is 15 (binary 1111), you binary-and this with the received message ID, and then you compare the result with five.
For example:
(msg_id & 15) == 5
is a way of coding that test. Which bits you care about, and your implementation details depend on many other factors.
Specifically for PDU1 (Protocol Data Unit) messages, a destination address is specified (byte 3). If a device receives a message not addressed to it, it can simply ignore it. Addresses are assigned by various standards, or a manufacturer may assign them ad-hoc.
In the general case the CAN-ID (bytes 0-4) contains all the details about what kind of message it is, and devices can inspect particular fields to decide whether they care about the message. For example the transmission controller probably doesn't care about battery status messages, nor the fuel gauge about which doors are locked.
I have a strange finding about the heartbeat-protocol in CANopen. Maybe somebody else has seen something like this and maybe it is supposed to work like this... Anyway, here's what it's about:
In CANopen there are two timeout-based life-guarding mechanisms: the first is node guarding, which I will not mention further, since it's considered old news.
The other one is called heartbeat. It is pretty simple: Any participant on the network sends a regular message stating its node ID and its state. The frequency is defined by object 0x1017sub0 and is called heartbeat-producer-time. If it is set to zero, no heartbeat is being sent.
Any other participant can then define a number of nodes it wants to find on the network plus the maximum time there may be between two consecutive heartbeat-messages. This information is stored in object 0x1016sub1..n as 32-bit entries for as many nodes as this particular node wants to listen to.
The entries consist of the node ID (bits 22 to 16) and the mentioned maximum time that may elaps between heartbeats, called the heartbeat-consumer-time (in bits 15..0). Again if the entry is zero, it is being ignored.
As you may have gathered, there is no distinction between network-master (node ID 1) and slaves (node IDs 2 to 127).
So far the theory, now for my problem:
I configure one of the slave-nodes in my network as a heartbeat-consumer for the master, so there's an entry in object 0x1016sub1 that looks like this: 0x000107D0. Meaning that a heartbeat-message from the master is expected after at least two seconds.
I have observed that this works in two examples. If I send a master-heartbeat for a time and then stop, the node either returns to pre-operational mode or sends an appropriate emergency-message.
If I don't send any master-heartbeat-messages, I would expect that after I start the node (send it into operational mode) it takes at most two seconds for the node to either return to pre-operational mode or send an appropriate emergency-message or perhaps even both. But in the two examples I tried, nothing happened. If I never send any heartbeat, the node never expects one and just keeps on running.
The two examples are very different from each other. I am not sure whether they use the same CANopen-stack library perhaps.
Is there an explanation?
If you read CANopen User Manual, section 1.3.1.6, page 39, you will notice that the heartbeat consumer is first activated upon receiving a heartbeat from the producer. I would assume then that, since in your example the first heartbeat is never sent, the consumer is not activated.
While reading the ERTS user's guide, I found this section:
The only signal ordering guarantee given is the following. If an entity sends multiple signals to the same destination
entity, the order will be preserved. That is, if A sends a signal S1 to B, and later sends the signal S2 to B, S1 is
guaranteed not to arrive after S2.
I've also happened across this while doing further research googling:
Erlang Reference Manual, 13.5:
Message sending is asynchronous and safe, the message is guaranteed to eventually reach the recipient, provided that the recipient exists.
That seems very vague and I'd like to know what guarantees I can rely on in the following scenario:
A,B are processes on two different nodes.
Assume A does not crash and B was a valid node at some point.
A and B monitor each other.
A sends messages M1,M2,M3 to B
In the above scenario, is it possible that B receives M1,M3 (M2 is dropped),
without any sort of 'DOWN'/'EXIT'/heartbeat timeout being received at A?
There are no other guarantees other than the ordering guarantee. Note that by default you don't even know who the sender is, unless the sender encodes this in the message.
Your example could happen:
A sends M1 and M2
B receives M1
The node on which B resides gets disconnected
The node on which B resides comes up again
A sends M3 to B
B receives M3
M2 can be lost on the network link in this scenario. It is highly unlikely this happens, but it can happen. The usual trick is to have some kind of notion of such errors. Either by having a timeout trigger, or by monitoring the node or Pid which is the recipient of the message.
Updated scenario:
In the updated scenario, provided I read it correctly, then A would get a 'DOWN' style message at some point, and likewise, it would get a message telling you that the node is up again, if you monitor the node.
Though often, such things are better modeled using an idempotent protocol if at all possible.
Reading through the erlang mailing-list and the academic faq, it seems like there are a few guarantees provided by the ERTS implementation, however I was not able to determine whether or not they are guaranteed at a language/specification level, too.
If you assume TCP is "reliable", then the current implementation guarantees that
given A,B are processes on different nodes (&hosts) and A monitors B, A sends to B, assuming A doesn't crash, any message delivery failures* between the two nodes or host/node/process failures on B will lead to A getting a 'DOWN' message (or 'EXIT' in the case of links). [ See 1 and 2 ]
*From what I have read on the mailing-list thread , this property is almost entirely based on the fact that TCP is used, so "message delivery failure" means any situation where TCP decides that a failure has occurred/the connection needs to be closed.
The academic faq talks about this like it's also a language/specification level guarantee, however I couldn't yet find anything to back that up.