nxGetProperty sometimes takes long time

[JensT]

Hi all,

I'm using a 9862 (XNET CAN interface) in a 9068 (cRIO controller).

In my software (c/c++ in eclipse) I have one session for every CAN ID (at the moment 4 out, 9 in).

For incoming CAN messages I'm using FrameInQueued mode with queue size 1.

Then I'm trying to check if there is "something new" within the realtime loop using nxGetProperty(session, nxPropSession_NumPend, .....)

Most times this works fine, but sometimes (distance about 10s), this function needs about 7-8ms (one time per loop) which is much too much, because my loop has only 10ms and there is a lot more to do within one loop.

My application sends outgoing CAN messages using FrameOutSinglePoint in the same loop.

In my application there are no threads using xnet functions.

Any ideas for the reason?

How can I get rid of this behaviour?

Thanks in advance for your anwers,

Jens

[reschri · Accepted solution]

Hi,

have a look at that:

Getting Started with the NI-XNET API for LabVIEW - National Instruments
http://www.ni.com/white-paper/12375/en/#toc4

...

Within NI-XNET, the session modes for single-point I/O are designed for use within high-priority loops. This applies to all four single-point modes: input, output, signal, or frame. XNET Read.vi and XNET Write.vi provide fast and consistent execution time, and they avoid access to shared resources such as the memory manager.

The session modes other than single-point all use queues to store data. Although you can use the queued session modes within a high priority loop, those modes use a variable amount of data for each read/write. This requires a variable amount of time to process the data, which can introduce jitter to the loop. When using the queued modes, measure the performance of your code within the loop to ensure that it meets your requirements even when bus traffic is

...

So you only get in single point I/O a deterministic, reliable loop timing,

Regards

René

[JensT]

Hi,

many thanks for the information.

I will use single point polling instead of testing the queue.

Regards,

Jens