tortoise says file changed, but diff says the file is the same

[crossrulz]

---

@DLMC wrote:

Yup, running Teststand, so, apparently all bets could be off.  🙂

be well,

---

I think the last question was if you are using the LabVIEW RunTime Engine with TestStand or the actual LabVIEW Environment with TestStand.  If the later, set the "separate from compiled" on all of the VIs to avoid SVN complaining about changes when it is likely just the compiled object code that is part of the VI.

What I prefer to do with deployed systems is to build up the code modules into Packed Project Libraries (PPLs) and have TestStand use those.  PPLs are fully compiled libraries that can be used in the RTE or the LabVIEW Environment.  Most importantly, I don't trust technicians being able to change code at the deployed machines.  PPLs require being built by your development environment.

[avogadro5]

---

@crossrulz wrote:

---

@DLMC wrote:

Yup, running Teststand, so, apparently all bets could be off.  🙂

be well,

---

I think the last question was if you are using the LabVIEW RunTime Engine with TestStand or the actual LabVIEW Environment with TestStand.  If the later, set the "separate from compiled" on all of the VIs to avoid SVN complaining about changes when it is likely just the compiled object code that is part of the VI.

What I prefer to do with deployed systems is to build up the code modules into Packed Project Libraries (PPLs) and have TestStand use those.  PPLs are fully compiled libraries that can be used in the RTE or the LabVIEW Environment.  Most importantly, I don't trust technicians being able to change code at the deployed machines.  PPLs require being built by your development environment.

---

It's been a while since I used it but TestStand does have a built-in system for dealing with this kind of problem: the deployment utility. It can build everything into a PPL, or do what amounts to a source distribution where it can include compiled code for all items and even remove block diagrams while still keeping the old names/file structures. So the development process becomes: code/debug with compiled code separated (which is far superior for source control purposes), and when ready for production build a deployment with compiled code included. Then the deployment can run with RTE but the original code doesn't contain the compiled objects that cause these headaches of knowing what really changed.

[NIExpert]

I believe @DMLC is suggesting to use compiled PPLs in the deployment, which I agree with.

My experience with using the Teststand Deployment tool to create the PPLs has been mixed.  I have had much better success with creating the PPL's separately and explicitly linking the sequence calls to functions inside the PPL during development.

Downside to this approach of course is that you loose the ability to debug easily.     I can't recall if I was able to compile the PPL's with debugging enabled as use LabVIEW's "Debug Application or Shared Library" option as a workaround.

[JÞB]

In addition to everything mentioned before.

LabVIEW will search for dependencies according to the configuration options in search paths.  So, if your check out folders are not exactly the same on every deployment and development machine TSVN will unsync everything when dependencies are found in a location different from where they were committed from.  It's a well known PITA but, you must get every member of the choir to "Come to Jesus" and open the same songbook. 

Also watch the TSVN ignore files.  *.Aliases contains things like MyComputer (which is not YourComputer) I'll typically ignore

*.Aliases, *sandbox*.*, *untitled*.*, *.*bak* and a few other gems.

[DLMC]

"

In addition to everything mentioned before.

"

This is interesting, and baffling, and instructive.

Thanks all, you have answered my questions completely and I get it.

But

I'm even more confused than ever over the many possible options to tie this all together.  Or if it is even possible to avoid the pitfalls.

We use Teststand as well as Labview and the test stations can all debug code, which because of unique circumstances, is essential.

This code was built with a UI where pop-up windows are constrained within that UI - Testing my fixes and upgrades showed that during debug sessions, that UI constraint is not observed. OR perhaps changes have disconnected the pop up vi's from being recognized, they float outside of that UI window.  I am assuming that I need to compile the UI projects to pull all of that back together again - that UI is a LV thing, not a Teststand thing.  A distinction that I understand, but find hard to reconcile.

Teststand is an overly complex monster.

I clearly have a lot more reading to do, having only two weeks worth of training and experience with these tools, supporting code that has been worked on by contractors for years, and left alone for two years, is a daunting task.

Again thanks folks, you're helped a lot.

Be well,

DLC

[JÞB]

---

@NIExpert wrote:

I believe @DMLC is suggesting to use compiled PPLs in the deployment, which I agree with.

My experience with using the Teststand Deployment tool to create the PPLs has been mixed.  I have had much better success with creating the PPL's separately and explicitly linking the sequence calls to functions inside the PPL during development.

Downside to this approach of course is that you loose the ability to debug easily.     I can't recall if I was able to compile the PPL's with debugging enabled as use LabVIEW's "Debug Application or Shared Library" option as a workaround.

---

For my experience the better solution is to use lvlib (unpacked) and call from TestStand through the

calling project if you add the library itself to your project (calling from the reuse library lvproj is not OK since that contains Unit Tests, Examples and documentation outside the lvlib itself) 

TestStand then only allows access to public vis, vims, ctls, etc.. and you can still deploy and debug with the much cheaper debug deployment licenses.  My rule of thumb here is: 1 development environment for each developer, 1 debug deployment license for any first article of any system and RTE's for follow on systems.  Usually the client will see the debug deployment advantage and pony up the cost+ for debug licenses on all systems. Then I can additionally deliver some LabVIEW example code to test any hardware issues when things break.

[JÞB]

Oh, you are new. And inheriting older stuff.

That is going to get you another tidbit of history.

A while back developers found out, painfully, that when you Run a vi and any non-running modal vi had it's front panel open, the modal vi would block access to everything else and hang LabVIEW. That required a Task Manager process kill and, changes got lost. Very annoying 😒

One common solution was to run "Revolk All Modals.vi" but, this darned vi actually changed the VI Property FP.Behavior. After a Save All, your modals aren't modal anymore.

Solution: the VI Properties FP.Behavior and FP.Visible are run-time writeable. Create your own Dialog VIs and handle those properties inside them.

There is a Snippet in a Community Nugget somewhere that I wrote to show you how.

Kudos for anyone who tracks down the post from my tag cloud