birkelbach / python-canfix Goto Github PK

Add debug logging to the library

After running sudo python3 setup.py install, I had to manually copy the entire canfix/messages directory into the installed egg to get it to work.

It would be nice to have some kind of constant definitions for the bit indexes for things like the trim switches, autopilot controls and the like. i.e. TRIM_PITCH_UP = 0, TRIM_ROLL_LEFT = 3...

But that key is not present in canfix.xml

Need to create properties for setting and getting the value of a parameter. It should check the type of data that is being set and either massage it into the correct type for the parameter or raise an error at this point. Otherwise the bad value winds up in the packing/unpacking logic and is much more difficult to figure out.

An example would be writing an array of bytes. Really bytes are bit fields so they should be written as an array of arrays. [[False]*8]*5] for example If the user passes an array [False]*5 we could massage that. If they pass an integer [0] we could do that too. If they pass a float then we have a problem.

Need to add property methods to the NodeAlarm class for the node, alarm and data properties. Mainly for checking the integrity of the arguments. These errors would eventually be caught, probably by the python-can package, but it'd be better if we caught them at assignment time as it'll be less confusing to the developer.

I setup the fixgateway to send the fixid WPNAME using canfix id 1152 ( 0x480) that is identified as CHAR[5]

If WPNAME contains exactly 5 characters it works fine.
If WPNAME contains less than 5 characters this library will throw a "string index out of range" exception at:

The obvious fix is to ensure WPNAME is always 5 characters, likely padded with spaces when needed.
The question is, should this library do that that or should it be done by whoever is calling this library?
Might not be simple to solve it in this library, do we pad left or right? What character do we pad with? Some hard coded options is unlikely to satisfy all use-cases.

For the moment I'm going to fix this in my fixgateway plugin but that will only fix it for my specific use-case.
This issue will still be waiting to bite the next person who wants to send strings via CAN.

Right now the library returns None in a parameters value property if there was not enough data in the can message. i.e. Only two bytes were present and it was a DINT or FLOAT type. Should this raise an exception instead?

Add the ability to generate objects completely with arguments to the constructor.

Right now the only argument for most of the classes is a can.bus.Message type that is used to initialize the object. Should expose all of the arguments to assign the rest of the properties for each object.