CANOopen; SDO ParamRange mapping

2020-02-27T13:58:07.150000Z

Thank you for your reply Tim.

I recognize that CoDeSys is also doing some parametrization to the devices. And I think the two do not mix well.
Luckily CoDeSys has the NoInitialize option for the RemoteDevices.

When using a SDO_Write function block, and doing parametrization manually, the steps are:
- listen to boot-up messages
- parametrize the device
- set the device to operational

That is a lot of functionality!

I think I'll miss-use some PDOs to get the parameter-data to the slaves.

CANOopen; SDO ParamRange mapping

2020-02-27T13:58:06.438000Z

The SDO data comes from the .eds file. These are normally the default settings of the slave.
When you change these settings, the CAN master (PLC) will first send these settings to the CAN slave before it will put it in operation mode.

In your case, when you don't know these settings, or when they need to be changed during operation, you need to use the specific SDO_Write function block to change the parameters in the slave.

CANOopen; SDO ParamRange mapping

2020-02-27T13:58:06.207000Z

In the slave local device, I can map a SDO ParamRange to a variable. See CANOpen_01_slave_local_SDO_param_variable_mapping.JPG
In the master, I do not see any SDO ParamRange in the 'CANopen I/O Mapping' tab. See CANOpen_02_master_SDO_param_variable_mapping_missing.JPG
The master has an SDO tab, where I can specify a constant. See CANOpen_03_master_SDO_param_constant_value.JPG

Here is my problem: Some of the data in the SDO ParamRange is not known at compile time, at the office. It becomes available in the factory, where it is a constant at installation.

Did somebody figure out, with a work-around, how to map a variable to a SDO ParamRange, in the master?

I use 3S' CANopen libraries. CoDeSys V3.4 and V3.5.

Regards,

Recent posts to CANOopen; SDO ParamRange mapping

CANOopen; SDO ParamRange mapping

CANOopen; SDO ParamRange mapping

CANOopen; SDO ParamRange mapping