Missing parameters from EDS file

Good day
I have a problem adding EDS file to library. Most of parameters from EDS files are not imported.

EDS file is for SIKO AG3/1 CAN servo motor. All configuration parameters are removed from improted version. How can I fix it, because it is crucial to access other configuration parameters. These are 5% of parameters i get SIKO_AG03_1_20150311.eds (18.4 KB)
How can the problem be fixed?
Apart from that integration experience is very very smooth. Please don’t ruin first experience.

Hi @Ilja_Sorokins,

Let me reach out to our developers for the Ixxat devices and see if this is something that they have encountered before.


Can you tell me which Ixxat device you’re using?

I guess i posted this in wrong place, may be transfer topic to Software?

CM Module for S7-1200. But it is more like software issue than device issue, as even without any device, adding to catalogue is not working properly

Hi @Ilja_Sorokins,

I just heard back from my colleague and he sent me this information as well as a document analyzing the file you sent over.

the SIKO does not support dynamic mapping
only the displayed values can be mapped
other values must be read / written by SDO commands

The CAN baud rate can be configured via an object and that this option requires a special procedure described in the attached document

analysis of SIKO EDS.docx (104.7 KB)


Thank you for swift response. Dug a bit into the topic and adjusted eds file accordingly, should work now, hopefully wont brick the servo)
Have a nice day

Hi @Ilja_Sorokins,

Just wanted to check and see if you were able to get that working with your servo?


Not got to that point, as i found a more substatial issue at the moment.
SDOWrite returns error 3803 on position setpoint variable.
As per manual this states wrong node ID, but writes to same Node id to other SDO’s perform fine. As one can imagine Position setpoint is crucial for servo operation

EDS-Screen2 EDS-Screen1

I can not figure out my troubleshooting steps

Hi @Ilja_Sorokins,

Here’s what my colleague told me:

there are bugs / misunderstandings in the use of WriteSDO FB:

input parameter: DATASIZE

it informs the FB how many data bytes shall be written to the object
this number of data bytes is written to the addressed object
it must exactly match the byte size of the accessed object:
otherwise the accessed device will response with an error (if it is implemeted according the CANopen specification)

index 607Ah, subindex 2
=> 32 bit value <=> 4 bytes
=> screenshot: 10 data bytes
which is wrong: must be 4

index 6040h, subindex 0
=> 16 bit value <=> 2 bytes
=> screenshot: 4 data bytes
which is wrong: must be 2

input parameter: DATA

the data type of the input is “SDO_WriteData”
“SDO_WriteData” is a byte array
the data format of the entered value in the byte array is little endian

RET output:

RET is 0
when no SDO command is processed
when output BUSY is true

this output is only valid when BUSY output has switched from true to false
afterwards it always displays 0

error code: 16#3803
unsupported access
see page 65 of the manual of the CM CANopen

there are several restrictions concerning SDO commands:
SDO commands running at the same time
=> must access different devices (input NODE must be different)
both FBs access NODE 2
this can be the reason for the error code 16#3803
=> must uses different instances of the FB (o.k. in the customers screenshots) => must use different SLOT (see input SLOT) (o.k. in the customers screenshots)

controlword (index 6040h) and Target position (index 607A) can be mapped in PDOs / are mapped by default in PDOs:

the use of PDOs is much more efficient than the use of SDOs

=> one SDO command can only access one object
=> a SDO command must be finished before the device has to process the next SDO command
otherwise the running SDO command is aborted
=> a SDO command is finished when the SDO response of the slave has been received
when BUSY output of ReadSDO / Write SDO FB has switched to false

thank you
Controlword works fine with wrong datasize. Correct size of 4 does not have effect.
I have logger for RET, that saves any state that is not 0.
Each sdo is no accessed simultaneously, they are triggered individually, only when none other is busy.
Conversion from integer/double integer to byte array is also automated.
Sdo read/write is more understandably written in the manual, however transparent CAN described in the manual does not match what is available in tia, thus i was not able to figure out how to use it yet.
Hopefully will manage to reverse engineer without the manual from demo.
Also contacted SIKO tech support. All SDO(excl. controlword) are read-only in NMT “Operational” state, so for most parameters to be able to correrct them is to switch to “Pre-Operational”.
Other parameters like positioning setpoint are accessible via PDO, which requires again transparent CAN telegram.

As it turned out my understanding of how all this works was completely inside out.

Is there a dedicated manual for setting up transparentCAN?

Demo has very much of extra code, that is writen in STL, which I am not very familiar with, I mostly get away with ladder. And Application note CM CANopen****Description of the transparent CAN demo Is very overwhelming.

I hope i understood correctly, how input data should look like for TransparentCAN in minimal kit?

NO_frames is how many array cells are going to be send in the telegram

I am clearly missing something.
Just sending 00h 00h 00h 00h throws out the error 390A

Which corresponds to Wrong Mode. But i dont see what else can be “Changed” in this application

Hi @Ilja_Sorokins,

Here’s what my colleague sent me:

Transparent CAN mode:
transparent CAN is not supported when the CM CANopen is running as CANopen Manager / Slave
transparent CAN mode does not support ReadSDO / Write SDO FBs.

CANopen Manager / Slave mode:
the transmission of TPDOs is controlled by the CANopen stack of the CM CANopen:
the CM CANopen knows based on the downloaded configuration and the configuration of the PDOs
which CAN identifiers are used
which data are transferred and where to get the data that shall be transmitted
the transmission of a the TPDOs is triggered by the transmission type of the TPDOs:

see screenshot of an example:
CM CANopen uses the CANopen node id 127
the slave device uses the CANopen node id 1

an enabled RPDO of the slave device in PDO Parameters Node-ID 1 is assigned with the TPDO of the CM CANopen that uses the same CAN-ID
an enabled TPDO of the slave device in PDO Parameters Node-ID 1 is assigned with the RPDO of the CM CANopen that uses the same CAN-ID

note PDOs are assigned by the CAN-ID that is independent of the PDO number

RPDO 1 of the slave is enabled and uses the CAN-ID 201h

assigned TPDO of the CM CANopen

TPDO 1 of the slave is enabled and uses the CAN-ID 181h

assigned RPDO of the CM CANopen

i hope that it clarifies the questions


Hi @Tim_hms,
What screenshot are you mentioning?