mdennie

Can you have the brat VI dynamically register for the value change event on the control, and ignore the change in value that gets observed on the next poll?

if you notice a change in value while polling, disable the dynamically registered event (wire in a not-a-ref) before writing to the value(signaling) property, and re-enable it after.

I've got LabVIEW 2012 and I checked the Example Finder under "New Examples for LabVIEW 2012". The only example listed is "TDMS Defragment - Fragment Indicator.vi."

Does anyone know where the "promised" example can be found?

I am very interested in what others have to say about predicting memory usage.

QUOTE (neB @ Oct 10 2008, 09:22 AM)

Matlab has a function that will tell you the size of the largest 10 contiguous blocks of free memory. You cannot have a single variable that is larger than your largest contiguous memory block. I assume it must be getting this memory from some Windows DLL call (although I don't know which one). If you could duplicate these system calls in LV, you might be able to get what you need.

Has any found a solution to _predicting_ 'memory is full' errors?

I know all about reducing memory usage and dividing up memory blocks, but I'd still like to know how to avoid being unceremoniously dumped from my application when it hits the limit. If I'm about to acquire a large dataset at the user's request and there isn't a large enough memory block available, I'd like to inform the user and recover.

...

This leaves to options, open all VIs from windows explorer or put all components in the same project. The problem with the later is if all developers use the same project file you will be forced to check in and out .lvproj and the .lvib every time you do anything to the project.

...

I'm very interested in solutions to the problem of multiple developers working in a single project. I've been trying to figure out how NI envisioned this would work.

If LV8 is supposed to provide an environment for large, multi-developer projects, surely someone considered that more than one person would work on a project at one time and that the project would be under source control. I was expecting to see an article from NI somewhere describing a suggested practice, but so far at NITS and in other conversations with NI folks I've gotten nothing but blank stares concerning this issue.

How are changes to a LV project managed when multiple developers are working in the project simultaneously? Has anyone encountered this yet?

-- Matt

At first glance, building a fairly simple example executable in LV8 results in an EXE of just over 1 MB.

Creating an installer results in a folder 'Volume' consuming almost 70 MB. Sheesh!

Part of this is the LV Runtime installer (about 20 MB), and part of it is the Math Kernel Library (about 6 MB) I just read about in a related thread.

But what is all the other stuff {'MU' (2 MB), 'MDF' (8 MB), 'svcloc' (1.4 MB), 'logos' (13 MB), 'license' (the Engilsh license is 65K but the Korean license is over 1 MB), and 'support files'} and are there ways to reduce it?

Any help or suggestions are appreciated, or links to similar topics elsewhere (I haven't found any).

Thanks,

-- Matt

I can understand, NI does not want to release a full installer on their FTP-Server. This will cause 4 or 5 times more traffic. But they could e.g. bring out full Release for BitTorrent?

Do you get an Update-CD if you are in the SSP?

If history is any guide, there won't be a release of bug fix full installer (even to SSP customers). I voted for one, though.

I see that an 8.0.1 Run-Time installer is available for Mac and Linux, but not for Windows? Looking at the date on the file 'LabVIEW_8.0_Runtime_Engine.exe' in the directory

ftp://ftp.ni.com/support/labview/windows/runtime/8.0/

versus in the directory

ftp://ftp.ni.com/support/labview/windows/runtime/8.0/8.0.0/

the dates and file sizes are exactly the same. Do I take this to mean that the Windows Run-Time 8.0 works fully with 8.0.1 EXEs, or have they just not updated the FTP site correctly yet?

Must be the latter. I see that my lvrt.dll file was updated by the 8.0.1 development system installation.

NI support says it'll be a few weeks before an RTE installer will be available... However, building an app installer from an updated system should install the updated RTE, right?

Also, 8.0.1 built apps are supposed to run with the 8.0.0 RTE.

No word on what actually changes in the 8.0.1 RTE.

-- Matt