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)
SIKO:
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
note:
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 customer
s screenshots)
hint:
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
note:
=> 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