NI VeriStand

Showing results for 
Search instead for 
Did you mean: 

Error -307720 when attempting to deploy a second time

I'm trying to learn VeriStand and am setting up my very first system.  I have the file, etc.  I deploy the first time, it deploys and runs correctly.  If I undeploy (f7) and try to deploy again, it returns error -307720.  I've searched through error codes, google, etc and haven't come up with much.


My guess is that I'm not undeploying correctly.  Restarting VeriStand doesn't work, but restarting the computer (PXIe running Windows) does.  Any suggestions?


Error dump is below:


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
The VeriStand Gateway encountered an error while deploying the System Definition file.

Error -307720 occurred at Project Window.lvlib:Project >> Project Window.lvlib:Command >> NI_VS Workspace ExecutionAPI.lvlib:NI VeriStand - Connect to

Possible reason(s):

NI VeriStand: Failed to route PXI_Trig0 from bus segment of chassis master device to other bus segments.
NI VeriStand: NI VeriStand Engine.lvlib:VeriStand >> NI VeriStand Engine.lvlib:VeriStand Engine State >> NIVeriStand Trigger Routing.lvlib:Setup Chassis
NI VeriStand: Error -1073807294 occurred at VISA Assert Trigger in NIVeriStand Trigger Routing.lvlib:Unreserve TTL0 in all bus>NIVeriStand Trigger Routing.lvlib:Setup Chassis>NI VeriStand Engine.lvlib:VeriStand Engine State>NI VeriStand Engine.lvlib:VeriStand

Possible reason(s):

VISA: (Hex 0xBFFF0042) The specified trigger line is currently in use.
Chassis #: 1

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
• Shutting down VeriStand PC Engines...
• Stopping TCP loops.
Waiting for TCP loops to shut down...
• TCP loops shut down successfully.
• Unloading System Definition file...
• Connection with target localeWindowsPXI has been lost.
• Connection with target RT_Linux_cRio9039 has been lost.

0 Kudos
Message 1 of 10

I'm having this same problem. It only happens with the system definition I created, not with the Engine Demo project. Did you find a solution?


Update: Took out my two DAQ AI channels and now it's working so I guess it's DAQ related

0 Kudos
Message 2 of 10

Hi barkermp,


What hardware are you currently using? When it works with the Engine Demo, is that deployed to the same hardware as the system definition you created?



0 Kudos
Message 3 of 10

I'm on a PXIe-8840 with Windows 7 so it's deploying to the same hardware with both projects.


I did figure out that the problem goes away (so I can deploy multiple times) when I have Hardware-Timed Single Point Sample Mode with "Disable AI support" and "Disable AO support" checked but I'm curious why that is.

0 Kudos
Message 4 of 10



Glad you figured it out.


We would need to know more about the hardware you are using and the tasks that VeriStand is performing in order to try to figure something out. If you would like us to dig a little deeper and try to find the root cause, please let us know more details about the system and what is VeriStand doing. The system definition file would be helpful.


At least, I am glad you were able to get the system running.

Camilo V.
National Instruments
0 Kudos
Message 5 of 10

I would like to know what's going on. Right now things seem to be running fine but at least if I know why I can try and avoid it in the future or have a fix for the issue.


I've attached my System Definition and the deploy log with the error. I had to zip it because the forum said it was an invalid extension for an attachment.

I only have the mDAQ card in the system definition but here's the build of the PXI:

  • Chassis: PXIe-1065
  • Controller: PXIe-8840
  • Slot 2: PXI-2501
  • Slot 3: PXI-2567
  • Slot 4: PXI-6221 (this is the card in the system configuration with the on Analog Input mapped)
  • Slot 5: PXI-8513/2 
  • Slot 6: PXI-2567
  • Slot 7: PXI-2567
  • Slot 8: PXIe-4139
  • Slot 11: PXI-8513/2

Thanks for your help!

Download All
0 Kudos
Message 6 of 10



I don't have a PXI-6221 but I should have something fairly equivalent. I'll try to put up a system in the next day or two to try to reproduce the behavior and I'll let you know if I can.



Camilo V.
National Instruments
0 Kudos
Message 7 of 10

Hey barkermp,

When you use Hardware-Timed Single Point, the Chassis master synchronization device distributes its sample clock across the PXI backplane. By default, it uses PXI_Trig0 to do this. It looks like upon deployment the first time, your Chassis master synchronization device is reserving PXI_Trig0 and never unreserves it even when the Sys Def is undeployed.


I looked through the VeriStand Error Codes, and it looks like for error -307720, they describe a way to resolve the error:


To address this issue, open MAX and select the chassis. On theTriggers pane for the chassis, clear any reservation for PXI_Trig0 on the appropriate bus, set routing for PXI_Trig0 to Dynamic, and then try again.


Have you tried that?

Nadine H.
Certified LabVIEW Developer | Certified TestStand Developer
Message 8 of 10

I missed that when I was searching before but I checked and my MAX settings already had no reservations checked (both before and after VeriStand deployment) and the routing set to dynamic. 

0 Kudos
Message 9 of 10

Hi barkermp,


Nadine is correct that by using Hardware-Timed Single Point, VeriStand will distribute the sample clock across the PXI backplane using PXI_Trig0. This is automatically reserved for you upon deployment but there is a bug where it is not unreserved for you upon undeployment. This means that when you try to deploy your project a second time, the resource is already reserved from the first deployment and introduces this error. This is currently tracked by CAR 584486.


One way to resolve this error is by restarting your PXI chassis. This will reinitialize everything so that PXI_Trig0 is unreserved. This is likely not an ideal workaround since it takes a decent amount of time, so you can also unreserve PXI_Trig0 programmatically. I’ve attached a simple VI that demonstrates a method to programmatically do so. One option is to manually run this VI every time between deployments or incorporate it into a simple VeriStand service that runs after undeployment. You could start with our Workspace Tool Example located at <Program Files>\National Instruments\LabVIEW XX\examples\NI Veristand\Workspace and then use that template to wait for undeployment and unreserve the trig lines for your next deployment. Adding that as a service would automatically run this VI upon every deployment. You can find more information about adding services here:


If you have any further questions about implementing a workaround for this CAR, I would suggest contacting National Instruments technical support. We would be more than happy to work with you to create a solution.




Message 10 of 10