From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

CAN and XNET successively

Solved!
Go to solution

Hello,

 

I'm trying to use successively NI-CAN and NI-XNET on the same CAN bus. I've programmed and tested the functionnalities with NI-CAN and NI-XNET, all is OK. But I can't run the two parts successively...

 

What I do:

- initialisation of the CAN bus (CAN0, 250kBaud) - with ncConfigCANNet.vi + ncOpen.vi

- execution of my CAN code

- CAN close (ncClose.vi)

- waiting time (500 ms)

- initialization of XNET sessions on same interface, for the next steps

-> error

 

I have only one CAN interface on my test bench (NI PCI-8512) and must use NI-CAN librairy for the first part of my programm (I must call a dll which use the NI-CAN librairy).

 

I've tried to add stop/restet after ncClose (with ncAction.vi), with the same result: error -1074384742, "XNET Create Session (Frame Input Queued).vi:5430001"

 

My configuration:

- OS W7 Pro

- LabVIEW 2014 SP1

- Max 14.5.0f0

- NI-CAN 14.0

- NI-XNET 14.1 (with compatibility librairy for NI-CAN)

 

==> How can I use XNET functionnalities after using NI-CAN functionnalities on the same interface??

 

Thanks per advance

Francis M
0 Kudos
Message 1 of 7
(7,756 Views)
Solution
Accepted by Cisco

Why would you choose to use the out dated and inferior API (NI-CAN) when you don't have to?  If you hardware doesn't support XNET, use NI-CAN, if you have an existing application that uses NI-CAN, don't re-write it.  But if you are making changes, or starting a new application, and you can use XNET, I highly recommend not using NI-CAN at all.  Anything it can do XNET can do better.

 

With that out of the way I swear I did accomplish this years ago.  Are you saying that separatly the two APIs work?  If you just run the XNET portion of you code it works?  And if you just run the NI-CAN portion of your code it works?  

 

Do you have the compatibility layer software installed?  Could you post a screenshot of MAX showing the two interfaces?

 

The error is states "The interface has already been opened with different cluster settings than the ones specified for this session." this makes me think that a different XNET session was opened and never closed.  Are you sure cleanup has happened properly from previous runs?

 

Can you post your code.

Message 2 of 7
(7,741 Views)

Hello Hoovahh,

 

It's a new application, my hardware is compatible with XNET --> I have used XNET instead of NI-CAN. All I've made with XNET works.

 

But I've to integrate a dll from a supplier. This dll was developed for a USB-CAN PEAK Hardware, end modified to be compatible with NI-CAN (but not with XNET). I've developed the code to execute to dll, it works.

 

I have to firsly execute the part with NI-CAN, and secondly the part with XNET. I close properly the NI-CAN interface, but when I'm trying to create my XNET session I've the error message.

 

As written before, I've installed the compatibility layer. I use "CAN0" when I work with NI-CAN and "CAN1" when I work with NI-XNET.

 

max.PNG

 

I'm sure that previous mXNET sessions were properly closed: I've totally closed LabVIEW and made a self-test of my PCI-8512 card before the execution.

 

My code is complex, I'm working to simplify it to isolate the problem and to post it.

Francis M
0 Kudos
Message 3 of 7
(7,730 Views)

I've made a test without dll calling, and it works. I manually read and write frames with NI-CAN, close the CAN session and open the NI-XNET session --> no error

 

I have to check with the supplier what is in the dll...

Francis M
0 Kudos
Message 4 of 7
(7,726 Views)

@Cisco wrote:

I've made a test without dll calling, and it works. I manually read and write frames with NI-CAN, close the CAN session and open the NI-XNET session --> no error

 

I have to check with the supplier what is in the dll...


Good to hear, like I said I swear I did this in the past but can't currently test it.  You just confirmed I'm not going crazy.  Sorry hear your DLL is doing something funky that probably isn't letting go of that hardware resource, probably not closing properly.

Message 5 of 7
(7,715 Views)

Yes, thank you again Hoovahh, and I confirm you're clearly not crazy!

Francis M
0 Kudos
Message 6 of 7
(7,708 Views)

@Cisco wrote:

I confirm you're clearly not crazy!


Lets not jump to conclusions.

0 Kudos
Message 7 of 7
(7,703 Views)