-
Notifications
You must be signed in to change notification settings - Fork 141
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
Comments
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? |
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. |
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 |
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 .. So far I've only tested with making the PDO recipient dynamically mapped. |
You are correct,
I've traced through the canopen stack and found CO_ODF_TPDOcom()
and CO_ODF_RPDOcom, which are triggered on SDO access to the communication
parameters of the PDOs they force a reconfigure and a remapping of the Can
Filters. It was the can filter remapping i thought was not done but it
looks like it is. So the stack can fully support dynamic PDOs.
…On 4 January 2017 at 13:07, jimlittlefield ***@***.***> wrote:
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
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#46 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJtGEYVcvaNzihwKarFuYWWIbhvQL_Mks5rO5l0gaJpZM4LZ9Xa>
.
|
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 |
That could work. I haven't tried the invalid checkbox code version yet. Soon..! |
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
The text was updated successfully, but these errors were encountered: