TestStand API External Component Modified Since Last VI Save

[wilbur]

I'm using TestStand 3.5 with LabVIEW, and deploying my code across multiple stations.  The code is managed by Perforce (source code control).  I'm keeping the stations identical by installing NI software from the same CDs (which I'll refer to as an "Original Station"), but it seems that over time the TestStand API will somehow be externally modified ("Modified Station"), which causes LabVIEW to recompile the VI.  The Explain Changes dialog box states "VI recompiled.  External component modified since last VI Save."  If I save the recompiled changes on a Modified Station and submit the changes, an Original Station opening the VI will then recompile VI, stating that an external component has been modified since the last VI save.  If I resave the VI on an Original Station, then the next time I open it on a Modified Station the recompile will occur.

This is problematic, because there will be a performance hit if LabVIEW has to recompile when opening VIs.  In addition, it makes debugging difficult, because LabVIEW will prompt to save changes on all the VIs if they were saved on a different station state.  Not to mention the unnecessary copies made in the source code control to maintain the history of the recompiling.

My current solution is to reinstall TestStand on all the Modified Stations.  I set any TestStand strict typedefs that I use to non-strict typdefs, mass compile the TestStand addon folder in vi.lib, and then the station becomes an Original Station again.  Overtime, it will modify itself and turn into a Modified Station.  Since these stations are at multiple sites, it is very inconvenient to manage.

My questions are the following:

1. What is causing this external modification?  Is there anyway to prevent it, so that the installation and code will not get modified so that all will remain Original Stations?

2. If it is not preventable, how can I force all stations to become a Modified Station, so at least they are all the same?

I've attached LabVIEW 8.5 VIs that demonstrate the VI differences.  I've observed this behavior in LabVIEW 7.1 and 8.2 previously.  If anyone also experience this behavior or has a work around, please post to this thread.  If NI has insight on what is causing this behavior and how to prevent it, it will help me out greatly.

Thanks!

[Rick_Francis]

 Wilbur,

Do you have more than one version of TestStand or LabVIEW on the stations?   Switching the active version of TestStand changes the registered version of the TestStand API which I believe is the external change that forces a recompile.  If version switching is the cause of the problem you could prevent these changes by not sharing any TestStand VIs between different versions of TestStand.  If each version of TestStand has its own VIs then a VI is compiled against one and only one engine version.

-Rick Francis

 

[wilbur]

Hi Rick,

Thanks for your response and information -- I only have TestStand 3.5 installed on the station, and only have LabVIEW 8.5.  Previously, on stations that had TestStand 3.5 and LabVIEW 7.1 (no other versions of TestStand or LabVIEW), the behavior was also observed.  After installing TestStand, it can take anywhere for a couple weeks to a few months before the behavior exhibits itself.  Some stations I have not seen this problem at all.  When I encounter this problem, uninstalling and reinstalling TestStand restores the system to the original state.  I have been unable to figure out what triggers the external modification, or how to force it to occur to make all the stations consistent.

Thanks,

Wilbur

[Rick_Francis]

Wilbur,

If you only have one version of LV and TestStand that rules out my first theory... I think the best means of solving this problem is to use a tool that compres files checksums - (i.e. see http://en.wikipedia.org/wiki/File_comparison).

The idea is to record the checksums for all the files on your system before the modification then run it after the modification and see exactly which files have changed.  Once we know exactly which files are affected it may give some insight as to why.

-Rick Francis

[MimiKLM]

Hi,

Even after two years later I have the same problem as Wilbur.

I'm using TS3.1 and LV7.1 with Operator Interface written in LV 8.2.

On that PC there TS3.5 and LV8.2 as well. However, it doesn't matter.

Source code is controlled by SVN.

When I wanted to add two VIs (scan barcode and write it to registry) to Test UUT Event I discovered that  Fill OI - Display Error.vi has been somehow modified (I don't know what is the link between those). The Explain Changes window tells me that 'External component modified since last VI Save' with description: 'An external component refereenced from this VI changed causing the VI to adapt to the new interface.

Those new two VIs I added are not interfering directly with any TS Operator interface elementes. So my questions are:

1. Which is the external component referenced  from the Fill OI - Display Error.vi? How can I get know what is that? Why I can't control that compontent overtly?

2. What caused the external component to change? Addition of two VIs, which the don't have direct relation to the main application and TS engine?

If I save that unknown change I'll have problems described here.