Memory Management in LabView / DLL

Hi all,
I have a problem concerning the memory management of LabView. If my data is bigger than 1 GB, LabView crashes with an error message "Out of Memory" (As LabView passes Data only by value and not by reference, 1 GB can be easily achieved). My idee is to divide the data structure into smaller structures and stream them from Hard Disk as they are needed. To do so, i have to get access to a DLL which reads this data from disk. As a hard disk is very slow in comparison to RAM, the LabView program gets very slow.
Another approach was to allocate memory in the DLL and pass the pointer back to LabView...like creating a Ramdisk and reading the data from this disk. But memory is allocated in the context of Labview...so LabView crashes because the memory was corrupted by C++. Allocating memory with LabView-h-Files included doesnt help because memory is still allocated in the LabView context. So does anybody know if it's possible to allocate memory in a C++-DLL outside the LabView context, so that i can read my Data with a DLL by passing the pointer to this DLL by LabView? It should work the following way:
-Start LabView program--> allocate an amount of memory for the data, get pointer back to labview
-Work with the program and the data. If some data is needed, a DLL reads from the memory space the pointer is pointing at
-Stop LabView program-->Memory is freed
Remember: The data structure should be used like a global variable in a DLL or like a ramdisk!
Hope you can understand my problem
Thanks in advance
Christian
THINK G!! ;-)
Using LabView 2010 and 2011 on Mac and Win
Programming in Microsoft Visual C++ (Win), XCode (Mac)

If you have multiple subvis grabbing 200MB each you might try using the "Request Deallocation" function so that once a vi is done processing it releases the memory.
LabVIEW Help: "When a top-level VI calls a subVI, LabVIEW allocates a data space
of memory in which that subVI runs. When the subVI finishes running, LabVIEW
usually does not deallocate the data space until the top-level VI finishes
running or until the entire application stops, which can result in out-of-memory
conditions and degradation of performance. Use this function to deallocate the
data space immediately after the VI completes execution."
Programming >> Application Control >> Memory Control >> Request Deallocation
I think it first appeared in LabVIEW 7.1.
Message Edited by Troy K on 07-14-2008 09:36 AM
Troy
CLDEach snowflake in an avalanche pleads not guilty. - Stanislaw J. Lec
I haven't failed, I've found 10,000 ways that don't work - Thomas Edison
Beware of the man who won't be bothered with details. - William Feather
The greatest of faults is to be conscious of none. - Thomas Carlyle

Similar Messages

Memory Management in Labview 5.1

Hi, I program a vi program for some laboratory measurement. it allows the user select which measurement he/she wants to do by selecting from a popup dialog when the program starts. But it seems tat, the vi loads all the different measurement vis into memory. what I want is that, when the user choose to do measurement 1, only the measurement 1 vi in the memory, otherwise, it just wastes memory.how can I do that?
Thank you!
I've uploaded a sample bg.vi there, hope that you can help me modify them to realize my dream.
Attachments:
Bg.llb ‏53 KB

Hello,
Oleg's suggestion to use VI Server would most definitely save you a lot of memory. If you are not familiar with the VI Server programming model, you may find it easier to use property nodes and invoke nodes instead of the Call By Reference Node. Take a look at the VI Server examples that ship with LabVIEW for additional information. I've attached a simple VI that demonstrates the basic flow of the VI Server model.
Regards,
Kent Leung
Applications Engineering
National Instruments
Attachments:
Bgnew.vi ‏29 KB

Resizing an array of struct inside a DLL using the memory manager

Hi all,
I dug deep inside the boards, but wasn't able to find a solution for my problem.
I'm building a dll, which does some imageprocessing and should return an array of structs to labview, with one struct for every element in the image.
As I don't know the number of elements beforehand and the limit of the number is numbers of magnitude larger then the expected one, I don't want to allocate such a huge chunk of memory prior to the dll call in labview.
In a former version I used a 2d array for the elements, where each row holds the values of every element. Here I used the NumericArrayResize-function, which worked quite well. But I have to add more sub-processes and using structs (or clusters in labview) appears to be more usefull and cleaner for me, in addition I had to cast some of the elements back and foreward a few times.
So one element-struct should hold 2 singles and 1 uint32. My question is now, how can I resize this array of struct with memory manager functions as the NumericArrayResize-functions does not suit this purpose?
(Accessing a given array of structs inside the DLL and after that reading the changed values in Labview is surprisingly easy )
Thanks in advance
Solved!
Go to Solution.

