VI corrupt and executes slowly - Anybody knows this behaviour?

[Jenso]

Hey guys,

I am right now rebuilding our DAQmx driver in order to make it compatible to our new framework. Now, when doing this I wanted to measure performance and was shocked that the execution of reading a value from the FGV that stores data for 256 channels took about 12 ms. After a lot of searching and doing I experienced that also a global variable version takes about 2..3 ms for reading a value.

So me and my colleague broke our heads about what the reason is until we finally gave up. Half an our later I started analyzation again and had to realize that the execution time for the FGV version speeded up about factor 250x. The global version was still at the old slow speed. I thought about what I might have done wrong to get it right and came to the conclusion that I only reverted some changes and saved the FGV VI.

So my colleague came up with the idea that maybe the VI was corrupt. And voilá: After rebuilding the global variable version I found that the global variable VI was corrupt too. Exactly the same controls cause the global version to execute roughly 250x faster than the old version.

By the way, all the timings were comparably the same when running the tests in an Application instead of inside the IDE.

Now my question is: Did somebody already experience a similar behaviour and can tell me on what occasion this happened (maybe deliver a root cause) or even (and that would be awesome) how to detect if a VI is corrupt or not (Because the VI can be executed without any errors or notifications).

My trouble is simply how to make sure that this either does not happen again or how to analyse slowly reacting project to find that the root cause lies in a corrupt file.

My stats:

I am using Labview 2014 SP1

Windows 10

In the attachment you can find the source code (I am afraid it is a total mess because actually it was intended to develop a driver and not to go looking for a phantom). In the source code you have to open Source/SubVI/SandBox/PerfTest - Timing of address comparison.vi.

In the front panel you can select the Global type to use for execution (FGV runs fine now, Global is the corrupt one and Global rebuild is the rebuilded and now working one). Cycle time mean is the value of interest (though it is no mean anymore).

Thanks a lot in advance!!!

[billko]

Although this probably isn't the issue here, I'd like to point out that the first version of LV to officially support Win10 is LV 2015.  (https://www.ni.com/en/support/documentation/compatibility/17/labview-and-microsoft-windows-compatibi...).

[Jenso]

Thanks for the reply.

I already know this, but unfortunately our IT dept. did not leave us a choice. And due to the fact that a lot of our production facilities are running on Labview 2011 - 2014 we cannot simply upgrade without the fear of incompatibility issues. And if in addition you have to struggle with your boss to get an additional Labview version (even one more?? We already have four!) then you try to deal with what you got when the projects still dont get fewer...

Back to the topic:

We already experienced some issues with Windows 10, but I was hoping that this one was not belonging to that category...

[wiebe@CARYA]

Keep in mind that VI's that are called a lot will dramatically slow down when the front panels are open. Updating the FP simply takes time.

EDIT: Although it's unlikely that this is happening since you test in an exe (TL;DR), the FP's could still be open though.

[Jenso]

I actually had the same idea, so I removed as many controls from the front panel as possible. I also tested the use of different front panel styles (I usually use the silver line). But this still had no effect. Only after rebuilding the VI exactly the same way it was before, the issue was solved.

But maybe I really miss the obvious thing here and it was not corrupt but a mistake sitting in front of the display.

Thx.

[wiebe@CARYA]

---

wiebe@CARYA wrote:

Keep in mind that VI's that are called a lot will dramatically slow down when the front panels are open. Updating the FP simply takes time.

EDIT: Although it's unlikely that this is happening since you test in an exe (TL;DR), the FP's could still be open though.

---

That edit crossed your reply. Sorry about that.