Announcing LabVIEW 2010 Service Pack 1

[Kevin_R]

OK, I just ran into an unexpected unpleasant surprise.

After installing Service Pack 1, I discovered all of my serial port assignments had been jumbled. I have 25 ports on this machine, and it took the better part of an hour to get the COMx numbers back in order.

If this is an unavoidable side effect of installing the upgrades, a warning message should be displayed to export the settings from NIMAX or something and then re-import. Or, better yet, such a utility should be part of the process.

[Jeffrey_P]

Kevin,

Your situation looks like the behavior described here.

You mentioned that you upgraded LabVIEW, but my assumption is that you also upgraded NI-Serial, the driver that communicated with COM Ports, and that's the cause of the error. This document contains instructions for a utility that will reassign the port numbers.

Respectfully,

[pnielsen@gplains.com]

The service pack hosed up my VI analyzer. After compiling the program would not run. Removed SP1 and re installed 2010 DS2 and the VI analyzer is working and the compiler is now working. I will not put SP1 back on my PC.

[altenbach]

---

pnielsen@gplains.com wrote:

The service pack hosed up my VI analyzer. After compiling the program would not run. Removed SP1 and re installed 2010 DS2 and the VI analyzer is working and the compiler is now working. I will not put SP1 back on my PC.

---

Make sure to let NI know, there might be a simple and known workaround already. If not, solving it now will help others. Please provide more details. Do you have an unusual installation? Did you get any error messages?

LabVIEW is always compiled, can you clarify what you mean by "after compiling"? Are you building an executable?

[Ray.R]

I read through the posts where people had difficulties with the installation of SP1.

In my case, the process went smoothly, and it seems to have fixed an issue I was having with the original 2010 installation.

Everything runs smoothly and I did not notice any adverse effects.

Thanks SP1 team!

[dav2010]

Is this different from the upgrade released in February?  The February release caused lots of failures, and after a lot of discussion with NI support, we decided not to install it at all, if I remember correctly.  Dare I download and install this one now?

[Ray.R]

It should be the same.

[richjoh]

How do I make my Installer use LV2010 runtime and not SP1 runtime? I've already reverted back to LV2010 but my project still shows SP1 for the runtime.

I am attempting to revert my LV code Installer to use LV2010 runtime and not SP1 runtime. SP1 always appears in the "Additional Installers" menu and I know of no way to force LV2010 runtime. The target PC errors with something like "this version of Labview is unable to run VI with seperated code... LV2010 doesn't have access to cache object..."

[coldatom]

I am experiencing several serious problems with Labview 2010 SP1 that sound like the kinds of problems that SP1 was supposed to fix.  These issues are becoming a real impediment to my research.

(1)  Editing the front panel is extremely slow--it can take 1 to 30 seconds to create, paint, or modify the display format of a control or indicator.  The system freezes and displays the rotating circle (equivalent of the spinning beach ball in OSX.)

(2)  There are similar slow downs in editing the block diagram, although not as drastic (1 to 4 seconds).  Programming labview is like playing the piano, and my hands are much faster than the block diagram can respond. (By the way--I loathe the auto tool select and auto wire routing.)

(3)  Saving can take 1 to 3 minutes with a fair amount of variability.

(4)  We observe that Labview slows down in execution speed over time.  As an example, after quitting labview and reopening a vi, we see that the vi takes ~60 ms to execute.  Over the course of a few hours, we see that the execution time climbs to ~300ms.  The fix seems to be quitting labview entirely (not just closing the vi) and then reopening the vi.

(5)  Occasionally, when running the code, labview takes up 100% of physical memory available (8GB), starts generating lots of hard faults,labview completely freezes up (no error messages) and the code becomes corrupted (i.e.. the !saved! version of the code on the disk will no longer load, and I have to revert to a back up version--yikes!)  Having the code freeze up is bad, but I don't understand why the code saved to the harddrive is becoming corrupted.  This has happened twice in the past ~1.5 months.  We backup our files religiously.

Problems (4) and perhaps (5) might arise from a memory leak somewhere in my code, but I have been programming labview since 1997 and I don't see one and the failure mode is unlike what I have seen with past memory leaks (going back to labview ~4).  Currently, my money is on a bug in Labview 2010 SP1.

I am running:

Windows 7 Enterprise SP1

Labview 2010 SP1

CPU AMD Phenom II X6 1090T Processor 3.20GHz

Graphics Card: ATI Radeon HD 4250

8GB RAM

Installed NI cards:

1x PCI6133

2x PCI6733

1x PCIe-6259

I have attached a zipped folder with the main code Master.vi .   (I would upload all the subvi's, but the total zipped folder is 100MB, way over the file size limit.)

Master.vi is very large and needs to stay that way.  The front panel spans two 28" monitors.  A rough count gives:

        Front Panel:

          752 indicators or controls (counting arrays as a single object, but counting items within clusters individually, pop-up menues counted)

          192 booleans (counting arrays as single objects)

            50 graphs (x-y, waveform, etc, but nothing too fancy like 3D)

            6 tab objects with a total of 50 individual tabs

        Block Diagram:

            The core code consists of a stack structure  that executes a Case structure with 74 values.

The vi does not handle extremely large data sets (in my opinion).  We typically scan 16 AI channels at ~1 MHz for 1 to 50ms, analyze them, store key results, retake more data, overwriting the previous data, and do this at ~1Hz rep rate.

Any feedback you can give would be great.  I am a longtime user of labview, I really like it, and I train all of my PhD and undergraduate students in it, but if programming large/complex vi's is going to be this painful, I will have to start looking for another solution.

Thanks,

James

[altenbach]

---

@coldatom wrote:

I am experiencing several serious problems with Labview 2010 SP1 that sound like the kinds of problems that SP1 was supposed to fix.  These issues are becoming a real impediment to my research.

---

Can you clarify that statement:

Did you have the same problems in 2010-non-SP1 and were promised a fix in SP1?

Is it a new problem in SP1?
Did it ever work correctly, and in what LabVIEW version?

Some of the front panel update speed loss could be due to the redraw penalty imposed overlapping controls. For example you have buttons on top of graphs, etc.

The code is too convoluted and incomplete (missing VIs) for troubleshooting, but a casual glance at it shows a huge amount of coercions and type mismatch. For example you use EXT for "current frame" and the "stack" array, even though they start out as I16, then get coerced to I32, then to EXT along the line. Is is usually better to decide on the correct representation once, then stick with it.

All that said, your VI opens fine and reacts fast to editing operation on my very old Athlon XP. Maybe there is something wrong with your computer. I assume your OS is 64 bit since you have 8GB of RAM. I also assume you use 32 bit LabVIEW.