LV820 VarMgr Error 7 on close (no RT info)

[PoolMaster]

Looking for suggestions regarding trouble with LV820 Variable Manager (VM) while viewing PXI RT system hosting single deployed Network Shared Variables (NSV) library.

Standard LV 'Error 7 occurred at New File' (file not found) dialog appears when close VM. Might this be a file access/protection issue? Does VM use separate ports that the psp protocol does not? Is this an actual file error (appears so) or just error 7 from variable server passed out?

No trouble accessing the variables in LV host/RT dev code or executable but cannot view the deployed lvlib on RT system. Can view in VM same library 'copied' then deployed to localhost. Use of Select Variable ... context menu item on Shared Variable node works and shows lvlib contents properly.

source: WinXP/SP2 on PXI-8105 in PXI-1052 chassis, 'Symantec Endpoint Protection' AV/firewall in use.

target: PharLap on PXI-8105 in PXI-1052 chassis

RT software: LabVIEW Real-Time 8.2, Network Variable Engine 1.2.0, Variable Client Support 1.2.0

[PatJamSim]

Hello PoolMaster

The most common cause for Error 7 from a real time system is when you try to reference a file that is not stored locally.  Even using a path containing an IP or referencec to another machine will not work; instead, you must create a file locally and FTP it over to the host.  Check out the following link for a little more detail:

http://digital.ni.com/public.nsf/allkb/08746206C3AD98CC8625733200370AB5?OpenDocument

Is there anywhere in your program that you are accessing files that could cause this error to be thrown?  There are any number of ways for this error to occur if you are writing to file, but it sounds like when you close the VM window you receive the error.  Are you closing it manually or programmatically?  Is there any interaction with your program that is occurring at this time?  Is your program running, or are just variables deployed?  Is any file I/O taking place anywhere in your code?

I would certainly be strange for the error to be thrown from the Variable Manager window; I can't find any resources relating Error 7 to VM.  Can you describe the exact process that is occurring when the error is thrown, along with any other relevant details about your program?  

[PoolMaster]

Although Network Shared Variables (NSV) are used in the LV82 project, the error comes from within the Variable Manager itself.

The error was reproduced after a complete stand power cycling, starting VM from the Start::Programs::National Instruments::Variable Manager menu, then closing it immediately with no other actions.

Earlier yesterday, an error occurred during the AutoDeploy (for the lvlib involved) that occurs when testing in LV (some shared variable dll problem which I have seen during FieldPoint RT projects). Generally, immediately running again results in no reoccurrence. I can imagine some [highly unlikely] corruption of a DLL while in memory but to have this continue after a complete OS restart?

[PatJamSim]

Hello PoolMaster

I agree that the most likely cause of your errors is a corruption of some sort of supporting file.  The error that is being thrown appears to be quite unrelated to the VM itself.  You might consider posting a screen shot of the error message; it would be helpful if you included in that shot all of the programs, projects, etc. that are running.  To help determine what may be the culprit, let me ask you a few questions.

When was the first time you received this error?  Was your system working in the past, and if so, for how long?  Did you recently install or upgrade any NI software, or any other software?  Is there any way for you to upgrade your software to a newer version that may have better functionality in terms of fixed bugs?  

The reason I ask the last question is that the Variable Manager was phased out quite some time ago, and was replaced by the Distributed System Manager.  The DSM goes back to LabVIEW 8.6, but because it is a stand-alone piece of software, it should still be compatible with LabVIEW 8.2.  The DSM interacts with the variable engine and not LabVIEW directly.  If you were able to update more of your software, it is possible that this error will go away.  You may also be able to get rid of it by using the DSM instead of the VM.  The DSM is available for download here.

Also, it seems like this error isn't exactly a show-stopping type of bug.  Is there a way for you to work with or around the error?  Is it occurring every time you use the VM, or preventing you from carrying out your application in any way?

[PoolMaster]

After some exploring, I found TagMonitor.exe in 'C:\Program Files\National Instruments\Shared\TagMonitor' which appears to be an early rendition of DSM and shows my deployed RT libraries properly. As such, the urgency to get VarMan working is diminished but I would still like to see it working again, so ...

Answers:

- First observed this past Monday during software troubleshooting in LV.

- VarMan displayed SVs on RT previously without issue.

- No NI software changes. This is an existing test console with several years use.

In MAX 4.5, clicked 'Tools::Install legacy support ...' to view dialog that would appear but only got message dialog with: 'Support files are up-to-date for all recognized drivers on the syste, No updates are required.'

Other software: not sure as system is connected to inhouse network so some pushes do occur but system remains at XP/SP2. There was some kind of Outlook 2003 patch I saw from this past weekend.

- Software upgrade to newer version: unlikely since existing EXE software on stand still currerntly used and budgets are thin for upgrades and anyway, software updates may require hardware updates; not a good plan.

- Show stopper: none, as I previously mentioned software still works it just that VarMan is a useful debugging tool. My work-around is a simple polling/monitor app for the SVs of my particuar project but my concern is that this issue a symtom of some underlying communication error that may bite me later.

- Occurrence frequency: happens every time now.

Questions:

- NI software in Windows Add/Remove utility has Repair option but no line item for VarMan. Was this a base LabVIEW component or did it come with the RT module? Would 'Repairing' the LV 8.2 RT Module have any effect?

- Above 'Repair' options does not exist for Real-Time Sofware Wizard in MAX. Would Uninstall/Reinstall the 'Network Variable Engine' and/or 'Variable Client Support' items help?

- I asked before about specific TCP/UDP ports used by VarMan (psp protocol, etc.) that may be being blocked...no response.

- In VarMan, tried to manually add RT Target but nothing happened. Is there a way to verify of VarMan is connecting with RT system?

Additional:

- Am including screenshot of error and list of installed NI software on host & target.

- Since TagMonitor reliably communicates with RT, it appears this error is solely associated with VarMan.

Thanks for your help with this issue, Patrick.

[PatJamSim]

In response to your questions:

-Variable Manager is included with LabVIEW, not LabVIEW Real-Time.  Repairing either or both could help resolve the issue, as it is difficult to pinpoint where the corruption is taking place.

-Once again, uninstall/reinstall may or may not be helpful because we are not sure where the corruption is located.  The Network Variable Engine and Variable Client Support are typically used on an RT target, so it may not have much affect on the host.

-Specifics about TCP/UDP ports for shared variables can be found at the following links.  In the first link, there is a table near the bottom that describes ports for network shared variables; these may be the ones in question.

http://www.ni.com/white-paper/12402/en

http://digital.ni.com/public.nsf/allkb/CEF5A3568A5DA71D8625732800520EA1?OpenDocument

http://digital.ni.com/public.nsf/websearch/0D7B86F4B4D19A5E86256F9A006EECB1?OpenDocument

http://digital.ni.com/public.nsf/websearch/8AE45BBFA1D7025E862570F200642FD8?OpenDocument

-There is no set way to verify connection to a target through VarMan.  The easiest way to know you are connected is to monitor a variable that your target is manipulating and see if the values update in VarMan.

Thanks for the additional information.  Unfortunately I have been unable to find another instance of a similar error, so we are entering uncharted territory.  Also, because the Variable Manager was replaced with the Distributed System Manager in LabVIEW 8.6, it is possible that an existing bug is causing the behavior.  You might consider re-imaging your system and reinstalling the necessary software.  This appears to me to be the most sure way to fix the problem; I understand that its quite a hassle to do so and is by no means the first option to try.