I was wondering how you would like to keep track of features that wait for implementation. Should we add a new issue for each observation that might get addressed in the future?
What I have noticed so far:
Multiplexing support is limited in that only one multiplexor can be present in a message
Multiplexing support is limited in that the multiplexor signal is expected to be of length 8 at position 0
Maximum signal length supported appears to be 32 bit
No floating point support
I know a nice dbc file to test these enhancements when they have been implemented. The lab power supply manufacturer ElektroAutomatik uses e.g. 16 bit big endian multiplexors for 32bit floating point nominal values (e.g. device nominal current, etc.). They provide the dbc files for their units free of charge and they can be converted to kcd e.g. by the Python package cantools.
I cannot contribute right now but I thought I make a note for future me (and perhaps you :).
Hello @sebi2k1,
I was wondering how you would like to keep track of features that wait for implementation. Should we add a new issue for each observation that might get addressed in the future?
What I have noticed so far:
I know a nice dbc file to test these enhancements when they have been implemented. The lab power supply manufacturer ElektroAutomatik uses e.g. 16 bit big endian multiplexors for 32bit floating point nominal values (e.g. device nominal current, etc.). They provide the dbc files for their units free of charge and they can be converted to kcd e.g. by the Python package cantools.
I cannot contribute right now but I thought I make a note for future me (and perhaps you :).
ElektoAutomatiks dbc files The fantastic cantools Python package