-
Notifications
You must be signed in to change notification settings - Fork 262
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
Slave writing to 7000 PDO outputs #183
Comments
Sounds like you should have a local copy updated by the 7000 Object. Then you can decide when to update. It is rarly that the 7000 object is the end that is the output. Ex. You have a GPIO outputs, then you need to write that from the update cb_outputs. GPIO_set(0x7000) R/W for 0x8000 is access rights from the master. |
Yes, thank you, that is a method for sure and what I am doing as a work-around. Is it true there is no way to have the master read back the state of the 7K objects? They are 'write-only'? Even if they are updated before the frame goes out? I am thinking here that the master never inspects the incoming 7K objects. The issue with this (if true) is that if one has a running system there is no way to acquire the state of the 7K objects upon ECat connection. I was duplicating them in the 6K in order to have the state but that is quite a bit of overhead. If this is the only way then I suppose that is what I need to do unfortunately. A negative to this is that the in vs out states will not match in the master until they are updated by the master. Shocking there are no R/W objects in ECat, Edit: My mistake on 8K SDOs. They are behaving bi-directional. |
I think your mixing concepts here. PDOs and SDOs work differently. While, PDOs are SDOs mapped to be updated by incoming frames using the 3 buffer process data SyncManagers. They than become subordinated by the processdata exhange. So if you have a SDO 7k mapped as PDOs the get updated by the master as you describe it. Of course the master can access the 7k object as a SDO, it wan be r/w but the write using SDO will be overwritten by the current PDO value. This is just how EtherCAT works |
My 7000 output PDOs are updating correctly from the master. However, some of the 7000 PDOs can be changed on the embedded slave via other means (Keypad, UART console interface, etc). If the value mapped to the 7000 PDOs is changed via means other than the master it is overwritten by RXPDO_update(), the local change is lost, and the target always reflects the state of the PDOs from the master, even though no change was initiated by the master.
Is there any way to have the master observe (read) the state of the 7000 output PDOs and not change them unless specifically written by the master? It seems the 7000 PDOs are 'write-only' opposed to 'read-write'.
Edit:
It seems this is also true of the 8000 SDOs. They are specified as r/w in the esi configuration tool but it seems they are never read from the slave, only written to the slave.
The text was updated successfully, but these errors were encountered: