VeriStand
VeriStand is duplicating VIs from VI.lib and hence has a potential for conflicts/modifying VIs in LabVIEW <vi.lib>
Just wanted to share some thoughts on VeriStand's interaction with LabVIEW <vi.lib> VIs.
I have been using VeriStand for a couple of years. I noticed that whenever I build a Custom Device or a new Device Template, the Source Distribution used in the Build process, makes a copy of all LabVIEW VIs that are used, including the VIs installed in the LabVIEW <vi.lib> foIder. This includes very commonly used VIs such as Simple Error Handler.vi etc.
Not only is this duplication of VIs wasteful of memory and disk space, it also has a strong potential for cross-linking, and unintentionally over-writing original VIs in <vi.lib>. I get this screen below once in a while when I have both LabVIEW and VeriStand open.
As a LabVIEW programmer, I have a hard and steadfast rule of never modifying or copying files in <vi.lib> unless I change their names and put them in my project folder. After VeriStand got installed I am afraid the integrity of my <vi.lib> files has been compromised.
Am I missing something here? Am I making some kind of "VeriStand novice user" mistake? I understand that you can save files with same names as long as they are in separate project libraries (lvlib), but I am not sure that my <vi.lib> files are sufficiently protected due to this constant cross-linking.
Thanks for reading this post.
Hi LVUser94,
Your understanding is correct.
Custom Device source distributions created using the Custom Device Template tool are indeed configured to include <vi.lib> content - amongst others as shown in the picture below. We took this approach in order to guaranteed all content would be available to the custom device during execution. Consider for example Custom Device A (CDA) was created with the option to exclude <vi.lib> content. This CDA however is using toolset source installed to <vi.lib>, but not available in the LV Runtime Engine. The source distribution to CDA is then given to a deployed system which only has NI VeriStand installed, but not LabVIEW. Under this scenario, the user on the deployed system may be unable to use CDA in System Explorer (or Engine) because the toolset source is unavailable in the source distribution. This would therefore result in a run-time error from the custom device source.
This unfortunately does however have the potential of causing cross-file link issue as you've discovered. Our intent of these source distributions is that they be used strictly by the VeriStand process during execution and not for further development. Because the VeriStand process is strictly using the LabVIEW Runtime Engine, it doesn't have the ability to save source and thus cause cross-file link issues. Therefore, if you desire to perform further development on a custom device, then my advice is not to use to source distribution but instead work directly with the original source; after your edits you can then recreate the source distribution for use by the VeriStand process.
You hinted to perhaps adding a namespace (aka lvlib) to the packaged content in order to avoid the cross-file issue. However, this is not recommended because shared source will be duplicated in memory by the LabVIEW Runtime. For example a namespaced Simple Error Handler will exist in memory for the original file and for the namespace copy. Without a namespace, LabVIEW will simply continue to use the first instance of the Simple Error Handler regardless of multiple loads from following code.
Consider the following when developing in LabVIEW:
1. The VI source hierarchy is placed in memory when loaded. Therefore, even if you are not using the source distribution for development, simply having it opened may cause issues. This again reiterates my argument to not use the source distribution for development but merely as a final library to be consumed strictly by VeriStand.
2. Assure your LabVIEW search paths do not include paths to locations where source distributions are located. If this is indeed the case, then LabVIEW may use the source distribution as its source.
