building the application, the vi calling std deviation and variance shows a broken arrow.

[altenbach]

same argument, though. (The VI also returns "mean" at the top connector ;))

[AnnaMariaAnna · Accepted solution]

[altenbach]

You can always make your own. not as "advanced" as the name suggests. 😄

[AnnaMariaAnna]

That's what I did! 😄

[altenbach]

---

@AnnaMariaAnna wrote:

That's what I did! 😄

---

Yes, I saw your posts after I posted.... Good luck!

[BoKnows · Accepted solution]

---

@AnnaMariaAnna wrote:

I think that the problem arises because the vi is called as a subvi of a test vi loaded as in the following:

C:\Program Files (x86)\National Instruments\LabVIEW 2017\vi.lib\Utility\victl.llb\Preload Instrument.vi

C:\Program Files (x86)\National Instruments\LabVIEW 2017\vi.lib\Utility\victl.llb\Run Instrument.vi

what do you think? can it be?

---

In order to use these VIs, you had to look through vi.lib to find VIs rather than use palettes to get the functionality you desired (or in this case upgrade a VI from ~20 years ago without looking to migrate to newer API).  This is generally a dangerous practice to use while developing your application.  There are a number of VIs in that library that aren't exposed on palettes for a variety of reasons.  The most common reasons are to maintain backwards compatibility or to provide a specific internal function that likely won't behave as you desire if you use it for any other use case.

Instead of these VIs, you'll want to look at the VI Server calls instead.  They're what replaced those VIs and what are maintained today.  This may not be the highest priority in your current situation.  But, keep it in mind as you go forward 😃 

[AnnaMariaAnna · Accepted solution]

Hi,

I got your suggestion and replaced those vi by Open VI Reference  and Invoke Node.😃

[wiebe@CARYA]

I had similar problems with the dll. One build of the application wouldn't run on a few specific PCs, while another build of the application would run on it. Both use the same math functions.

It seemed completely random, although the error looked like related to SSE\SSE2.

This also changed over time. After random (unrelated) changes, the problem appeared. Other VIs using the dll did work.

Making the mean and std.dev. manually was the quick way out...