How can I reset a NI-CAN network object without an object handle?

[MarkMoss]

Despite my best efforts to ensure my NI-CAN objects are close properly, I'll occasionally have an issue where my program fails to properly close a NI-CAN network object.  To allow my programs to recover from this situation automatically, I'd like to be able to reset a NI-CAN network object given only the CAN port name (i.e. CAN2).  This KB article (Document ID 4IIHT8SL) seems to suggest its possible, but doesn't give a complete implementation.

I've tried to follow the KB article's suggestion to clear the device by calling ncAction.vi and specifying the Reset action, but I haven't had any luck (see attached VI).  Despite resetting the object, I still get error 0xBFF62017 when I attempt to configure the CAN network object after it's been left open.

1. Does anybody know how to clear/reset a NI-CAN network object given its CAN port name?

2. Am I simply missing a step in my attached VI.

I'm using LabVIEW 8.6.1f1 with NI-CAN 2.6.3 and a PCI-CAN/XS2.

Thanks,

Mark Moss

Electrical Validation Engineer

GHSP

[Lars_L]

Hey Mark,

I've got your same hardware and I downloaded and ran your example. I'm currently seeing the same behavior that you're describing where the 0xBFF62017 error is returned even after doing ncAction>Reset. I'm currently looking into this with R&D so we can get a better explanation of what we're missing here.

In the meantime, though, there is a simple workaround. If you look in the nican.llb file located here: C:\Program Files\National Instruments\LabVIEW 2009\vi.lib\nican\nican.llb, you'll see near the bottom that there is a function called ncReset.vi. This function will reset your CAN card and attempt to find and close all open NI-CAN resources. However, we usually don't recommend using ncReset because this is a legacy function that had issues where the driver didn't always find all of the opened resources. This can be especially problematic if you are running a test for an extended period. While investigating the CARs that were filed on this function, R&D decided to use another implementation which is the ncAction>Reset method.

That being said, I've tested with both of these methods with your attached examples and it isn't clear why the ncAction>Reset isn't clearing the opened CAN sessions as expected. The ncReset function does work so I would use this for the time being and I'll update you as soon as I find out more from R&D.

Lars L

NI Applications Engineer

[MarkMoss]

Thanks, Lars.

The ncReset function does appear to reset the hardware, allowing subsequent calls to ncConfigCANNet.vi to succeed.  However, it appears that ncReset doesn't recover all of the resources in used by the CAN objects.  Specifically, while testing the ability of my program to recover from improperly closed CAN objects, calls to ncConfigCANObj.vi began to return error code -1074388947 (Exceeded resource limit for queues in shared memory).  After rebooting the computer, these errors went away.  Note that my application code does uses several CAN objects with large read or write queues, and I am very close to using all of the available shared memory.

For now, I'm going to leave out the reset function and rely on the fact that my program should always properly close its CAN objects.

Mark Moss

Electrical Validation Engineer

GHSP

[Lars_L]

Hey Mark,

I'm afraid you've run into the limitations of ncReset. This is the main reason why we obsoleted this function. It does not always succeed in closing all resources and thus after longer testing periods (or forced testing as you've done) you'll see the "Exceeded resource limit" error that you've described.

In general, it is always proper programming practive to make sure you call a close for each ncOpen in your application. I heard back from R&D and it looks like the first KB you referenced gives the best explanation of what the ncAction>Reset function does:

"The Reset action first issues the Stop action, clears all entries from the write queue, then resets the CAN or LIN hardware.  Resetting the CAN hardware sets the CAN error counters to zero, returning the CAN controller to error active state."

The main issue here is that the ncAction>Reset solution does not clear software resources. This is done by using ncClose and you must obviously have an object handle for this to work. From what I heard back from R&D, it sounds like there were issues with NI-CAN that were preventing us from improving the resource management without doing a major driver overhaul. This was instead fixed with the new XNET driver framework where the XNET driver automatically clears any open driver sessions after the VI goes idle.

For the time being, you will need to rely on the fact that your program is properly closing it's CAN objects. If you move to new hardware in the future, I would consider our NI-XNET boards as there are a variety of improvements that you could take advantage of.

Lars