Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Object Parameter Validity #40

Closed
f1-stuo opened this issue May 4, 2021 · 2 comments
Closed

Object Parameter Validity #40

f1-stuo opened this issue May 4, 2021 · 2 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@f1-stuo
Copy link

f1-stuo commented May 4, 2021

Hi,

  • Device: [S32K116]
  • OS: [none]
  • Version [v4.1.5]

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

@michael-hillmann michael-hillmann added this to the 4.1.6 milestone May 4, 2021
@michael-hillmann michael-hillmann added the enhancement New feature or request label May 4, 2021
@michael-hillmann
Copy link
Contributor

Great that you can use it, nice to hear!

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.

@f1-stuo
Copy link
Author

f1-stuo commented May 5, 2021

That sounds like a great plan.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants