I want to use CANopen, and by the preconfigured set a device can have more than one COB-ID(as it has different function codes)
I want to know if the CAN bus frame identifier uses CANopen's COB-ID as it is.
A CANopen node cannot use multiple identifiers at the same time, but it's technically possible to reconfigure the node-ID. According to CiA301 - CANopen application layer and communication profiles, during NMT state initialization the parameters of the manufacture specific profile area and of the standardized device profile area are set to their power-on values.
One way to implement this is to assign a default node-ID for the CANopen node. Then reserve a SDO object in the object dictionary to modify the node-ID after reset or power-on. Note that if you want to fully follow CANopen standard, when you change the node-ID, the CAN-ID allocation modify the IDs for the other NMT states and communication objects such as SDO, PDO, etc.
Check this link for further information.
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.
Is there a way to assign relative weights to OCKCarePlanActivity instances, to differentiate their priorities (and enable adding optional activities)? For example, "jogging" and "taking chemo drug" would have very different priorities, but all activities account for the same percentage of completion in the Care Card.
I don't think this capability exists based on the CareKit docs, but just wanted to double check.
The implementation guides (and most web resources I can find) describe the GS06 and ST02 Control Numbers as being unique only within the Interchange they are contained in. So when we build our GS and ST segments we just start the control numbers at 1 and increment as we add more Functional Groups and/or Transaction Sets. The ISA13 control numbers we generate are always unique.
The dilemma is when we receive a 999 acknowledgment; it does not include any reference to the ISA control number that it's responding to. So we have no way to find the correct originating Functional Group in our records.
This seems like a problem that anyone receiving functional acknowledgements would face, but clearly lots of systems and companies handle it, so what is the typical practice to reconcile 997s or 999s? I think we must be missing something in our reading of the guides.
GS06 and ST02 only have to be unique within the interchange, but if you use an ID that's truly unique for each one (not just within the message), then you can skip right to the proper transaction set or functional group, not just the right message.
I typically have GS start at 1 and increment the same way that you do, but the ST02 I keep unique (to the extent allowed by the 9 character limit).
GS06 is supposed to be globally unique, not only within the interchange. This is from X12-6
In order to provide sufficient discrimination for the acknowledgment
process to operate reliably and to ensure that audit trails are
unambiguous, the combination of Functional ID Code (GS01), Application
Sender's ID (GS02), Application Receiver's ID (GS03), and Functional
Group Control Numbers (GS06, GE02) shall by themselves be unique
within a reasonably extended time frame whose boundaries shall be
defined by trading partner agreement. Because at some point it may be
necessary to reuse a sequence of control numbers, the Functional Group
Date and Time may serve as an additional discriminant only to
differentiate functional group identity over the longest possible time
frame.
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.