IXXAT interface send_periodic() unexpected when period above 0.5s

[johanbrus]

When using the command "bus.send_periodic(msg, 0.50)" with the IXXAT interface, the message is send with the defined period up to a period of 0.5 seconds but anything above that (e.g. 0.6) results in a value of about 0.6 - (n*0.5) sec.
So period of 0.6 = 0.1; 1 = 0.5; 1.1 = 0.1 sec. etc.

I don't see this behavior with other interfaces (e.g. vector, kvaser)

[hardbyte]

Thanks for the bug report @johanbrus can you please report version of IXXAT canlib and python-can you're using?

Are you seeing this when sending multiple periodic messages (especially with different periods)? I don't have any IXXAT hardware so can't help chase it down much.

cc @christiansandberg @cowo78

[christiansandberg]

The ixxat backend has a hardware based periodic send implementation. The period is converted to an internal tick count and at some point this will probably wrap around. So it is possible this is what is happening in your case.

The IXXAT API is unfortunately really crappy and lacks basic features so I think there should be an easy way to choose the thread based software implementation instead. It is possible to do it today but you need to call the default send_periodic method instead of the IXXAT specific which is not very user friendly.

[johanbrus]

@hardbyte sorry where would I find the version of the IXXAT canlib, I guess the one that came with python-can=3.3.3 ?
Yes. I am sending messages using the code as supplied with different periods and checking with an independent CAN viewer.

@christiansandberg I noticed in the code yes that there was a separate periodic message sending implementation. Seems class CyclicSendTask in canlib.py might be a clue.
What do you mean with choose the thread based software implementation instead? Sending multiple single messages using Python's threading module?
Also, you say to 'call the default send_periodic method instead of the IXAAT specific' - I have no idea how that would work (yet) so if you could point me to the place in the docs or tell me that would be helpful.

Anyway, it's not high priority for me as I have multiple devices to choose from but thanks for the help.

[christiansandberg]

Most interfaces do not have hardware support for sending cyclic messages. That's why we have a "fallback" implementation of a thread sending messages periodically. The timing of the messages is not very accurate in that case however, but at least it works as expected.

I'll see if I can give you a hint of how to use this implementation instead later. It is not documented anywhere.

[christiansandberg]

You could try something like this instead, I think it should work. It uses the default send_periodic implementation instead of the one defined by the IXXAT class.

from can.bus import BusABC

bus = ...
msg = ...

BusABC.send_periodic(bus, msg, 0.5)

[johanbrus]

This did work as in messages were being sent, however the behavior is similar to the first test which is strange to me.
This is my script, just executing either the line BusABC... or the line bus... with the same result:

import can
import time

from can.bus import BusABC

def send_periodic():
    
    bus = can.interface.Bus(bustype='ixxat', channel=0, bitrate=250000)
    
    msg = can.Message(arbitration_id=0xc0ffee,
                      data=[0, 25, 0, 1, 3, 1, 4, 1],
                      is_extended_id=True)

    #bus.send_periodic(msg, 0.5)
    BusABC.send_periodic(bus, msg, 0.5)
    time.sleep(10)
    bus.stop_all_periodic_tasks()

if __name__ == '__main__':
    send_periodic()

Maybe I am missing something?

[Audry21]

Hi there !
I am very interested in a solution to this issue. How can I help ?
I can makr some tests as i have an ixxat device at my work. (but ill be in holidays for the next 2 weeks).
I tried also the code provided by johanbrus, and i can confirm it does not work and behave as explained at the top of this topic.

[christiansandberg]

Maybe we should just make the software thread based implementation the default. The IXXAT API does not allow modifying the data and you might wonder how often you send a message that never need to change... 🤔

[Audry21]

I dont know, as I am not very familiar with python-can yet (found it and decided to give it a try for my projects ^^)
For now, I handled the issue using a thread that makes bus.send(msg) and sleep for the period etc. I thinks it's some kind of "personal" thread implementation, as I didnt managed to force the use of the one provided by the lib.

It can happen that you send periodic emssages that does not change ! I have two case in my projects:

• one equipement must send a heartbeat meassage, which is like a watchdog signal: always the same, periodic.
• one equipement must dump some really big data from another equipement, but as the message are 8bytes long, and, a request is required for getting each 8bytes chunk, we need to "spam" the dump requests on the equipement: same message, periodic

I dont know if its something that happens often, but it can ^^