CAN FD empty payloads

[dwood-appareo]

OS and version: Raspbian GNU/Linux 10 (buster)
Python version: 3.7.3
python_ics version: 910.10.post6
Hardware: valuecan4 -2FD
Driver: libicesneolegacy.so built from 63c81b1c3d13bb96371611d7e2573d6e4adcb6e2

When using ics provided examples the CAN FD payloads are received as empty. Regular CAN frames are transmitted and received as normal.

[drebbe-intrepid]

@dwood-appareo would it be possible to use latest builds of both python_ics and libicsneolegacy?

[dwood-appareo]

@dwood-appareo would it be possible to use latest builds of both python_ics and libicsneolegacy?

Not sure if it is by design by pip is only finding 910, I manually installed 912.4 after building from source.

per build_libicsneo.py the hash is not the last commit, so I have updated that and rebuilt.

Here is how I am sending messages to test:

def transmit_can(device):
    msg = ics.SpyMessage()
    msg.ArbIDOrHeader = 0x18FFFFFD # CAN Arbitration ID
    msg.Data = (1,2,3,4,5,6,7,8) # Data Bytes go here
    msg.NetworkID = ics.NETID_HSCAN # First channel of CAN on the device
    msg.NumberBytesHeader = 8
    msg.StatusBitField = ics.SPY_STATUS_XTD_FRAME
    # msg parameter here can also be a tuple of messages
    ics.transmit_messages(device, msg)

def transmit_canFD(device):
    msg = ics.SpyMessage()
    msg.ArbIDOrHeader = 0x18FFFFFF # CAN Arbitration ID
    msg.NetworkID = ics.NETID_HSCAN
    msg.Protocol = ics.SPY_PROTOCOL_CANFD
    msg.NumberBytesHeader = 8
    msg.StatusBitField = ics.SPY_STATUS_CANFD and ics.SPY_STATUS_XTD_FRAME
    msg.StatusBitField3 = ics.SPY_STATUS3_CANFD_BRS
    msg.ExtraDataPtr = tuple([x for x in range(64)])

    ics.transmit_messages(device, msg)


if __name__ == "__main__":
    connected_count = len(ics.find_devices())
    print("Found {} connected device(s)...".format(connected_count))
    for i in range(connected_count):
        device = open_device(i)
    print("Finished.")
    try:
        while True:
           receive_can(device)
           time.sleep(1)
           transmit_can(device)
           transmit_canFD(device)
    except KeyboardInterrupt:
        print("breaking")

[drebbe-intrepid]

@dwood-appareo Can you provide the source for receive_can also? I'm not sure what is going on with pip and installing an older version. Let me get my hands on a Raspberry PI and see if I can reproduce this. Having binaries with pip for arm is on my todo list. This might take me a couple days to get to but I can try to give more feedback for you while I work on this.

[dwood-appareo]

@dwood-appareo Can you provide the source for receive_can also? I'm not sure what is going on with pip and installing an older version. Let me get my hands on a Raspberry PI and see if I can reproduce this. Having binaries with pip for arm is on my todo list. This might take me a couple days to get to but I can try to give more feedback for you while I work on this.

def receive_can(device):
    msgs, error_count = ics.get_messages(device)
    print("Received {} messages with {} errors.".format(len(msgs), error_count))
    for i, m in enumerate(msgs):
       print('Message #{}\t'.format(i+1), end='')
       print('\tArbID: {}\tDLC: {}'.format(hex(m.ArbIDOrHeader),m.NumberBytesData))
       print('Channel:', m.NetworkID)

I did not have any issues building from source so no problems there, maybe just more of a note to you that the build_libicsneo clones an old hash.

After updating python_ics and libicsneo, I also explicitly set the override library:

ics.override_library_name("/home/pi/python_ics/libicsneo/build/libicsneolegacy.so")

And this provided the same results of an empty CAN FD payload.

[drebbe-intrepid]

When you say empty payload I assume m.NumberBytesData is zero?

Are any of the messages you are receiving actually receive messages?

https://github.com/intrepidcs/python_ics/blob/master/examples/transmit_canfd_example.py#L86

[dwood-appareo]

When you say empty payload I assume m.NumberBytesData is zero?

Are any of the messages you are receiving actually receive messages?

https://github.com/intrepidcs/python_ics/blob/master/examples/transmit_canfd_example.py#L86

Yes, the receive function I am using is just dumping the DLC len for debugging.

Hardware wise I have the valueCAN connected to another device, that I have candump running on, so with the two transmit functions I sent previously this is my output:

18FFFFFD   [8]  01 02 03 04 05 06 07 08
18FFFFFF   [0] 
18FFFFFD   [8]  01 02 03 04 05 06 07 08
18FFFFFF   [0] 
18FFFFFD   [8]  01 02 03 04 05 06 07 08
18FFFFFF   [0] 

In my full setup I am actually using python-can, but when I discovered the payloads being empty I thought the best course would be to go to the python-ics level.

I do know that my receiving hardware is functioning because my python-can script works on windows.

[drebbe-intrepid]

@dwood-appareo thanks for the update, I'm assuming on windows you are using icsneo40 and not libicsneo correct?

I'm dealing with power outage and internet issues right now so I'm delayed on getting to this at the moment. Thank you for all the information.

[dwood-appareo]

@dwood-appareo thanks for the update, I'm assuming on windows you are using icsneo40 and not libicsneo correct?

I'm dealing with power outage and internet issues right now so I'm delayed on getting to this at the moment. Thank you for all the information.

I believe so? I got the drivers from installing Vehicle Spy.

[drebbe-intrepid]

ics.get_library_path() should tell you exactly what you are using on windows.

[dwood-appareo]

ics.get_library_path() should tell you exactly what you are using on windows.

icsneo40.dll on windows.

[drebbe-intrepid]

ics.get_library_path() should tell you exactly what you are using on windows.

icsneo40.dll on windows.

thanks, we will look into this ASAP.

[dwood-appareo]

ics.get_library_path() should tell you exactly what you are using on windows.

icsneo40.dll on windows.

thanks, we will look into this ASAP.

Thank you, please reach out if you need more information.

[drebbe-intrepid]

@dwood-appareo we are able to reproduce this internally. We are working on fixing it. As for the version being old, it looks like an older version of pip can only install up to 910.10. pip must have broke compatibility upstream somehow.

[dwood-appareo]

@dwood-appareo we are able to reproduce this internally. We are working on fixing it. As for the version being old, it looks like an older version of pip can only install up to 910.10. pip must have broke compatibility upstream somehow.

Great that you were able to reproduce it, looking forward to an update.