Missing datatype 0x16 -> UNSIGNED24 #466

Activity

1. sveinse commented on Jun 19, 2024

   

   sveinse

   on Jun 19, 2024

   Collaborator

   More actions

   I'm not familiar with UNSIGNED12 in canopen. Datatype 0x16 is according to CiA 301 UNSIGNED24. Where is UNSIGNED12 used?
2. prunith commented on Jun 19, 2024

   

   prunith

   on Jun 19, 2024

   Author

   More actions

   Hi @sveinse you are right i made a mistake UNSIGNED24 is missing UNSIGNED12 does not exist so far.
3. prunith

   changed the title [-]Missing datatype 0x16 -> UNSIGNED12[/-] [+]Missing datatype 0x16 -> UNSIGNED24[/+] on Jun 19, 2024
4. prunith commented on Jun 19, 2024

   

   prunith

   on Jun 19, 2024

   Author

   More actions

   I dig into code to see how it can be implemented, unfortunatly canopen use struct library that not support 24bit data. Perhaps with this work arround it could work unpack('<l', b'\x57\x15\x00' + b'\x00')[0] # unsigned littleendian
5. prunith commented on Jun 19, 2024

   

   prunith

   on Jun 19, 2024

   Author

   More actions

   I see also that pull request already submited to correct that #267 unfortunately it was mixed with other change and not implemented.
6. sveinse commented on Jun 19, 2024

   

   sveinse

   on Jun 19, 2024

   Collaborator

   More actions

   The latest release 2.3.0 contains support for UNSIGNED24 and all the other types that were missing. Done in PR #440. Is there anything that's missing or not working properly?

   👍React with 👍1Reacted by André Colomb
7. prunith commented on Jun 19, 2024

   

   prunith

   on Jun 19, 2024

   Author

   More actions

   Tanks @sveinse @acolomb i m just late from one week , i have not noticed new release. Anyway i confirm it is fixed with 2.3.0.
   Unfortunatly i have noticed some issue with latest python_can 4.4.0 library. I ll open a new ticket if needed.
8. sveinse

   closed this as completedon Jun 19, 2024
9. acolomb commented on Jun 19, 2024

   

   acolomb

   on Jun 19, 2024

   Member

   More actions

   What issues specifically? The canopen 2.3.0 release should work around an incompatible change in python-can 4.4.0 already. And for the next python-can release, the incompatibility is fixed again on their end already, just not released.