Running NI-MAX GUI in background somehow improves my CAN BUS simulation timing

[upatel69]

Hi,  

I have a simulation where the UUT sends a CAN message (2-bytes) to my simulation. My simulation process it and returns a 7-byte response message. This has to be done within 10msec, otherwise the UUT reports timeout. When the NI-MAX GUI is running in the background the response time is less than 3msec. If I close the NI-MAX GUI the response time exceeds 10msec. Is there something I`m missing in configuring the CAN card that the NI-MAX GUI is performing?  

CAN Card: NI-PCI 8512 Driver: NI-CAN 17.0 and NI_XNET 17.5.1  

Thank you, Umesh

[cdiaz95]

Hi upatel:

    A couple of question to understand better this issue:

1)  By NI MAX GUI do you refer to NI MAX the software or to something else?

2) Can you upload an image of the code or is it based on some particular example?

[upatel69]

I`m still having the problem.

Yes it`s the NI-MAX software. When I launch it (running in the background) my simulation timing is good (I`m using this as my workaround for now).

Attached is my code

Umesh

[cdiaz95]

Hi Umesh;

    This is some interesting behavior and I think it could be related to the NI CAN driver. This driver stores the configuration information in a MAX internal database. When opening MAX this opens the GUI and starts the background services which also start the database. This could explain the time difference in execution. 

    With XNET this should not occur since the configuration is not stored on MAX. 

     One thing to try could be to open MAX, close it and then run the code to see if the difference still happens. I would think that it should run fast as the database is already initialized. 

Hope this helps 

[upatel69]

I tried that, when I close MAX the timing is not good, as soon as I reopen MAX the timing is good (this is while my code is running)….very bizarre.

Umesh

[Mike.B]

Hi Umesh,

We have seen this behavior before, where MAX running in the background improves the execution time of LabVIEW code that uses the NI-CAN driver to interface with NI-XNET hardware via the NI-XNET Compatibility Layer.

As already hinted at by cdiaz95, this is because MAX likely loads up the compatibility layer at startup, whereas your code does not already have it in memory. When NI-XNET first came out, the compatibility layer was intended to help developers slowly transition code bases over from NI-CAN, and was not intended to be a permanent solution for continual development. It is, of course, still okay to use, but its behavior is more complicated than using exclusively NI-CAN or NI-XNET.

Since you're using an NI-XNET device, I recommend fully migrating your code base over from NI-CAN to NI-XNET to see if you experience improved execution time without MAX running in the background. If you don't mind MAX running in the background, then simply keeping your code as-is makes the most sense for now.

[upatel69]

For this project I`ll use the work-around by running NI-MAX, but for the next project I`ll migrate from NI-CAN to NI-XNET completely.

Thank you Mike,