-
-
Notifications
You must be signed in to change notification settings - Fork 629
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
synchronous RPDOs lost #23
Comments
The standard says: Synchronous PDOs shall be transmitted inside sync window, otherwise they are ignored. They are passed to application immediately after the next SYNC message. However, this part is quite new and is not deeply tested. |
For this application, the sync window is disabled (OD_synchronousWindowLength=0), so I would expect a synchronous RPDO received a few milliseconds after a sync message to be processed on the following sync for any time interval, assuming no other RPDO arrives before the sync. (In this case, the sync interval is 30ms) However, CO_process_SYNC_RPDO calls CO_RPDO_process once per millisecond between syncs with syncWas=0. This clears the RPDO CANrxNew flag before the next sync, and the RPDO does not get passed to the application. If the RPDO happens to arrive in the millisecond before the sync, it does get passed to the application. RPDOs configured as event driven are always processed. |
The following code change in CO_PDO.c fixed the problem for me. void CO_RPDO_process(CO_RPDO_t *RPDO, bool_t syncWas){ |
I checked it and there was a bug (race conditions): Following situation was problematic:
Stack is now updated with the change from above. Operational RPDOs are not supposed to be deleted in any case. (CO_CANclearPendingSyncPDOs() only clears TPDOs outside window.) Thank you. |
I’m using CANopenNode for an actuator project. Asynchronous RPDOs work fine. However, I noticed that some synchronous RPDO commands were getting lost. It looks like CO_RPDO_process() clears the CANrxNew flags every time it is called, rather than just when the sync flag is set and the RPDO processed. The main loop calls CO_process_SYNC_RPDO() once every one millisecond tick. If the sync message arrives once every 10ms and the RPDO arrives at some random time between syncs, there would be a 90% chance of the function resetting the new flag without processing the RPDO. I’m wondering if this is a bug or I’ve misunderstood something. Thanks.
The text was updated successfully, but these errors were encountered: