CAN frame API with two buses

[bef]

Hi,

I'm using a PXI 8461 to control 2 CAN-bus lines.

When I start the bus monitor in MAX, both work correctly (frames are coming in).

But I wasted a day now to try to make both lines work in my app.

I'm calling ncConfigCANNet.vi and ncOpen first with CAN0, then with CAN1.  ncOpen with CAN0 gives me an objHandle, but when I cann ncOpen with CAN1 after that, I get objHandle=0 but no error!

(I not using error inputs)

So in my app CAN0 is running, CAN1 will eventually return an error when I try to read from it using the objHandle (with is 0).

I even tried to use the NI-example "Multiple CAN Cards Frame API Single DAQmx Card Input.vi" with the same effect.

Is there a known issue about that?

I'm using

NI-CAN  2.7.2f2

LV 8.5.1

PXI8461 with CAN0 and CAN1 working with the MAX busmonitor

100g Ritter Sport Chocolate per hour

[Taki1999]

Can you post what you've got so far? One other thing is to make sure you close MAX before running your VI. If MAX is still holding one of the CAN interfaces then you won't be able to open it in LabVIEW.

[bef]

If you look at this vi from the NI-examples:

Multiple CAN Cards Frame API Single DAQmx Card Input.vi

this is what I'm doing. As I said, this example is behaving the same way as my program. CAN0 responds, CAN1 doesn't.

MAX is closed. And even if there was some other program allocating CAN1 there should be an error. But ncOpen runs without error and still returns null. Just like calling it with an error on the "Error In" terminal... but I have no error there.

I even tried the low-level / depreciated ncReset.vi. No luck.

One more thing I don't understand is why ncOpen.vi is reentrant and  all the other VIs from the nican.llb are not. In the end they are all calling nican.dll.

Any ideas?

[bef · Accepted solution]

Sorry, my fault.

I was able to solve the problem. My read- and write-queue length was too big. I was using 100 for each queue. That works for one CAN interface, but not for 2. And, yes, there was an error message... I lost that error somewhere in the error handling.

A nice thing I used for the first time here is the network-based debugging-feature for executables. Really cool and helpful.

Case closed!