You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Great work on the stack! We have it implemented on a NXP S32K116, and it works really well. During the implementation though we've noticed a few discrepencies (possible bugs). So I thought I'd post what we've observed.
'Object Parameter Validity'
Some CANopen objects seem to accept invalid values. This is true of objects such as COBID SYNC (0x1005), and COBID EMCY (0x1014) when '0' is set. It's not accepted as a valid value by the stack, but it is accepted i.e. an 'invalid' respose is not transmitted back to the master.
Also, and I think this is more in the realm of a feature request, but it is related. Would it be possible to create a mechanism that would allow limits on object parameters to be easily configured such that if they were exceeded, an 'invalid' CANopen response was transmitted back to the master?
Many thanks,
Stu
The text was updated successfully, but these errors were encountered:
Regarding the issue with the write access of your mentioned COBID object entries from the master side, I think you are right that we are not 100% standard conform when using object variables of a basic type (e.g., CO_LONG). The basic data type is allowing every value in the full range of the corresponding data type.
When we need to check certain values or limit the range of an object entry, we should add a user objects. With the type-functions (read, write, ctrl, and size), we can implement any logic. The user object type functions are separated in a small structure, so we can reuse them in multiple objects easily. The example Write serial number illustrates the mechanism.
For some DS301 defined objects, there are such type-functions already implemented (unfortunately not for writing your mentioned objects).
If you have some time: The types for the handling of write operations to these objects are a highly welcome enhancement for the stack.
There is a similar type function already available for the SDO server COBID (see: COTypeSdoIdWrite).
If you can wait: I try to manage an update next month, with some documentation enhancements. I think I can include these needed type functions for any COBID objects in a standard object dictionary, too.
Hi,
Great work on the stack! We have it implemented on a NXP S32K116, and it works really well. During the implementation though we've noticed a few discrepencies (possible bugs). So I thought I'd post what we've observed.
'Object Parameter Validity'
Some CANopen objects seem to accept invalid values. This is true of objects such as COBID SYNC (0x1005), and COBID EMCY (0x1014) when '0' is set. It's not accepted as a valid value by the stack, but it is accepted i.e. an 'invalid' respose is not transmitted back to the master.
Also, and I think this is more in the realm of a feature request, but it is related. Would it be possible to create a mechanism that would allow limits on object parameters to be easily configured such that if they were exceeded, an 'invalid' CANopen response was transmitted back to the master?
Many thanks,
Stu
The text was updated successfully, but these errors were encountered: