Video

Our software takes the time stamps as provided by the CAN hardware used. The only modification we can make in the software is to set a new zero point.

Yes correct, this instance of the software is connected to a CAN bus producing data and that gets visualized.

Good catch! Yes, it should.

For PDO there is no client/server defined. PDOs use producers (TPDO) and consumers (RPDO). SDO are client / server communication. Client requests access to an OD entry of a server.

TPDO mapping is done with three objects 0x6078 ,0x606c,0x22a2 and the transmission type is asynchronous i.e 0xff and return type 16bit,32bit,16bit respectively with help of dsp 301 manual as menitoned below. TPDO1 id 0x183 Set 0 to 0x1A00(0) Stop all emissions of TPDO1. Set 0x60780010 to 0x1A00(1) Program the actual current value (object 0x6078) to first 2bytes of the PDO. Set 0x606c0020 to 0x1A00(2) Program object 0x606c for next 4 bytes (actual velocity). Set 0x22a20010 to 0x1A00(3) Program object 0x22a2 for next 2 bytes (temparature). Set 1 to 0x1800(2) Set transmission type in PDO communication parameters to “Transmit every SYNC.” Other PDO communication parameters are not programmable . Set 3 to 0x1A00(0) Activate the three mapped objects. and gave response as in the manual . i think i just mapped the objects . i"m not seeing any response data regarding the objects from the elmo. am i need to do any additional thing. when can i read the tpdo1 data from elmo can u please help me with this

The documents and training describes the default COB-ID assignment. Both the exact CAN ID used and the number of PDOs iused per device is just a default and can be re-configured. Usually it means re-using default COB-IDs from devices not present in the network. EXAMPLE: If in your system you only use node ID 1 to 63 and 64 to 127 are unused (never present), then you can re-assign the default COB-IDs from nodes 64 to 127 to the other nodes.

@@EmSACANopen Thanks for this explanation. I had a suspicion this is the case, that one has to use up some other IDs. But then it's not really true when it is said that one can node can have 512 PDOs, unless you have only a single node.

A RPDO configuration is not "visible" on the bus. It is just the configuration for a consumer, somebody else needs to produce it. Maximum busload caused by a single node or CAN frame repetition is typically not defined and are application specific. For a strictly event time driven system, recommendation is to stay below 90 busload. An event driven system should stay (in average) well below 50% bus load.

SDO, PDO, HB, EMVY are all different services. Each service requires a unique CAN ID to be used. By default this unique CAN ID is determined by a base number plus the node ID of the node using the service. For EMCY: base is 80h, so node 5 uses CAN ID 85h. CANopenIA is a HW product range providing Instant Access to CANopen.

Interfaces supported by this software are from www.peak-system.com/ and www.kvaser.com/

Graphical visualization of PDO data is in Professional and Ultimate, node simulation is in Ultimate. Ultimate also has graphical visualization of simulated nodes' object dictionary data.

Unfortunately our knowledge about MCUXpresso is limited to integrating our CANopen libraries . Please try posting your question in the NXP forums, for example at community.nxp.com/community/mcuxpresso/mcuxpresso-ide/

This depends on the CANopen FD Manager/Master implementation which is not standardized. I would expect that any CANopen FD Manager should also be backward compatible to process PDOs of any length, no matter if 1, 2, ... 8 or more bytes.

@@EmSACANopen Is there any issue with the different message frames? A CANFD message frame is different from a CAN2.0 frame. Is it possible to have a system with mixed slave nodes (some CAN2.0 running CANopen and some CAN-FD running CANopenFD), all controlled by CANopenFD master? Thanks.

Unfortunately no, if you put a pure classical CANopen (or CAN) device on a CANopen FD (or CAN FD) network, it will destroy the CAN FD frames and cause error frames. You need a bridge separating the two. See can-newsletter.org/uploads/media/raw/c8f2bab1e505c72108efc741fa8239fc.pdf

Yes, this is how combination of PDO / SDO works. PDO for independent data communication between devices. At any time (or not at all) Manager can use SDO to configure devices. CANopen Architect Mini is a pure EDS Editor. It does not need/support any HW.

@@EmSACANopen Is Mapping parameters the way you would transfer a file using CanOpen? I don't see another mechanism for sending a large burst of data where the integrity / order must must be ensured!

In CANopen, you can "send" (write/download or read/upload) a file through SDO segmented or block transfer to/from a DOMAIN type OD entry only. The transfer is always started from the SDO client (normally also the master or manager) and connects to one SDO server (normally a slave node).

@@bennguyen1313 This can be done using the segmented or blocked SDO transfer.

@@bennguyen1313 Use (U)SDO for file transfers.