Well, I was able to solve it myself. I found this thread, where the first post of rolfk made me thinking. It appeared to me, that the numericarrayresize-function behaves very similar to the realloc-function of c. So I used the type unsigned int 8 (which is just one byte) and multiplied it by the number of bytes used by one struct, in my case 12 bytes (4+4+4) and then multiplied it by the number of structs (elements in the image) i have. Luckily it worked and the memory block was resized exactly as I wanted it to be. Important to note: do not forget to adjust the size element of the handle, otherwise Labview does not know about the changed size.

(Un)Managed Wrapper calling LabView-Dll

Hello,
I am focused with a strange behaviour which i could not explain.
I had to extend the NI272x in my C++ unmanaged environment for a StepType http://sine.ni.com/cs/app/doc/p/id/cs-11443/lang/de/pdf/yes/pdf that descripes a functional testsystem.
Unfortuanately NI provieds no C Api for this devices. But LabView drivers were available. So i made LabView Wrapper
to consume it. This is worked fine.
A current extension development is done in C#. It loads the old unmanaged StepType-Dll during runtime. If the LabView Dll is
used. I am not able to load the DLL with C# via SDK LoadLibrary to memory.
To understand whats going on i have provied a small project that descripes the task.
Regards
Juergen
=s=i=g=n=a=t=u=r=e= Click on the Star and see what happens :-) =s=i=g=n=a=t=u=r=e=
Solved!
Go to Solution.
Attachments:
TestProject.zip ‏129 KB

I believe the problem is that the dll you are loading has dependent dlls. The normal behavior of LoadLibrary does NOT automatically look for dependent dlls in the same directory as the dll you are loading. You should use LoadLibraryEx with the LOAD_WITH_ALTERED_SEARCH_PATH option instead (This is what teststand uses when loading dlls with the c++ adapter). See Microsoft's help info on MSDN for more details about LoadLibraryEx and LOAD_WITH_ALTERED_SEARCH_PATH.
Hope this helps,
-Doug

Fatal Internal Error: "Memory Manager.cpp", line 547

Hello,
I am using LV 2009 and I am also getting an error as follows:
=======================================================
Fatal Internal Error: "Memory Manager.cpp", line 547
LabVIEW version 9.0.1
You will lose any unsaved work. For assistance in resolving this problem, please relaunch LabVIEW, or contact National Instruments.
=======================================================
I get this error when I start executing steps on TS 4.2.1 as well as when I do "Unload All Modules" in TS. Please find the attched logs. Further, I could not run anything in TS and need to restart the PC to re-run the sequence after everytime this error occurs.
We have transited through LV 8.0, 8.2, 8.5 and now 2009 over past 4 years for our project and this is the first time I could see this error.
Please help.
Thanks.
Attachments:
lvlog2010-06-09-10-06-07.txt ‏2 KB
lvlog2010-06-09-18-52-36.txt ‏1 KB
lvlog2010-06-09-19-16-20.txt ‏2 KB

Adding on to Pritam's post:
For the earlier "Fatal Internal Error: "Memory Manager.cpp", line 547" , we found that a couple of our dll's which were developed in LV 8.5.1 had not been recompiled in LV2009. After recompiling each of them in LV2009, and then running the same sequences in TestStand,this error vanished.
But now again we're seeing this error, and that too only on 3 PCs systems out of 5 PCs!
The same installer has been installed on all 5 sytems (after removing the earlier installers and running MSI Blast.exe them).
The error now appears again, only when we try to exit TestExec.exe and another tool built in LabVIEW.
So everything works fine and tasks are performed,etc, but when we close the window or try the exit that program, the "Fatal Internal Error: "Memory Manager.cpp", line 547" pops up.
If we say "OK" to it, the window closes, but the Task is seen still running in the Task Manager and has to be manually terminated (End Task).
Does anyone know what could be going wrong?

Calling LabVIEW DLL from C with 2d array strings

