Add support for CANable USB to CAN interface

[RayDar]

I thought this would be a good place to post an an official 'TODO' for adding support for a USB to CAN adapter, such as the CANable Pro, which can be purchased online (Aliexpress) for 10 USD or so. This is the only thing keeping me (and likely many others) from using this wonderful piece of software.

[andrey-pr]

This task currently in progress 👍

[mstaack]

will something like this also be supported?

https://www.inno-maker.com/product/usb-can/

[onno204]

Hi @andrey-pr ,

I have bought a CAnable usb.
I see you have already created the branch canable, are there any things to keep in mind. Or can this branch be tested? (I have a Bafang m200).

[andrey-pr]

Sorry, development of canable driver is paused. Branch "canable" is currently absolutely unusable

[onno204]

Thanks for the reply.

I received my CANable-usb today, so I was keen to setting it up before seeing your comment.

I have merged the master branch into the canable branch and did a ton of tinkering with the canable class.
I have finally managed to receive can data and make it show-up in the UI.

Tomorrow I will look into sending data onto the can-bus. I hope this fixes a lot of fields being empty in the UI.

(As you can see some of the fields are still empty: https://imgur.com/a/LcdiD5D )

[onno204]

Hi @andrey-pr ,

I could use your help a little bit since I think you have already looked at this problem.
I'm having trouble collecting the serial-numbers & hw / software version.

I do receive some data on the can bus when said data is requested, but looking at the length of the data, it seems I am still missing some data?
(it is not even close to the demo data)

I do think it has something to do with the MULTIFRAME_START = 0x04 of the CanOperationCode
Do I need to ACK the data or something?
I hope you can help me.

This is the received data:
Hardware version (3):
{canCommandCode: 96, canCommandSubCode: 0, canOperationCode: 4, sourceDeviceCode: 4, targetDeviceCode: 5, data: [3]}
Firmware version (4):
{canCommandCode: 96, canCommandSubCode: 1, canOperationCode: 4, sourceDeviceCode: 4, targetDeviceCode: 5, data: [4]}
model(32):
{canCommandCode: 96, canCommandSubCode: 2, canOperationCode: 4, sourceDeviceCode: 4, targetDeviceCode: 5, data: [32]}

[andrey-pr]

Hi @andrey-pr ,

I could use your help a little bit since I think you have already looked at this problem. I'm having trouble collecting the serial-numbers & hw / software version.

I do receive some data on the can bus when said data is requested, but looking at the length of the data, it seems I am still missing some data? (it is not even close to the demo data)

I do think it has something to do with the MULTIFRAME_START = 0x04 of the CanOperationCode Do I need to ACK the data or something? I hope you can help me.

This is the received data: Hardware version (3): {canCommandCode: 96, canCommandSubCode: 0, canOperationCode: 4, sourceDeviceCode: 4, targetDeviceCode: 5, data: [3]} Firmware version (4): {canCommandCode: 96, canCommandSubCode: 1, canOperationCode: 4, sourceDeviceCode: 4, targetDeviceCode: 5, data: [4]} model(32): {canCommandCode: 96, canCommandSubCode: 2, canOperationCode: 4, sourceDeviceCode: 4, targetDeviceCode: 5, data: [32]}

This kind of parameters (version names, etc) transported several frames per parameter. One frame have limited length and this parameters are longer, so the first frame will be returned as MULTIFRAME_START, then several with MULTIFRAME, then MULTIFRAME_END and after each one you need to answer with NORMAL_ACK. Code that processes this frames is located in device/besst/besst.ts file, but its not stable enough

[onno204]

Thanks for explaining the process.
I have created a generic can frame handler class, but those multiframes are all-over the place. (some targets need an ACK before sending the middle/end frame. And some targets will just send you all the multi-frames.)

I also had an issue where receiving different subcommands from the same target would just send the reply of 3 data points in a single sequence, so this required me to add a check if the message is complete at every received multiframe command.

The first mutliframe message contains the bytes' length of the incoming message. I have used this as much as possible to try and repair the received frames. When an ending frame is received, the buffer is always cleared. Broken frames are discarded, but it seems to be pretty stable now.
(When a buffer is complete a new CanFrame is constructed and internally emitted as normal can event.)

What seems to make the multiframes wayyy more reliable is adding a timeout between sending multiframe requests. (I have added 200ms * (SubCode % 5) for all requests to Code 60)

I do still seem to be missing some data, but maybe that is my Bafang M200 (Veloretti) not having those data points.
Do you have Canable device and time to test if it is the code or my engine that is causing the data to be unavailable?

Eg. when clicked the refresh button on the engine page I see 2 parameters(conParams_1 & conParams_2) not loaded:
https://imgur.com/a/bcTcryd