Error 8 Deploying System Definition Containing Multiple Instances of LabVIEW Models

[Pie566942.0]

A VeriStand 2016 System Definition contains (1 + N) instances each of simple LabVIEW models (not CD&Sim).  VeriStand makes (N) copies of each .lvmodel during deployment, so there are (1 + N) instances of each .lvmodel in the same folder, each with unique names, each with identical binary contents.  VeriStand deletes the copies when it in-deploys the system definition.

VeriStand sometimes "chokes" when making the copies, complaining that I don't have permission to write to this area of the C:\ disk.  The resulting Error 8 prevents the System Definition from deploying.  I have to delete the temporary files and try again.

This doesn't happen every time I deploy the system definition, and it seems to be related to how "busy" LabVIEW is.  There's definitely a connection to the LabVIEW development environment, because I can't delete the (N) copies until I close LabVIEW, even if I've completely close VeriStand.

My plan is to make (1 + N) unique copies of the model, so VeriStand doesn't need to make its own.  Is this an acceptable work-around?  What's going on here?  Why can't VeriStand always make the copies, or why can't it keep them around to reuse later?

Thanks,

Steve K

[NickelsAndDimes]

Hi Steve,

Just to clarify something, when you say that the copies can't be deleted even after you close VeriStand, is this after you undeployed the project (not just stopped execution)? Even when a VeriStand project is stopped, the files will remain deployed so this might be the behavior you're seeing.

I'd say what you're seeing here is VeriStand trying to avoid data from one mode instance "contaminating" another. Because some models depend not only on their current in/outports, but the history of those in/outports, feeding different data sets into the same model would result in incorrect data. VeriStand's workaround is to make a copy of the model with a different filename so each dataset in VeriStand gets its own unique model.

I was able to reproduce that part of the behavior you're seeing. I made a simple LabVIEW model (in1 + in2 = out1) and added it to a VeriStand project 3 times. When I deployed the project, 2 copies of the model appeared in the folder. However, I wasn't able to reproduce an Error 8 in deployment. I've attached images of this in case anyone else on this forum has any additional insight. 

System Definition FileBefore Deploying (this is the model I made in LabVIEW)After deploying

Where are you deploying this model? Localhost? A remote target? To a Windows-protected folder (Program Files, AppData, etc)?

[Pie566942.0]

Hi Nick,

The primary issue is sometimes I can't deploy the system definition because of Error 8.  I assume Error 8 is happening when VeriStand, or some shared LabVIEW component, is making copies of the .lvmodel.  Your explanation of why it's copying the model makes sense, but I don't know why it sometimes can't make the copy.  This is the primary issue because I can't run my system definition when it happens.

The secondary issue is that I can't delete the files after the system definition fails to deploy without shutting down VeriStand and LabVIEW.

When the primary issue happens, I can no longer deploy the system definition, even after a whole system restart.  Before I knew what was going on, i.e. before I found the "stale" copies in the models folder, I only knew it had something to do with the models.  I knew that because:

ERROR(8) SYST_INFO: - VeriStand_Interface.lvclass:Target.vi.ACBRProxyCaller.E5300108 >> VeriStand_Interface.lvclass:Target.vi:970011 >> VeriStand_2016.lvclass:Cmd_Do_Connect_To_System.vi:1070001 >> NI_VS Workspace ExecutionAPI.lvlib:NI VeriStand - Connect to System.vi  <append>=========================  NI VeriStand:  Copy in Model Execution.lvlib:Create Model Instances.vi->Model Execution.lvlib:Initialize Models.vi->Model Execution.lvlib:Initialize Model Loop Data.vi->NI VeriStand Engine.lvlib:VeriStand Engine State Machine.vi->NI VeriStand Engine.lvlib:VeriStand Engine.vi<APPEND> C:\Projects\<name>\trunk\LV2016\<name>\ni_veristand\_dev\Verification\Models\NIVS_Add_0.lvmodel

My resolution, back then, was to remove and re-add the models to the System Definition.  This was a major inconvenience, but for some reason it worked.  I don't know what was happening with the copies when I was doing that.

Then I learned more, so I was able to close LabVIEW and VeriStand, delete the copies, and deploy successfully.  Now I know more, and I've saved each model instance as it's own copy, and generated unique .lvmodels for each instance, and this hasn't happened again.

I have full control of where the original builds are, highlighted above.  I'm deploying to localhost, a Win7 VM, and the PCL runs at 20 Hz.  I'm automating via the Gateway.dll.

Unless there's something wrong with my work-around (create unique .lvmodels for each instance), and unless you can reproduce this on your end, I'm not sure what else we can do.  I'm running VMWorkstation Pro 12.5.9.  My host OS is Win10 Enterprise x64 and the VM is Win7 Professional SP1 x64.  Are there any CARs related to VeriStand on VMs?  Anything about automating VeriStand against the Gateway.dll on VMs?

Thanks Nick,

Steve K

[NickelsAndDimes]

Hey Steve,

First things first, there's nothing "wrong" with the workaround you're using. Creating copies of the model and calling each one a single time in VeriStand won't cause any problems.

As for the question about using a VM, NI doesn't officially support the use of most products in a VM. Typically hardware won't work and software will, but that's not always the case. VMs just add too many variables for us to reliably test our products (how many different VM clients are there, and how many combinations of host/virtual OSes could be made). With that said, the permissions error you're seeing may be related to the fact that you're writing to disk on a virtual OS rather than a host OS.

Because VMs are unsupported, there aren't any CARs with them. If copying the model is a viable workaround for you, then that's probably going to be your best path forward.