I am trying to write a DLL in C that calls a LabVIEW DLL that has a
number of functions that each return a 2D array of strings which are the formatted
measurements, with column 1 being the measurement name and column 2
being the measurement. I wanted to use the 2D array of strings since
this would give a uniform interface for returning measurements. Ive
cobbled together bits and pieces of messages and example code I've
found here into something that almost works, and was hoping someone
with a little more experience in interfacing C with LabVIEW DLLs would
be able to help me.
Here's a little
snippet from the header file generated when building the LabVIEW DLL:
typedef struct {
long dimSizes[2];
LStrHandle String[1];
} TD1;
typedef TD1 **TD1Hdl;
long __cdecl TestVI(char serialNumber[], TD1Hdl *formattedMeasurements, char ErrorDescription[], long len);
The "TestVI" VI generates a 2D array of strings. The cell contents and number of rows are random to
simulate different measurement names and measurements.
Here's a snippet for the wrapper class:
class CArgoTestsLabVIEW
public:
CArgoTestsLabVIEW();
virtual ~CArgoTestsLabVIEW();
// test modules called from parent DLL
BOOL GetResult_LV(CString resultName, double *result);
long TestVI_LV(CString serialNumber);
private:
TD1Hdl m_LVStringArray;
CMapStringToString m_resultMap;
InitMeasurementsArray();
PopulateResultMap();
The "m_LVStringArray" is intended to hold the 2D array of strings that
the test modules spit out. The "m_resultMap" is just for accessing the
measurements from the parent DLL via the "GetResult_LV" function.
The implementation of TestVI_LV is:
long CArgoTestsLabVIEW::TestVI_LV(CString serialNumber)
long rc = 0;
char errStr[BUFFERLEN];
strcpy(errStr,"");
rc = InitMeasurementsArray();
if (rc == 0) {
rc = TestVI(serialNumber.GetBuffer(serialNumber.GetLength()), &m_LVStringArray, errStr, BUFFERLEN);
PopulateResultMap();
return rc;
The accessor functions InitMeasurementsArray and PopulateResultMap are:
long CArgoTestsLabVIEW::InitMeasurementsArray()
MgErr err;
if (m_LVStringArray)
DSDisposeHandle(m_LVStringArray);
m_LVStringArray = (TD1Hdl)DSNewHandle(sizeof(TD1));
// code to check for NULL
// Set number of strings in array to 0
(*m_LVStringArray)->dimSizes[0] = 0;
(*m_LVStringArray)->dimSizes[1] = 0;
// Set total size of array structure. For now it is only as big as the long variable.
err = DSSetHandleSize((UHandle)m_LVStringArray, sizeof(long));
// code to check for error
return 0;
void CArgoTestsLabVIEW::PopulateResultMap()
int numberOfResults;
int i;
int charCnt;
numberOfResults = (*m_LVStringArray)->dimSizes[0];
if (numberOfResults == 0) {
return;
m_resultMap.RemoveAll();
for (i = 0; i < numberOfResults; i++) {
charCnt = (*((*m_LVStringArray)->String[i * 2]))->cnt;
(*((*m_LVStringArray)->String[i * 2]))->str[charCnt] = '\0';
charCnt = (*((*m_LVStringArray)->String[i * 2 + 1]))->cnt;
(*((*m_LVStringArray)->String[i * 2 + 1]))->str[charCnt] = '\0';
m_resultMap.SetAt((LPCTSTR) (*((*m_LVStringArray)->String[i * 2]))->str, (LPCTSTR) (*((*m_LVStringArray)->String[i * 2 + 1]))->str);
The problem I have is that I eventually get an access violation from
the run-time engine if I try to call the test VI in a loop. I'm
obviously having a memory management problem, but it escapes me as to
where the problem is. Anybody have any ideas?

smercurio_fc wrote:
The problem I have is that I eventually get an access violation from the run-time engine if I try to call the test VI in a loop. I'm obviously having a memory management problem, but it escapes me as to where the problem is. Anybody have any ideas?
(*((*m_LVStringArray)->String[i * 2]))->str[charCnt] = '\0';
Hi smercurio,
Have you solved this? I don't work with C much anymore, but it looks, here, as if the memory at str[charCnt] isn't yours to address/change.
Is index "charCnt" one char past the end of the String-memory allocated by LabVIEW?
just an idea!
Hmmm, maybe page 9 is a bit far back to fish in the unanswered posts.
Message Edited by Dynamik on 03-03-2006 02:03 AM
When they give imbeciles handicap-parking, I won't have so far to walk!

LabVIEW DLL 2D Array output deallocation

Hey everyone,
I am using a custom built DLL made with LabVIEW. One of the functions outputs a 2D array of data by "handle". I can catch the 2D array from the function just fine from within my C program, however I have a question about deallocating the memory allocated by the LabVIEW DLL for the 2D array.
I call the DLL function repeatedly in a loop and as this occurs the RAM used on my machine continues to increase until it is full or I exit the program. There are no other dynamically allocated peices of data within the C program that could be causing this.
The question is, can I call free() on the 2D array handle safely? Is this the correct way to deallocate the 2D arrays passed out of LabVIEW DLL functions? One dimension of the 2D array is always the same size, but the other dimension varies per call.
Here is an example (I have renamed function calls and library headers due to security reasons):
#include "DLLHeader.h"
int main(void)
    ResponseArrayHdl myArray = NULL;
    DLL_FUNC_InitializeLibrary();
    DLL_FUNC_ConfigurePortWithDefaults("COM3");
    DLL_FUNC_StartAutoSend(9999999);
    while(DLL_FUNC_IsTransmitting())
        DLL_FUNC_GetAllAvailableResponseMessagesByHndl(&myArray);      // gets the 2D array
        // do something with array data here!
        free(myArray);   // is this the appropriate way to clean up the array?
        Delay(0.05);
    DLL_FUNC_GetAllAvailableResponseMessagesByHndl(&myArray);      // gets the 2D array
    // do something with array data here!
    free(myArray);   // is this the appropriate way to clean up the array?
    DLL_FUNC_ShutdownLibrary();
    return 0;
from DLLHeader.h:
typedef struct {
    } ResponseMessage;      // created by the LabVIEW DLL build process
typedef struct {
    long dimSize;
    ResponseMessage Responses[1];
    } ResponseArray;
typedef ResponseArray **ResponseArrayHdl;   // created by the LabVIEW DLL build process
I want to make sure this is an appropriate technique to deallocate that memory, and if not, what is the appropriate way? I am using LabVIEW 7.1 if that matters. The C program is just ANSI C and can be compiled with any ANSI C compliant compiler.
Thanks!
~ Jeramy
CLA, CCVID, Certified Instructor

Tunde A wrote:
A relevant function that will be applicable in this case (to free the memory) is the "AZDisposeHandle or DSDisposeHandle". For more information on this function and other memory management functions, checkout the " Using External Code in LabVIEW" reference manual, chapter 6 (Function Description), Memory Management Functions.
Tunde
One specific extra info. All variable sized LabVIEW data that can be accessed by the diagram or are passed as native DLL function parameters use always DS handles, except the paths which are stored as AZ handles (But for paths you should use the specific FDisposePath function instead).
So in your case you would call DSDisposeHandle on the handle returned by the DLL. But if the array itself is of variable sized contents (strings, arrays, paths) you will have to first go through the entire array and dispose its internal handles before disposing the main array too.
Rolf Kalbermatter
Message Edited by rolfk on 01-10-2007 10:43 PM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

How can I calling LabView DLL within LabView and pass similar Data Types?

I am trying to use an Instrument Driver, which is created in LabView6.1 as a DLL. At this point I have only LabView to test this DLL. I was wondering, is there easy way to find out what sort of Parameter or Data Type I should be using.
How can I pass the following data with in LabView:
LVRefnum as Type?
LVBoolean as Type?
TD1 (a structure) as Type?
It is funny to see that I am able to create a DLL in labview but having trouble calling it within LabView. I thought, it would be easier to test the DLL within the same environment.
Basically, I am more worried about the VISA calls that are used in the driver to communicate with instrument. Because, there is no link to �VISA32.dll� in
the header file, is that handled by the LV Run-time engine? I guess more details are needed on using the LabView DLL within LabView from National Instrument Technical Support.
Attachments:
RL5000.h ‏1 KB

A LVRefNum seems to be an unsigned long data type (32bit). You can cast it
in LV then use that as a parameter to call the DLL. (an Occurrence type
seems to be a Ulong32)
When you created the DLL what was the resulting type for the LVRefNum?
Happy Holidays
"Enrique" wrote in message
news:[email protected]..
> I see...
>
> After doing some research, it seems to me that there is no easy way to
> find out the type of data, other than looking at the header file and
> have documents like Using External Code in LabVIEW handy. The
> following information is from that document:
>
> LVBoolean is an 8-bit integer. 1 if TRUE, 0 if FALSE.
>
> LabVIEW specifies file refnums using t
he LVRefNum data type, the
> exact structure of which is private to the file manager. To pass
> references to open files into or out of a CIN, convert file refnums to
> file descriptors, and convert file descriptors to file refnums using
> the functions described in Chapter 6, Function Descriptions.
>
> I know you are creating a dll in LabVIEW, but I am pretty sure the
> information applies as well and is useful. For your dll this can be
> interpreted that, rather than passing a LVRefnum, try passing the file
> descriptor.
>
> From the header file, is can be deduced that TD1 is a cluster in
> LabVIEW.
>
> You are right in saying that "more details are needed on using the
> LabView DLL within LabView from National Instrument Technical
> Support.".
>
> Enrique

Why does LabView dll not work in C Thread?

Hello Everybody,
I want to use a LAbView Application as Dll in a Console Application.
There is an Example Available (DLL_Example.zip)in (Displaying the Front Panel of a LabVIEW-Built DLL Function)
When I use this Example in a Windows Console Application, it Works fine (It is important for me, to see the LV Window!)
Code example:
/* Example Start *******************************************/
int main(int argc, char* argv[])
double Y = 4;
double X = 5;
double Result = 0;
SimpleCalculator(1, Y, X, &Result);
printf("Result = %f", Result);
return 0;
/* Example Stop *******************************************/
When I use the function "SimpleCalculator" in a Thread, the LabView Window never appear, what's wrong?
Code example:
/* Example Start *******************************************/
DWORD WINAPI LVThread(LPVOID lpParameter)
double Y = 4;
double X = 5;
double Result = 0;
SimpleCalculator(1, Y, X, &Result);
printf("Result = %f", Result);
return 0;
int main(int argc, char* argv[])
DWORD ThreadID;
CreateThread(NULL,0,LVThread, NULL, 0, &ThreadID);
getchar();
return 0;
/* Example Stop *******************************************/
I'm using Microsoft Visual Studio 6.0. and LabView 7.0
Thanks for every help.

bobby wrote:
Hello Everybody,
I want to use a LAbView Application as Dll in a Console Application.
There is an Example Available (DLL_Example.zip)in (Displaying the Front Panel of a LabVIEW-Built DLL Function)
When I use this Example in a Windows Console Application, it Works fine (It is important for me, to see the LV Window!)
Code example:
/* Example Start *******************************************/
int main(int argc, char* argv[])
double Y = 4;
double X = 5;
double Result = 0;
SimpleCalculator(1, Y, X, &Result);
printf("Result = %f", Result);
return 0;
/* Example Stop *******************************************/
When I use the function "SimpleCalculator" in a Thread, the LabView Window never appear, what's wrong?
Code example:
/* Example Start *******************************************/
DWORD WINAPI LVThread(LPVOID lpParameter)
double Y = 4;
double X = 5;
double Result = 0;
SimpleCalculator(1, Y, X, &Result);
printf("Result = %f", Result);
return 0;
int main(int argc, char* argv[])
DWORD ThreadID;
CreateThread(NULL,0,LVThread, NULL, 0, &ThreadID);
getchar();
return 0;
/* Example Stop *******************************************/
I'm using Microsoft Visual Studio 6.0. and LabView 7.0
Thanks for every help.
Check out luciangeeks's explanation elsewhere on this forum in several threads about the message loop needing to be pumped by the intial thread starting up the LabVIEW runtime system. In Windows console applications the hidden startup code linked in from the C runtime library to intialize the environment before passing control to the console applications main function also contains a message loop, polling the Windows message queue to among other things translate those messages into keychars so that the C runtime library function getchar() and friends can work as expected. It also makes the console application look responsive to the Windows system so that Windows doesn't think it would need to shutdown the application. LabVIEW DLLs really running as GUI components can't work without an active message loop making sure those system messages are retrieved and distributed to the according (usually hidden) VI windows. However the setup in Windows makes it such that a DLL sort of inherits the message loop of the thread which first entered that DLL. If that thread does not have a message loop, LabVIEW windows simply can't work properly and this means that the LabVIEW code is not managed properly and therefore won't run.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

RE: (forte-users) memory management

Brenda,
When a partition starts, it reserves the MinimumAllocation. Within this
memory space, objects are created and more and more of this memory is
actually used. When objects are no longer referenced, they remain in memory
and the space they occupy remains unusable.
When the amount of free memory drops below a certain point, the garbage
collector kicks in, which will free the space occopied by all objects that
are no longer referenced.
If garbage collecting can't free enough memory to hold the additional data
loaded into memory, then the partition will request another block of memory,
equal to the IncrementAllocation size. The partition will try to stay within
this new boundary by garbage collecting everytime the available part of this
memory drops below a certain point. If the partition can't free enough
memory, it will again request another block of memory.
This process repeats itself until the partition reaches MaximumAllocation.
If that amount of memory still isn't enough, then the partition crashes.
Instrument ActivePages shows the memory reserved by the partition.
AllocatedPages shows the part of that memory actually used.
AvailablePages shows the part ot that memory which is free.
Note that once memory is requested from the operating system, it's never
released again. Within this memory owned by the partition, the part actually
used will always be smaller. But this part will increase steadily, until the
garbage collecter is started and a part of it is freed again.
There are some settings that determine when the garbage collector is
started, but I'm not sure which ones they are.
The garbage collector can be started from TOOL using
"task.Part.OperatingSystem.RecoverMemory()", but I'm not sure if that will
always actually start the garbage collector.
If you track AllocatedPages of a partition, it's always growing, even if the
partition isn't doing anything. I don't know why.
If you add AllocatedPages and AvailablePages, you shoud get the value of
ActivePages, but you won't. You always get a lower number and sometimes even
considerably lower. I don't know why.
Pascal Rottier
Atos Origin Nederland (BAS/West End User Computing)
Tel. +31 (0)10-2661223
Fax. +31 (0)10-2661199
E-mail: Pascal.Rottiernl.origin-it.com
++++++++++++++++++++++++++++
Philip Morris (Afd. MIS)
Tel. +31 (0)164-295149
Fax. +31 (0)164-294444
E-mail: Rottier.Pascalpmintl.ch
-----Original Message-----
From: Brenda Cumming [mailto:brenda_cummingtranscanada.com]
Sent: Tuesday, January 23, 2001 6:40 PM
To: Forte User group
Subject: (forte-users) memory management
I have been reading up on memory management and the
OperatingSystemAgent, and could use some clarification...
When a partition is brought online, is the ActivePages value set to the
MinimumAllocation value, and expanded as required?
And what is the difference between the ExpandAtPercent and
ContractAtPercent functions?
Thanks in advance,
Brenda
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

The Forte runtime is millions of lines of compiled C++ code, packaged into
shared libraries (DLL's) which are a number of megabytes in size. The
space is taken by the application binary, plus the loaded DLL's, plus
whatever the current size of garbage collected memory is.
Forte allocates a garbage-collected heap that must be bigger than the size
of the allocated objects. So if you start with an 8MB heap, you will always
have at least 8MB allocated, no matter what objects you actually
instantiate. See "Memory Issues" in the Forte System Management Guide.
-tdc
Tom Childers
iPlanet Integration Server Engineering
At 10:37 PM 6/11/01 +0200, [email protected] wrote:
Hi all,
I was wondering if anyone had any experience in deploying clients on NT
concerning
the memory use of these client apps.
What is the influence of the various compiler options (optimum
performance, memory use etc)?
We seem to see a lot of the memory is taken by the Forte client apps (seen
in the Task Manager
of NT) in respect to the other native Window apps. For example an
executable of approx 4Mb takes up to
15Mb of memory. When I look at the objects retained in memory after
garbage collection, these are about
2Mb. Where do the other Mb's come from?

Can't step into CVI step that calls LabVIEW DLL?

Windows 2000 SP1
TestStand 2.01f
LabWindows CVI 6.0
LabVIEW 6.1 Runtime
We have a framework based on TestStand and CVI. A customer has supplied us
with a DLL written in LabVIEW 6.1 and packaged with the Application Builder
that we need to call from a CVI test library DLL. They say they can't
supply us with a non-LabVIEW implementation. We installed the LabVIEW 6.1
run-time. We added code to the CVI test library to dynamically load and
unload the LabVIEW DLL using LoadLibrary and FreeLibrary. LoadLibrary is
called in a function in the MainSequence Startup step group, FreeLibrary is
called in a function in the MainSequence Cleanup step group.
Things run as expected when the CVI DLL is built as Release or Debug and the
CVI
adapter is configured to run in-process.
However, if we try to debug CVI DLL by building it as Debug and configuring
the CVI adapter to run in an external instance of CVI, things hang the first
time we try to step into, or run, a CVI test library step that calls one of
the functions in the LabVIEW DLL. On the Applications tab in Task Manager,
the item named LabVIEW is marked as 'Not Responding'. The only way to
recover is to kill the LabVIEW process, which takes down CVI and TestStand
with it. If none of the LabVIEW DLL functions are called, no problems are
seen (no hang).
I assume the problem has something to do with the library getting mapped to
the wrong process space (TestStand v. the external CVI instance). Is there
any way to solve this problem? Any ideas or suggestions would be
appreciated.
Joe

> Out of curiousity, what happens if you attempt to debug your DLL from
> CVI? For example, configure TestStand to run its steps 'inProcess'...
> but then close the TestStand application and in CVI, configure it so
> that the Specified External Process dialog points to TestStand's
> SeqEdit.exe (CVI launches TestStand when debugging the project). Once
> TestStand is running, run your test and set your break points as
> usual, you should be able to step into the CVI code if nothing else.
> If not, I would be interested in hearing what problems you encounter.
When 'debugging' SeqEdit from CVI, we experienced no lock up.
Thanks for this suggestion. Debugging from CVI is a workaround for now,
though not highly desirable as it is reverse from normal debug proc
edure
(user can't step into CVI from TestStand). Still would like to know if
'normal' debugging of this problem is possible.
> The nice thing about debugging directly from Labwindows/CVI while
> TestStand runs 'inprocess' is that you can avoid some library linking
> errors, which may be the source of the troubles you are seeing.
The problem appears to be general to LabVIEW DLLs called from an external
instance of CVI under TestStand. We were able to reproduce the problem with
a simple LabVIEW VI compiled to a DLL, then called from a simple CVI DLL
under TestStand. We will package up some sample code and submit it to NI
tonight or tomorrow.
Thanks for you help.
Joe

C++ build error with LabVIEW DLL

Hi, I'm a student at UC Irvine learning to use LabVIEW. I am working on a practice project for which I have to use a PID system to control the temperature of an object. Things are starting to get a little messy with nested control statements, loops, etc., so I figured I'd export a LabVIEW DLL with all the hard to code stuff, such as interfacing with my instruments, and plotting data or whatever, and do the number crunching and keeping track of stuff in C++.
The DLL file I made in LabVIEW went off without a hitch as far as I can tell, but when linking it to my C++ test program (which at this point is just including the LabVIEW's .h file for the DLL and an empty main() function), I get a lot of build errors. I am using Dev-C++ which uses g++ to compile the code.
Here is a pic of my build errors:
Solved!
Go to Solution.
Attachments:
LabVIEW_compile_error.JPG ‏184 KB

Normal windows apps are not as forgiving about where you can put your DLL as LabVIEW. You have to have a DLL either in the direcotry where the executable file itself resides (that would be your build directory, not the source directory), the windows or system directory, or any directory that is set in the PATH environment variable. Anythin else will most likely not work, or at least not reliably.
No need to add the cintools directory into your include file paths nor the library file paths. you would only need that if you decided to let the DLL export native LabVIEW data types in which case you would need the LabVIEW manager functions to prepare the correct data buffers.
Rolf Kalbermatter
Message Edited by rolfk on 07-30-2009 07:49 AM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Memory management in plugins using Cocoa

Hello,
In Obj-C memory management guide stated: "If you spawn a secondary thread, you must create your own autorelease pool as soon as the thread begins executing; otherwise, you will leak objects."
I assume that it also applies to Acrobat Plugins? What are the guidelines of using NSAutoreleasePools in plugins and is there any specific things in plugins' memory manamgement?

If you have multiple subvis grabbing 200MB each you might try using the "Request Deallocation" function so that once a vi is done processing it releases the memory.
LabVIEW Help: "When a top-level VI calls a subVI, LabVIEW allocates a data space
of memory in which that subVI runs. When the subVI finishes running, LabVIEW
usually does not deallocate the data space until the top-level VI finishes
running or until the entire application stops, which can result in out-of-memory
conditions and degradation of performance. Use this function to deallocate the
data space immediately after the VI completes execution."
Programming >> Application Control >> Memory Control >> Request Deallocation
I think it first appeared in LabVIEW 7.1.
Message Edited by Troy K on 07-14-2008 09:36 AM
Troy
CLDEach snowflake in an avalanche pleads not guilty. - Stanislaw J. Lec
I haven't failed, I've found 10,000 ways that don't work - Thomas Edison
Beware of the man who won't be bothered with details. - William Feather
The greatest of faults is to be conscious of none. - Thomas Carlyle

Memory manager.cppについて

いつもお世話になっております。
下記問題について、どなたかご存知でしたら教えて頂けないでしょうか。
VI編集中に致命的な内部エラーとして、「memory manager.cpp　ライン566」のダイアログが表示されます。
ブロックダイアグラム上で編集作業時、ショートカットキーの「Ctrl」+「Z」もしくは「Ctrl」+「S」を押した際に本エラーが頻発します。
その他の操作では出たことがありません。
ダイアログの内容からメモリに関するエラーなのだと察することはできますが、具体的な解決法がわかりません。
どなたかご存知でしょうか。
ちなみに、Windows7 HomePremium（64bit）にてLabVIEW2010を使用しております。
解決済！
解決策の投稿を見る。
添付:
ライン566.jpg ‏36 KB

haljion 様
平素より弊社製品をご利用頂きまして、誠にありがとうございます。
ご報告いただいた症状は、不特定の状況で生じるLabVIEW 2010の既知の不具合となっております。
積極的な解決策ではございませんが、この不具合の発生後、LabVIEWの再インストールをすることで改善された例が報告されています。
なお、この不具合は、LabVIEW 2011以降では修復がなされております。
この不具合ですが、不特定の状況で生じるものであるため、こちらで再現することが困難な次第です。
そこでお教えいただきたいのですが、この不具合はどのようなタイミングから発生するようになったのでしょうか。
また、特定のVIの編集を行っている際のみ発生するもの、もしくは、編集するVIに依らず発生するもののいずれでしょうか。
日本NI 早田

Passing Array of Srings between Visual Basic and Labview dll

I have searched and searched for the correct way to pass an array of
strings between Visual Basic 6.0 and a Labview 7 dll. So far, I still
do not know how to pass the array. When I create the dll in LV, the
array of strings is presented as a string, not an array. I am familiar
with passing arrays of type double, but I really need to know how to
pass an array of strings. Any and all help is appreciated.
Bob

Hey Bob,
From what I understand, that can get kind of messy. You have to allocate the memory in VB in the format that LabVIEW expects (see the externalcode.h file in National Instruments\LabVIEW 7.0\cintools for details). Then pass a pointer to that location to LabVIEW. There are a couple of related examples online. They don't necessarily show how to pass an array of strings to VB, but they should show how to pass a string and an array. I hope this helps.
Using Microsoft Visual Basic to Call LabVIEW DLLs That Pass String Data Types
http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=B123AE0CB9B0111EE034080020E74861&p_...
Using Microsoft Visual Basic to Call LabVIEW DLLs That Pass Array Data Pointers
http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=B45EACE3D9E556A4E034080020E74861&p_...
Regards,
Chris J

Memory Management in LabView / DLL

Similar Messages

Maybe you are looking for