I am unable to understand the CANopen Protocol. I am aware of the working of CAN and how a CAN frame looks like. A CAN data or remote frame contains the Start of Frame , Message Identifier Field, DLC, RTR , Data(Payload), CRC , ACk fields, etc. I am aware that the CANopen standard utilizes the CAN bus to send the CAN messages. However , the way in which a CANopen's CAN frame looks is different where it contains a COB ID+Node ID in the Message identifier field and in the payload field , it contains object dictionary related information. I would like to ask the following questions therefore:
How are the object dictionaries defined. I am aware that it is a
table containing an ID , sub ID, Datatype information about the data
it contains , the manufacturer information for the respective data
entry , etc . Are they all hard coded as an m*n multidimensional
array in the software stack?
I am confused with the terms transmit PDO and Receive PDO. Is it similar to CAN data frame and CAN remote frame ?
What is PDO mapping and how can i identify which object ID in the object dictionary is mapped to which object ID in the PDO mapping
table. Both use the same terms Object ID ?
I am actually very new to CANopen and i have asked these questions based on my initial understanding. I was unable to find a detailed explanation in the CiA website.
Thank you in advance
Krishna
It is not so easy to understand it!!
CanOpen is a communication between Master (client) and Slave (server).
An device like a sensor is a Slave.
The slave has an OD (object directory). The manufacturer provides all informations about it. Ex. if i want to read the temperature, its location is at adress 0x2040 at sub index 00. Then the master (our system) needs to make this request. To do this, you need to configure the device by sending some request (with SDO) in order to change the TPDO1 mapping (0x1A00) and TPDO1 communication parameters (0x1800). And be able to receive by the device the temperature. The device will not work alone.
SDO (read/write) allows OD access entries. Ex. change the TPDO1 mappings.
PDO is the output/input to the device once operational.
There is NMT Master commands to put the device in operational mode or to send a SYNC or Heartbeat. Depends what the device needs?
Ex. 080h 00 : SYNC send by master
280h 06 E5 EF 02 00 00 00 : response of device by TPDO2
000h 02 01 1F : put the device with ID = 1F in operational mode
If you want a good example device POSITAL FRABA absolute rotary encoder with can open interface.
Hope this will help you a little bit!!!
Related
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.
Read a lot of specifications and still can't get a simple thing.
All UDS requests encapsulated in ISO-TP packets, which are encapsulated in simple CAN frames, so ECU constantly receives a stream of frames from CAN bus.
How does ECU decide that this CAN frame is a part of any high-level protocol?
For example, I've sent Security request to ECU, CAN frame data will look like this
02 27 01
How does ECU determine that this is not just a chunk of data but a part of the protocol?
I wasn't able to find any relation to ISO/OSI stack when high-level protocols "talk to each other" using headers, so we know how to decode data packets.
The CAN message IDs that are used for specific protocols are defined per system.
In most cases the OBD-II will be sent over CAN ID 7DFh for the query and higher IDs for responses from different modules, but even that might be different on specific car models.
One way of figuring out the CAN IDs that are used for UDS-based communication is to send simple tester-present (SID 3Eh) messages and watching for CAN IDs which seems to have an appropriate response.
UDS via CAN is specified in the DoCAN ISO-15765-2 part and describe the network and transport layer for a functional (broadcast) and physical (p2p) communication between ECUs or better control functions.
Normal CAN id's don't implement any network functionalities like a addressing. For that purpose the SAE J1939 network layer is used. In a J1939 network each CAN client has a address and each functionality a parameter group (PGN). All of this is encoded in a 29bit CAN ID. For example the CAN ID 0x18EF8081. This will transport a message from the CAN client 0x81 to 0x80 via the PGN 0xEF, 0x18 is the priority.
In UDS over CAN the PGNs 0xDA (physical) and 0xDB (functional) are used for all communications. With that information's you can implement a CAN ID filter which match only the PGN part of the CAN ID.
I have a huge pcap file. I want to know facebook usage in terms of data transfered (upload, download). For that, I am using wireshark to read this file. From a question on stackoverflow , there are many fields that can be used to find bytes.
frame.len==243
ip.len=229
udp.length==209
data.len=201
Now, I have test frame.len and ip.len both gives different results. What I should consider correct ? I am a newbie in networks terminology and I have to just find correct data transfered.
What happens, when you connects to server and requests some simple page:
Server application generates requested data (e.g. <body>Hello world</body> string) and passes it to HTTP layer
HTTP layer generates necessary header according to RFC (specifies HTTP version, status code, content type etc), prepends it to generated data and pass everything to TCP layer
TCP layer may break data into more than one pieces (not our case, message is already too small) and prepend necessary info for transport layer to each piece (src/dst port number, sequence number, some flags, checksum etc), then passes it to IP level
IP layer prepends necessary info for routing (source/dest addresses, TTL and other stuff), then passes it to lower layer (e.g. Ethernet)
Ethernet adds its part (MAC addresses, maybe VLAN tags) and pushes all to physical device
Resulted data is sent byte-by-byte from server's NIC to network
So your question is actually up to you. What do you want to measure? Is it "data, which I need to display excluding all auxiliary info"? Or is it "all number of bytes I need to send/receive for getting this lovely cat picture"? Here is a list of fields to get size of each part:
To get data lenght only (as string, unfortunately): http.content_length_header == "606"
To get (data + HTTP header) length: tcp.len == 973
To get (data + HTTP + TCP + IP layers): ip.len=1013
To get every byte sent: frame.len == 1027
If you want to measure bandwidth occupation, use frame.len. If you're interested in "pure site weight", it should be independent from environment, so use http.content_length_header. Things might become more complicated on high level considering the following:
Era of HTTPS means you can't easily observe HTTP content in traces, so tcp.len might be the highest option
Some data (e.g. audio, video) is transferred over different protocol stack (e.g. IP - UDP - RTP)
I'm working with a ELM327 and I'd like to be able to set the header and data portions of CAN messages to be sent. I see that there is a code for setting the header for messages
SH xxyyzz
But I'm having trouble finding out how to set the data portion and control when the message gets sent.
Do these both occur when I send a ASCII request for a PID with extra characters for the data field?
And would that use the header that was set by the SH command?
Is there a better way to do this?
Datasheet: http://elmelectronics.com/DSheets/ELM327DS.pdf
If you're using the ELM327, and you're on a protocol such as J1850 vpw, or J1850 pwm (older than 2003 CAN vehicles).. Then you will use this to set the header.
The header will consist of xx yy zz
xx = priority of message (i.e. 68)
yy = Target address of module you want to talk to (i.e. 5A)
zz = Sender address, which can usually be F1
So your command would look like this ATSH 68 5A F1
This sets the header.. Now you want to send data. Any data you send from now on will use that header, and send the data to that module.
So if you wanted to get the RPM's, you can just send 01 0C
You will get something like 41 0C 23. The last data byte is the value of RPM's. You will have to figure out the formula to convert this into a human readable format though.. A lot of information can be found here..
https://en.wikipedia.org/wiki/OBD-II_PIDs
By the way, if you're communicating on a CAN network, you would just use the module ID as the header.. ATSH 7E0, then send your data. all vehicles 2008+ are CAN.. some 2003-2007 are also.
This might be an old question, but I just found an online link which describes in detail how to send arbitrary CAN messages using the ELM327. So anyone (like me) coming past that question can still find a valid answer.
Look here for details on send arbitrary CAN messages with the ELM327:
https://www.elmelectronics.com/wp-content/uploads/2017/11/AppNote07.pdf
Best
If you're using an ELM327 chipset, you need to call ATSH or AT SH, to set the header first. Then send the message separately (The data bytes).
https://www.sparkfun.com/datasheets/Widgets/ELM327_AT_Commands.pdf
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 |
+----------------+---------+