CAN Set Hardware Master Timebase Rate returns error with new NI-XNET hardware

[Pianne]

Hi all,

I have a project that communicates over a CAN bus. It has always worked fine with a PCI-CAN/2 card, but when I tried using it in combination with a newly purchased NI PCI-8512 (NI-XNET) card, it return the following error:

"Error -1074388560 occurred at CAN Set Hardware Master Timebase Rate.vi

Ni-CAN: (Hex0xBFF621B0) the feature specified has a design under NI_CAN which cannot be made compatible with NI-XNET CAN hardware."

Yes, I have installed the NI-XNET Compatibility Library for NI-CAN.

The error occurs when initializing RTSI connections for synchronization, Vi is attached.

I guess this code is based on an example found in LabView.

When I remove the CAN: Set property (Hardware Master Timebase Rate) block, there is no error and the rest of the application seems to run fine.

Can anyone explain what the purpose is/was of setting timebase to 10MHz internal clock before connecting a RTSI line to it ?

Are there any side effects caused by removing this step?

Do I still need to include it if I run the application in combination with the old PCI-CAN/2 card?

Thanks in advance.

[ThiCop]

Hello Pianne,

Thanks for sharing this VI!

The error -1074388560 indeed typically indicates that you are trying to use an XNET device with the XNET Compatibility Library for NI-CAN, but the functionality you are looking for is not available.

Did you originally implement that project code?
If yes, can you tell me which example it is based on.

Maybe then I can easily find you an XNET counterpart.

I also only found the Init VI

To be able to tell you how big the effects will be I would also need to have an idea about the scope of the whole project.

Is it possible to share this scope with me?

Based on this code it seems like you're trying to synchronize a DAQ Device with an XNET device.

Which kind of device are you trying to synchronize your XNET card?

If it is the same device as before, then you should just take a look at the NI Example Finder and select "Synchronize PCI-CAN with DAQmx Analog Input (Using RTSI).vi".

Here they show the VI's you should be using instead of the older ones.

[Pianne]

Thank you for your response.

I did not write the original code. I suspect this particular VI has been re-used several times. I think it's based on an example, judging by the comments on the block diagram.

This particular VI is used in a project that controls part of a test bench through CAN communication (Motor controllers and an automotive TCU), the testbench also reads values back from the CAN bus and combines them with analog and digital inputs and counter inputs from a DAQ card (NI PCI-6221). These measurements are stored in TDMS data files as 2D arrays for further processing.

The goal is to continuously read input samples at a fixed sample rate and get an equal amount of samples for all DAQ- and CAN inputs on each read. Also, the samples should align in time.

In the project, the inputs are controlled by "input driver.vi". I've made a source distribution and attached it to this post.

As the same input driver is also used on other test benches (with older CAN hardware), I would like to avoid using NI-XNET specific code, so that the VI can be used unmodified across different test benches.

Kind regards,

Pieter-Jan

[Pianne]

While on the subject of RTSI and synchronization, I have an additional question:

In the VI atteched to a previous post, the "task-connect" routines are only performed on the first CAN task (case in while loop does nothing when "i" > 0).

I noticed that when I use different CAN ports for my CAN tasks, the synchronization is off by about 30 milliseconds. I suspect this is because the second port does not use the RTSI trigger.

Any suggestions to solve this ?

i tried removing the case structure and performing the "task-connect" functions on all tasks but got an error.

[ThiCop]

Hello Pieter-Jan,

Just for the sake of verifying that this fixes the issue:
Can you do a test with the XNET-functions to see if this fixes this issue?

Aren't your test-benches already using different hardware?
What you could always do is add a sort of Hardware Abstraction Layer for your synch VI's.

This would allow you to choose the appropriate VI's depending on which kind of hardware you're using.

[Pianne]

Thierry,

I can run the "Synchronize PCI-CAN with DAQmx Analog Input (using RTSI).vi" example you mentioned and it runs OK (this was to be expected).

The testbenches that use this input driver (which is part of a bigger framework) all use NI DAQmx cards and NI PCI-CAN cards, but since we will be building/modernizing a few other testbenches, we need additional CAN cards. As these NI PCI-CAN devices are nolonger availiable, we decided to go with NI-Xnet devices.

The goal is to have a testbench framework that can be used on any testbench, with either NI-CAN or NI-Xnet hardware (using the Compatibility Library).

What do you mean by "hardware abstraction layer" ? This would implicate making a completely new version of the whole 'input driver' section, using XNET functions and then selecting which one to run, depending on the hardware configuration (conditional disable structures)?

I had hoped to get it working in compatibility mode... In fact, as I said before, it IS running with the NI-CAN functions.

I'm just not sure why the "Set property" - Hardware Master Timebase Rate function has to connect ot the 10MHz clock on the XNET device, only to change it back to RTSI.

And I wonder what the implications of removing this function from the code are.

[ThiCop · Accepted solution]

Hello Pianne,

Based on our discussion in class it seem indeed like a part of your legacy code is written in a very specific way that is not fully compatible with the XNET-approach.

It could indeed be useful to have 2 seperate versions of this init VI (and other CAN-code) of your code and to let your top-level application decide which one to run, based on the used set-up.
A HAL like approach could still be used in this case.