VeriStand Fails to Re-Deploy after Initial Deploy and Undeploy, somehow connected to CAN FD

[blackburnite]

I have a system definition file which contains several CAN ports, one of which is CAN FD.  It also contains a custom device which takes an array of XNET interfaces and uses the XNET Connect Terminals VI to connect the LogTrigger event to a PXI backplane trigger so that all the XNET interfaces can be synchronized to send the LogTrigger frame at the same time. 

When the CAN FD port is not one of the ports passed to this custom device, everything works fine.  But when it is passed in, VeriStand will fail to deploy on subsequent deployments.  The first one upon system boot will deploy and undeploy fine.  But to redeploy, the PXI must first be rebooted.

The error in question is -10743846 NI-XNET: File transfer with the NI RT target failed and occurs when VeriStand attempts to deploy the XNET DBs.  This error also occurs if attempting to deploy manually via the XNET DB Manager after the initial deploy/undeploy.  The system is not password protected.

[blackburnite · Accepted solution]

After some exhaustive debug I was able to narrow this down.  The custom device code I was working with I inherited, and what it was doing was taking an array of database terminals, configured via the custom device main config pane in veristand, and extracting the cluster information from each because it had to open a set of new sessions after VeriStand had already opened sessions on the same interfaces.  Were you to try to use a blank in memory cluster, you'd probably get an error saying that a session had already been opened on the interface with different cluster info, hence why this step was necessary.

However, these database terminal references were never explicitly closed, which apparently is not a problem for regular CAN or LIN.  But with CAN FD, as far as I can tell, even just having a database references that points to a CAN FD database will cause that database to get "reserved" or "locked", even if you don't invoke any additional methods on it or call any other XNET function with it.  So if that databse reference is not then explicitly closed using the XNET Close Database poly VI, then attempting to redeploy will result in an error because XNET hasn't "released" that database.

I'm not sure why it only applies to CAN FD but anyways, that's the fix.