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

Access type cannot be changed. #46

Closed
jimlittlefield opened this issue Jan 3, 2017 · 7 comments
Closed

Access type cannot be changed. #46

jimlittlefield opened this issue Jan 3, 2017 · 7 comments

Comments

@jimlittlefield
Copy link

As part of dynamic PDO mapping its necessary to change the "number of mapped objects" (subindex 0) for an PDO mapping parameter. I'm finding that for all the new RPDO's that I've added to the OD, the access type setting is grayed out so you can't change it from the default "ro" setting. I'd like to have the number of mapped objects set to zero but be able, at runtime, to change the setting when the RPDO is to be enabled. To do this, I need the accesstype of RPDO mapping, subindex 0x00 to be rw.

It seems like there may be a bug in the handling of the combobox.accesstype.Enabled property in DeviceODView.cs. I changed line ~300 to change comboBox_accesstype.Enabled = false; to comboBox_accesstype.Enabled = true; This seemed to allow me to change the accesstype as necessary but I don't know if it breaks something else.

jl

@robincornelius
Copy link
Owner

Dynamic PDOs were not initially considered as this code started off based on a generator for CanOpenNode that does not support dynamic pdo mapping.

As you discovered the restrictions are only enforced in the GUI to attempt to guide the user into not breaking too many things but i keep finding these exceptional use cases with canopen that are annoying and require special handling.

Before i just go ahead and change the code so that Access Type and possibly default value are editable i'm trying to see if there is better logic here that could be applied.

My first thought would be rather than change the code in DeviceODView.cs it might make more sense to apply the special logic to DevicePDOView.cs so that the number of mapped objects and the access type could be specified here? This would keep the PDO editing functions together and probably make better UX sense.

The other question is should you be changing number of mapped objects? or should this be a fixed array size of 8 then unused object mappings should be either 0x00000000 or 0x8??????? this is probably very implementation specific. Is there anything in any of the CanOpen standards that define this behavour? I know canopen node will ignore any 0x00000000 mappings .

The other question is what other valid use cases are there for wanting to change Number Of mapped objects on other record/array objects at run time? I am aware of 0x1003 but is this something that should be generally allowable or only on a few specific cases?

@robincornelius
Copy link
Owner

Ah this answers one of my questions, its not the standard but its from the official web page

https://www.can-cia.org/can-knowledge/canopen/pdo-protocol/

"2. Set PDO mapping invalid by writing 00h to sub-index 00h of the related mapping entries."

So it must be allowable to change access type on sub 0x00 of mapping entries as for dynamic PDOs it is always necessary to write to sub 0 where as for fixed PDOs you require that field to be read only.

@jimlittlefield
Copy link
Author

The cia link you cite is exactly what I'm trying to do. Since CANopenNode supports an SDO client it seemed to me that the ingredients to do Dynamic PDO mapping were there .... so I'm interested in your point that CANopenNode does not not support Dynamic PDO mapping. I thought it does based on this thread ... https://sourceforge.net/p/canopennode/discussion/387151/thread/1a7943df
jl

@jimlittlefield
Copy link
Author

Further to the Dynamic PDO mapping....I've gotten a basic test setup working. Your tool can be used (with the modification I original described) and the following ..
a) Map all the PDO communications and mapping objects to RAM and make them accesstype rw
b) Use the in-built CANopenNode SDO client to alter the PDO mapping, comm. objects

So far I've only tested with making the PDO recipient dynamically mapped.
jl

@robincornelius
Copy link
Owner

robincornelius commented Jan 4, 2017 via email

@robincornelius
Copy link
Owner

As a possible enhancement it may be an idea to set the number of sub objects in the mapping to 0 if the invalid checkbox is ticked. At the moment you can now edit the text box and change the number but if you try to edit the PDO mapping page it will recalculate

@jimlittlefield
Copy link
Author

That could work. I haven't tried the invalid checkbox code version yet. Soon..!

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

No branches or pull requests

2 participants