Passing array to call library function running on VxWorks (cRIO)
Hello,
I am using a cRIO 9012 running VxWorks.
I have a Call library function VI in my application and I want to pass arrays of doubles to this function.
The problem is that I can not access the values in the array.
Here is the source code of my function:
#include "D:\\Programme\\National Instruments\\LabVIEW 8.5\\cintools\\extcode.h"
double avg_num(double *in1, double *out1)
double ret;
ret = in1[0] + out1[0];
return ret;
The value of in1[0] and out1[0] is always.
When passing no arrays but single values, all is fine. But since my application is more complex than this example, I need to pass arrays.
The block diagram and parameter specification is as shown in the attached screenshots.
I am compiling the source code with the Gcc 6.3 which is available here:
http://zone.ni.com/devzone/cda/tut/p/id/5694
What am I doing wrong?
Or is passing arrays not supported on cRIO?
Maybe the makefile needs to be modified?
Thank you.
Best regards,
Christian
Attachments:
vi.JPG 88 KB
parameter.JPG 41 KB
I guess I have solved the problem.
The key was to set the parameter "Minimum size" for all function parameters to <None>.
Having this, I can read the passed arrays. I do not know why this works but at the moment, it is ok for me.
Thank you all.
Similar Messages
-
Passing arrays with Call Library Function does not work after application builder
Calling a DLL with Call Library Function which requires an array of data works correctly in Labview, but after building an exe with application builder, the call no longer works. Dereferecing the pointer in the DLL retuns all 0s and not the actual values.
Solved!
Go to Solution.
Attachments:
TEST.zip 28 KBI did not run your code because it is a little unclear to me what it does.
Two things:
First, is the DLL you are calling the DLL-ified version of PopUpNames.vi? Then the problem is likely that the panel is not being built into the DLL.
When LabView builds an application / dll, it strips the front panel and block diagram from all VIs that it doesn't think need to show a panel at run time. This reduces file size and increases code security. The App Builder's panel inclusion logic can be overridden by Build Specifications -> Source File Settings -> Remove front panel. A better method is to put a property node on a control in a window you want to show marking it "visible"; this is sufficient to tell the App Builder it should keep the panel.
Currently Source File Settings shows "no dependencies" (clearly incorrect---another evil side effect of Express VIs I guess) but if you change the settings as shown below to keep ALL panels, one might hope the App Builder can figure it to keep the panel when it deconstructs the Express VI. (Alternatively convert the Express VI into a regular one.)
A second comment: I am a bit flummoxed at the larger goal here. You are calling LabView DLL from LabView, which doesn't make a lot of sense, so I assume your larger goal is to call LabView from C or vice-versa. In that case be aware that your DLL is x86 (32-bit) but you are passing 64-bit ints as your pointers. In this case it is 32-bit LabView with 32-bit pointers in embedeed in 64-bit containers calling 32-bit LabView with 32-bit pointers in embedeed in 64-bit containers, so it all works, but if your going to call this from C or whatnot you're going to have to follow that same design.
When calling C code the LabView Call Library Function does have a "unsigned pointer-sized integer" data type that always appears to be 64 bits in the dev env but which actually passes a 64 or 32-bit int to the DLL depending on the environment. The "pointer sized int" has to be 64 bits in the "LabView" part of the code because LabView's strong typing requires the data type to be determined at compile time. Casting all pointers to the largest data type in LabView makes it possible to write platform-independent code, but down at the Call Library level you still have to put the right number of bytes on the stack. -
Call Library Function Running slow
Hi
I’m using a third party IO board for DAQ experiment. To create a real-time DAQ VI I used the DLL file which’s supplied by the manufacture, I managed to get the VI working to read from the board by using the Call Library function. But the vi running slow, it takes about 10s to get the reading or spot any change, while using Visual basic application any changes are spotted instantly
Any help will be appreciated
Marwan
http://www.geocities.com/marwan_m13/weemee8080.jpg
Attachments:
Project[2].vi 42 KBJust for analysing, where the timeleakage occurs:
Try to measure the execution time of the library function(s). It whould
be interesting, if they realy produce the timeleakage or not.
I modified your project for this (see attachment).
Attachments:
Project[2].vi 53 KB -
Call library function node with array of clusters using array data pointer
Hello all.
I am writing a LabVIEW wrapper for an existing DLL function.
The function has, as one of its parameters, an array of structs. The struct is very simple, containing two integers. I am using the call library function node to access it.
In Labview I created an array of clusters, where the cluster has two 32-bit integers as its members. So far, so good.
Now I have to pass this in to the Call Library Function Node. Here I am running into trouble.
I have used The topic in LAVA and The topic in the knowledge base as my primary sources of information, though I have read a bunch of forum topics on the subject too.
I do understand that I could write a new function which takes as a parameter a struct with the size as the first member and an array as the second, and I might just do this and have it call the regular function, but I was hoping to do it more simply.
According to the C file which LabVIEW generates for me from the CLFN when I choose "Adapt to Type" and "Array Data Pointer", the prototype it is expecting is:
int32_t myFunc(uint32_t handle, uint16_t channel,
int32_t FIFOnumber, void data[], int32_t numWords, int32_t *actualLoaded,
int32_t *actualStartIndex);
And the prototype of the function in my DLL is
int borland_dll myFunc(DWORD handle, usint channel,
int FIFOnumber, struct mStruct *data, int numWords, int *actualLoaded, int *actualStartIndex);
This looks like a match to me, but it doesn't work (I get garbage in data). From the topic in LAVA referenced above, I understood that it would work. It does not.
If I cast data to the pointer-to-pointer I get when I generate c code by wiring my struct to a CIN and generating, then I seem to get what I expect. But this seems to work when I choose "pointers to handles" too, and I would expect array data pointer to give a different result.
Is there any way to get this to work directly, or will I have to create a wrapper? (I am currently using LabVIEW 2011, but we have customers using 2009 and 2012, if not other versions as well).
Thank you.
Batya
Solved!
Go to Solution.OK, here is more detailed information.
I have attached the VI.
This is the code from the "C" file created by right-clicking the CLN and creating a "C" file.
When the parameter in the CLN is set to "array data pointer":
/* Call Library source file */
#include "extcode.h"
int32_t Load_Transmit_FIFO_RTx(uint32_t handle, uint16_t channel,
int32_t FIFOnumber, void data[], int32_t numWords, int32_t *actualLoaded,
int32_t *actualStartIndex);
int32_t Load_Transmit_FIFO_RTx(uint32_t handle, uint16_t channel,
int32_t FIFOnumber, void data[], int32_t numWords, int32_t *actualLoaded,
int32_t *actualStartIndex)
/* Insert code here */
When the parameter is "pointers to handles":
/* Call Library source file */
#include "extcode.h"
/* lv_prolog.h and lv_epilog.h set up the correct alignment for LabVIEW data. */
#include "lv_prolog.h"
/* Typedefs */
typedef struct {
int32_t control;
int32_t data;
} TD2;
typedef struct {
int32_t dimSize;
TD2 data[1];
} TD1;
typedef TD1 **TD1Hdl;
#include "lv_epilog.h"
int32_t Load_Transmit_FIFO_RTx(uint32_t handle, uint16_t channel,
int32_t FIFOnumber, TD1Hdl *data, int32_t numWords, int32_t *actualLoaded,
int32_t *actualStartIndex);
int32_t Load_Transmit_FIFO_RTx(uint32_t handle, uint16_t channel,
int32_t FIFOnumber, TD1Hdl *data, int32_t numWords, int32_t *actualLoaded,
int32_t *actualStartIndex)
/* Insert code here */
When the parameter is set to "handles by value":
/* Call Library source file */
#include "extcode.h"
/* lv_prolog.h and lv_epilog.h set up the correct alignment for LabVIEW data. */
#include "lv_prolog.h"
/* Typedefs */
typedef struct {
int32_t control;
int32_t data;
} TD2;
typedef struct {
int32_t dimSize;
TD2 data[1];
} TD1;
typedef TD1 **TD1Hdl;
#include "lv_epilog.h"
int32_t Load_Transmit_FIFO_RTx(uint32_t handle, uint16_t channel,
int32_t FIFOnumber, TD1Hdl *data, int32_t numWords, int32_t *actualLoaded,
int32_t *actualStartIndex);
int32_t Load_Transmit_FIFO_RTx(uint32_t handle, uint16_t channel,
int32_t FIFOnumber, TD1Hdl *data, int32_t numWords, int32_t *actualLoaded,
int32_t *actualStartIndex)
/* Insert code here */
As to the DLL function, it is a bit more complicated than I explained above, in the current case. My VI calls the function by this name in one DLL, and that DLL loads a DLL and calls a function (with the same name) in the second DLL, which does the work. (Thanks Rolfk, for helping me with that one some time back!)
Here is the code in the first ("dispatcher") DLL:
int borland_dll Load_Transmit_FIFO_RTx(DWORD handle, usint channel, int FIFOnumber, struct FIFO_DATA_CONTROL *data, int numWords, int *actualLoaded, int *actualStartIndex)
t_DispatchTable *pDispatchTable = (t_DispatchTable *) handle;
int retStat = 0;
retStat = mCheckDispatchTable(pDispatchTable);
if (retStat < 0)
return retStat;
if (pDispatchTable->pLoad_Transmit_FIFO_RTx == NULL)
return edispatchercantfindfunction;
return pDispatchTable->pLoad_Transmit_FIFO_RTx(pDispatchTable->handlertx, channel, FIFOnumber, data, numWords, actualLoaded, actualStartIndex);
borland_dll is just "__declspec(dllexport)"
The current code in the DLL that does the work is:
// TEMP
typedef struct {
int control;
int data;
} TD2;
typedef struct {
int dimSize;
TD2 data[1];
} TD1;
typedef TD1 **TD1Hdl;
// END TEMP
int borland_dll Load_Transmit_FIFO_RTx(int handlertx, usint channel, int FIFOnumber, struct FIFO_DATA_CONTROL *data, int numWords, int *actualLoaded, int *actualStartIndex){
struct TRANSMIT_FIFO *ptxFIFO; //pointer to transmit FIFO structure
usint *pFIFOlist; //pointer to array of FIFO pointers to FIFO structures
int FIFOentry, numLoaded;
usint *lclData;
usint nextEntryToTransmit;
// TEMP
FILE *pFile;
int i;
TD1** ppTD = (TD1**) data;
TD1 *pTD = *ppTD;
pFile = fopen("LoadFIFOLog.txt", "w");
fprintf(pFile, "Starting Load FIFO with %d data words, data pointer 0x%x, with the following data: \n", numWords, data);
for (i = 0; i < numWords; i++) {
fprintf(pFile, "%d: control--0x%x, data--0x%x \n", i, data[i].control, data[i].data);
fflush(pFile);
fprintf(pFile, "OK, using CIN generated structures: dimSize %d, with the following data: \n", pTD->dimSize);
for (i = 0; i < numWords; i++) {
fprintf(pFile, "%d: control--0x%x, data--0x%x \n", i, pTD->data[i].control, pTD->data[i].data);
fflush(pFile);
// END TEMP
if ((handlertx) <0 || (handlertx >= NUMCARDS)) return ebadhandle;
if (cardrtx[handlertx].allocated != 1) return ebadhandle;
pFIFOlist = (usint *) (cardrtx[handlertx].segaddr + cardrtx[handlertx].glob->dpchn[channel].tr_stk_ptr);
pFIFOlist += FIFOnumber;
ptxFIFO = (struct TRANSMIT_FIFO *)(cardrtx[handlertx].segaddr + *pFIFOlist);
//use local copy of ptxFIFO->nextEntryToTransmit to simplify algorithm
nextEntryToTransmit = ptxFIFO->nextEntryToTransmit;
//on entering this routine nextEntryToLoad is set to the entry following the last entry loaded
//this is what we need to load now unless it's at the end of the FIFO in which case we need to wrap around
if ( ptxFIFO->nextEntryToLoad >= ptxFIFO->numEntries)
*actualStartIndex = 0;
else
*actualStartIndex = ptxFIFO->nextEntryToLoad;
//if nextEntryToLoad points to the last entry in the FIFO and nextEntryToTransmit points to the first, the FIFO is full
//also if nextEntryToLoad == nextEntryToTransmit the FIFO is full and we exit without loading anything
if (( (( ptxFIFO->nextEntryToLoad >= ptxFIFO->numEntries) && (nextEntryToTransmit == 0)) ||
( ptxFIFO->nextEntryToLoad == nextEntryToTransmit)) && (ptxFIFO->nextEntryToLoad != INITIAL_ENTRY)){
*actualLoaded = 0; //FIFO is full already, we can't add anything
return 0; //this is not a failure, we just have nothing to do, this is indicated in actualLoaded
numLoaded = 0;
lclData = (usint *)data; //must use 16 bit writes to the module
//conditions are dealt with inside the for loop rather than in the for statement itself
for (FIFOentry = *actualStartIndex; ; FIFOentry++) {
//if we reached the end of the FIFO
//if the module is about to transmit the first element of the FIFO, the FIFO is full and we're done
//OR if the module is about to transmit the element we're about to fill in, we're done - the
//exception is if this is the first element we're filling in which means the FIFO is empty
if ((( FIFOentry >= ptxFIFO->numEntries) && (nextEntryToTransmit == 0)) ||
((FIFOentry == nextEntryToTransmit) && (FIFOentry != *actualStartIndex) )){
*actualLoaded = numLoaded;
//set nextEntryToLoad to the end of the FIFO, we'll set it to the beginning next time
//this allows us to distinguish between full and empty: nextEntryToLoad == nextEntryToTransmit means empty
ptxFIFO->nextEntryToLoad = FIFOentry;
return 0;
//we reached the end but can continue loading from the top of the FIFO
if ( FIFOentry >= ptxFIFO->numEntries)
FIFOentry = 0;
//load the control word
ptxFIFO->FifoData[FIFOentry * 3] = *lclData++;
//skip the high of the control word, the module only has a 16 bit field for control
lclData++;
//now put in the data
ptxFIFO->FifoData[(FIFOentry * 3) + 2] = *lclData++;
ptxFIFO->FifoData[(FIFOentry * 3) + 1] = *lclData++;
numLoaded++;
//we're done because we loaded everything the user asked for
if (numLoaded >= numWords) {
*actualLoaded = numLoaded;
ptxFIFO->nextEntryToLoad = FIFOentry+1;
return 0;
//if we reached here, we're done because the FIFO is full
*actualLoaded = numLoaded;
ptxFIFO->nextEntryToLoad = FIFOentry;
fclose (pFile);
return 0;
As you can see, I added a temporary diagnostic with the structures that were created in the "Handles by value" case, and print out the data. I see what is expected, whichever of the options I pick in the CLN!
I understood (from the information in the two links I mentioned in my original post, and from the name of the option itself) that "array data pointer" should pass the array of data itself, without the dimSize field. But that does not seem to be what is happening.
Batya
Attachments:
ExcM4k Load Transmit FIFO.vi 15 KB -
In the labview manual, there is very little mention about the use of waveform.How is this waveform being called and can i have an example to see how this work.
Also in the adapt to type paramete, what does this parameter do and in what circumstances do we need to use it.The manual say something about the use of this parametr.It says that scalar elements in arrays or clusters are in line.For example a cluster containing anumeric is passed as pointer to a structure containing a numeric. What does this statement mean?
Can i imply t
hat if my input is a struct, can i use a adapt to type parameter to overcome this incompatibility?Can i also have an example to let me have a better idea.thank youI'm going to share my experience with the "Adapt to Type" parameter.
Attached to this message is an example. The attachment is a zip file with three files: a dll, a c file and a vi written in LabVIEW 6. The dll contains a function that return a structure with 3 values (like the coordinates of a point in space, that is, (x, y, z)). You can see how the function was constructed by looking at the c file.
In LabVIEW, I created a cluster with the same three parameters. Then, I configured the call library function following the function prototype as in the c file. For the point variable I use "Adapt to Type".
I hope this can give you a head star.
Best regards;
E. Vargas
www.vartortech.com
Attachments:
pointexample.zip 63 KB -
The data type is
typedef enum {false, true} bool;
typedef float flt4;
typedef double flt8;
typedef int i32s;
typedef unsigned int i32u;
typedef short int i16s;
typedef unsigned short i16u;
typedef signed char i08s;
typedef unsigned char i08u;
struct t_UnwrapData {
struct {
i08u flags;
i16u unwrap_m;
i08u weight_m;
} status;
flt4 *ph2pi;
flt4 *weight;
flt4 *gamma;
flt4 *phase;
i08u *flags;
i08u *neigh;
i32s neighOfst[8];
i32s r,c;
i32s x0,y0,xSz,ySz;
flt8 unwTime;
flt4 binCut;
Please Could someone help me suggesting how I pass this dat
a type to call library function?Hi Setu,
Here is a solution that I have been playing to return back an array of clusters
typedef struct
int32 dimSize;
uInt8 array[1];
} LVU8;
typedef LVU8 **LVU8Hdl;
typedef struct
U32 DeviceId;
U32 VendorId;
U32 BusNumber;
U32 SlotNumber;
LVU8Hdl SerialNumber;
} LVDEVICE_LOCATION;
typedef LVDEVICE_LOCATION **LVDEV_LOC_HANDLE;
typedef struct
int32 dimSize;
LVDEVICE_LOCATION cluster_array[1];
} LVDEV_LOC_ARRAY;
typedef LVDEV_LOC_ARRAY **LVDEV_LOC_ARRAY_HANDLE;
LVPLX_API void GetAllDevices(LVDEV_LOC_ARRAY_HANDLE cluster_array)
int i,j;
int numDevices = 3;
DSSetHandleSize(cluster_array, sizeof(int32)+3*(sizeof(LVDEV_LOC_ARRAY)+(sizeof(int32)+16*sizeof(L
VU8))));
(*cluster_array)->dimSize = 3;
(*((*cluster_array)->cluster_array[0]).SerialNumber)->dimSize =16;
(*((*cluster_array)->cluster_array[1]).SerialNumber)->dimSize =16;
(*((*cluster_array)->cluster_array[2]).SerialNumber)->dimSize =16;
for(i=0; i<3; i++)
((*cluster_array)->cluster_array[i]).BusNumber = i;
((*cluster_array)->cluster_array[i]).VendorId = i*5;
for(j=0;j<16;j++)
(*((*cluster_array)->cluster_array[i]).SerialNumber)->array[j] = (10*j)+i;
The code doesnt do much but returns back 3*cluster which the array in my cluster is sized for 16. The problem I've been having , was ensuring I have allocated enough memory to handle the complete structure. This works for me, now all I have to do is put the real code in which get my array of data from the instruments.
Hope it helps
Regards
Ray Farmer
Regards
Ray Farmer -
Window doesn't close wheh Call Library Function Node set to Run in Any Thread
This is a problem regarding Call Library Function Nodes running in the UI thread or any thread.
I have a camera which has its own API supplied as a dll. I have created a set of VI wrappers which each call a function in the dll through a Call Library Function Node.
Initially each CLFN was set to 'Run in the UI thread' (the default).
To start the camera streaming images I call (through a CLFN)
ICubeSDK_Start(int CamIndex, Hwnd, ImgHandle, bool Preview, bool callback);
If Preview = True then the image is displayed in a preview window.
If ImgHandle = NULL a default preview window
is used.
In the CLFN definition I define:
ImgHandle as a U32
Preview as a I32
To stop the camera streaming images I call
ICubeSDK_Stop(int CamIndex)
In the actual implementation I set ImgHandle = 0 (NULL) and Preview = 1 (true).
This all works fine, and a preview window is opened and images displayed. When I call ICubeSDK_Stop the preview window is closed.
However, I would prefer to set the CLFN to 'Run in any thread' because
a) when run in the UI thread the preview window randomly gets sent to the back when I switch focus between open VI windows (presumably because it is in the same thread as the VIs)
b) I don't want to put unnecessary stuff in the UI thread
c) my (naive?) understanding is that it is safer to run in any thread
So I have set all CLFNs to 'Run in any thread'
When I do this the preview window opens OK, and behaves like any other non LabVIEW controlled window in terms of focus. But when I call ICubeSDK_Stop() the preview window does not get closed properly, it just shows a blank image. I can't close it manually, there is no X in the corner and no option to close it from the taskbar. To get rid of it I have to close the LabVIEW project it is spawned from, which often results in a crash. It does appear as a separate item in task manager but if I 'end process' it, LabVIEW closes (and often crashes) as well.
If I change only the CLFNs that call the Start and Stop functions back to 'Run in the UI thread' then it all works fine again, except that the preview window gets sent to the back randomly as before.
So, what do I have to do to get the preview window to close properly if I set the CLFN to 'Run in any thread'.
Alternatively, is there a way to close the window programmatically (ie force it to close) after I have called ICube_Stop.
Thanks
DAveHi Dave,
The "Run In UI Thread" switches from the thread the VIs currently executing in to the user interface thread. If you select "Run in Any Thread", the Call Library Function Node continues in the currently executing thread. By default, all Call Library Function Nodes run in the User Interface thread.
Before you configure the Call Library Function Node to run in any thread, you have to make sure that the code is thread safe. Code is thread safe when it does not store any global data (e.g. global variables, files on disks, etc.), does not access any hardware, does not make calls to any functions, libraries or drivers that are not thread safe.
Unfortunately, since you said that your DLL accesses hardware, it is not recommended to use "Run in Any Thread." This is probably why you are seeing the crash.
If your preview window gets sent to the back you can programmatically bring it forward. Here is an example of how this can be done: http://decibel.ni.com/content/docs/DOC-4551
If you want to completely close the window down you can do so as described in this link: http://digital.ni.com/public.nsf/allkb/81E9C1441900FFCE8625748F0055DBB0?OpenDocument
I also thought you might find this useful: http://zone.ni.com/devzone/cda/tut/p/id/3009
I hope this helps.
Regards,
Mahdieh G
Applications Engineer
National Instruments UK&Ireland -
How can I debug the Call Library Function at run-time
I've written a VI using the CLF to call a DLL which was compiled off-site by another engineer using MSVC. Even though the VI runs without flagging any errors, the VI is not doing what I expect. Is there any way of finding out if the DLL is been called correctly? The first function that is called doesn't return any value, but I think that it should. Does this mean that the DLL is not being called correctly? Note also that the DLL works fine with a JAVA GUI.
Make sure that you are specifying the proper function prototype in the call library function. If you are slightly off the call will not work properly. Ask the offsite engineer to provide you with this data. Another tip is to build the dll with the option to show front panel when called. You can actually popup the dll like you would a subvi. If you design it with test indicators showing on the front panel that is a great way to determine if it is working. Hope this helps.
BJD1613
Lead Test Tools Development Engineer
Philips Respironics
Certified LV Architect / Instructor -
Description to pass 'enum' to a call library function node
Hi,
I'm looking for some description/help regarding how to pass 'enum' to a call library function node.
The API documentation that I have states something like this:
enum ibApi_DEVICETYPE_e {
ibApi_DEVICETYPE_A = (1<<0),
ibApi_DEVICETYPE_B = (1<<1),
ibApi_DEVICETYPE_C = (1<<2),
ibApi_DEVICETYPE_D = (1<<3),
ibApi_DEVICETYPE_ANY = 0x3f /* used with filter */
typedef ibApi_UINT32 ibApi_DEVICETYPE;
The above is one of the input parameters to my call library function node. Hint to some documentation/example VI should be enough.An enum requires sequential values, so you wouldn't be able to enter an arbitrary value for each of the enumeration items. You can still use an enum, but you would need a small "accessor" VI that converts the enum to a number. I do this often, as I prefer enums. You can, however, use a ring constant which allows you to enter your own values for each of the labels. With a ring constant you can enter the value based on a format you've selected. By default the format is "Automatic", which means you enter a decimal value. If you right-click on the ring constant and select "Format & Precision" you can change it "Hexadecimal". Then, in the "Edit Items" tab you can enter a hex value in the "Values" column. So, you would have a row that has "ANY" in the "Items" column and "3F" in the "Values" column. This is only if you prefer to see the values in hex.
Tip: You should make this into a typedef.
Note: The values for each of the constants are not 0, 1, 3, but rather 1, 2, 4, 8, etc... -
Failed to run parallel path when using call library function node in LV2009
I have a problem with two parallel paths not being run in parallel on LabView 2009.
See the image below.
This code initializes an external device, the upper part contains a call library function node to download my code into the device. When done, the function returns and the "Done" flag is set to True.
The lower part contains a call library function node to check the download status, reporting the percentage of downloaded code.
This updates a progress bar that is referenced by the calling VI module and this works fine in LV 7, 8 and 2011. The lower path of the VI updates the progress bar while the CLFN in the upper part is still downloading code to my device.
Somehow, in LV2009 this does not work when running this inside my application. When running just the calling VI (the window showing the progress bar) it works but not when that VI is called by my application.
Is there some limit on parallel threads that is different in 2009 than in other versions ?
Or is there some other problem in 2009 that might cause this problem ?
My labview version is 9.0f3 (32-bit).
Regards,
RobI've just installed the DETT tool and checked what the different versions of LabView do.
In LV2009 the application instance runs in a thread (5) but the modal dialog (the VI above) then drops to thread 0 and stays in thread 0.
In LV2011, stays in the same thread as the application instance and only a trigger event (this could be the progress bar reference?) is executed in thread 0.
So it seems there is a 'feature' in LV2009 where modal dialogs are by default not following the preferred execution system set in the VI properties ...
When I change this from "same as caller" into another thread (I used "other 1") then my progress bar works as expected.
I'm not a LabView thread expert (not even a novice ) so I'm just guessing that "other 1" as a thread is OK. This VI only runs during startup of the application to download the code to my device.
To answer Ben's question: "What thread does a modal VI run in?":
In LV2009, the modal VI runs in thread 0 (UI thread ?). When the preferred execution system is set to another thread, the modal dialog still starts in thread 0 but then switches over to the other thread.
In LV2011, the model VI runs in the caller's thread (preferred execution system set to "follow caller") from start.
Thanks,
Rob -
I have created a simplee application that controls a piece of equipment with all control via a supplied dll. Hence, there are a number of Call Library Function Nodes within the code and a modicum of other LabVIEW code. Everything works fine as a LabVIEW application, but when converted to an executable, although the application runs and functions, as soon as any Call Library Function Node is executed, calling from the dll, I get the C++ debug error in the attachment.
Is this something that I can solve from within LabVIEW, or is the problem likely buried in the dll?
Damian
Attachments:
CLFN error.JPG 22 KBHi Wise,
Try building an executable from a very simple VI that makes one call to the dll. Have you also try using the Call Library Function node on other simple dlls that you know will work?
Regards,
Stanley Hu
National Instruments
Applications Engineering
http://www.ni.com/support -
Parameters into Call Library Function Node not being passed
I am trying to configure an instrument using IVI Instrument drivers. In the first vi that does this, the instrument (a sig gen) is being set correctly to the desired frequency and power. In a second vi I try to change the frequency and power, the sig gen does not change.
If I run the second vi stand-alone with the original settings, again there is no change. But if I change the value of frequency or power by any amount, that parameter is now set properly on the sig gen.
When I look at the IVI vi, I can see that the parameters I send in are getting to the Call Library Function Node.
Any idea what the problem is.
Thanks.
p.s., Are there instructions on how to paste a picture or link to a vi into my post. This question would have been a lot easier and clearer to ask.Hi cgantz,
While it sounds, possibly, like a "state-caching"-related bug in the IVI driver, it certainly would be good to have a look at your code. Look a the bottom-left area of the "Message Body" when replying - there's an "Attachment" tool for this purpose!
Cheers.
"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare) -
Running Call Library Function Node in UI Thread
Hi there!
The Call Library Function Node has a undocumented upper left input wire, left of the output wire, corresponding to the return value, if any.
It looks like I can use this wire to influence the order in which different Call Library Function nodes execute. Is this a documented feature I can rely on or am I walking on thin ice here ?
Furthermore I call the same non-thread-safe function twice in my VI, the Call Library Function Node of each being set to "Run in the UI Thread". If I don't enforce the functions to be called in sequence and I change the value of an unrelated VI control while the VI is running (in a While loop), the function generates an error as if it was called by LabVIEW assuming the function w
as thread safe. This behavior is very repeatible.
If I enforce both instances of the same function to be called in sequence (by wiring the output value of the 1st function to the undocumented upper left input wire of the 2nd function), all problems are gone.
Normally I'd expect that changing a totally unrelated VI control (double) which also runs in the UI thread may have no influence at all, but running the VI indicates otherwise. I tried to reproduce the problem based on a simple example, but I'm unable to obtain the same effect.
Is there anyone out there who can comment on the behavior I described ?
Thanks.Jeremy,
thanks for the confirmation with respect to the greyed out terminal. I
had to find out the meaning of "being right on the money about
something", so thanks for extending my knowledge of the English
language too ... 8-)
Please find the LabVIEW code in attachment. It uses a HP836xx LabVIEW
instrument driver (controlling an RF source) and also calls a C API to
have work done in Mathematica (www.wolfram.com) using MathLink. We
know that the functions which communicate with Mathematica are not
thread safe, so all function calls are set to "Run in UI Thread".
If you look at the block diagram, you find the return value of
LSNAgetEquiTimeStamps() connected to both the greyed out input
terminals of both LSNAgetTimeData().
The VI runs fine, setting the source and collecting data, until I
change the "Power(dBm)" control value. After a few changes, the C API
indicates that the packages which are exchanged with Mathematica are
"out of sequence". The same happens immediately if I indicate that the
functions are thread-safe, by specifying them to be re-entrant. So I
tend to conclude that one way or another the 2nd LSNAgetTimeData() is
executed before the 1st one has finished.
If I eliminate the wire connecting the return value of
LSNAsetEquiTimeStamps() to the lower LSNAgetTimeDat () input terminal
and connect the return value of the upper LSNAgetTimeData() to the
greyed out input terminal of the lower LSNAgetTimeData(), everything
works fine. I can change the value of the "Power(dBm)" control "a
volonte". This is consistent with my assumption above: by changing the
wires I forced the 2nd LSNAgetTimeData() to wait for all inputs to be
available. Because one input is provided by the 1st LSNAgetTimeData(),
I'm sure this one has completed before the 2nd one is invoked.
I cannot explain what is happening. According to the manual, all code
linked to each function node should complete before code linked to
another function node is executed. However, I think I've read
somewhere on the NI website that the UI consists of two threads and
perhaps something goes wrong (internally in LabVIEW ?) when the UI
thread is informed about the fact that the "Power (dBm)" control has
changed.
I don't claim LabVIEW is to blame ... FYI ... the version I'm using is
(the evaluation version) of LabVIEW 7 Express.
Thanks.
Frans.
Attachments:
836xx_LSNA_example_v2.vi 99 KB -
Passing Variant to dll using call library function node
Hi,
Using LV2012
I have a dll that the following prototype:
SetTestResult(LPCTSTR Serial, int Test, int Result, VARIANT measuredValue);
How can I pass the Variant to this node when my variant can be either int or float.
I have tried "ToVariant" function but it is not sending data and gets error 1517 on LabView. For configuration parameters for variant I have used ActiveX type and datatype as activeX Variant Pointer.
So for call library function node my prototype looks like this:
int32_t SetTestResult(CStr Serial, int32_t Test, int32_t Result, VARIANT *measuredValue);
Can someone help me understanding What am I doing wrong here please?
Thank you,
Hiren
Hiren PatelHello Hiren,
Posting your code (even without the DLL) would definitely make it easier for people to point out potential issues. Here is an example that demonstrates passing an ActiveX variant to a DLL built in CVI, I would suggest cross-checking the way the Call Library Function Node has been configured.
Example:Transferring an ActiveX Reference Pointer to a CVI DLL
http://zone.ni.com/devzone/cda/epd/p/id/3343
Regards,
Tom L. -
Hi, I'm trying to use a .DLL I wrote in Visual C++ .NET. The Call Library Function generates a function prototype of "CStr Parser(CStr arg_raw)"
but my compiler won't accept this. So I change it to how C normally deals with strings "char *Parser(char *arg_raw). Now the Call Librafy Function does not find "Parser" in my .DLL though it is definitely there!
Help!
-FongHello
You will need to include extcode.h in your C file. You can find this under ..\LabVIEW\cintools folder.
The include has all the defines you will need.
Bilal Durrani
NI
Bilal Durrani
NI
Maybe you are looking for
-
How can I make Mozilla Firefox Start Page use Google search instead of SearchCompletion search?
I have just upgraded Firefox 9 to 10. I noticed when I fire up Firefox at the Start Page and enter a query at the search bar, the resulting pages are from SearchCompletion engine. How do I make Google search engine as the default engine at the Firefo
-
I Can't Access my Creative Cloud account on my Desktop.
I frequently use AE Premiere Pro, photoshop, and many other Creative Cloud apps. I used to get these messages that would pop up in the upper right hand of my screen saying that it "couldn't sync with creative cloud" or that it "couldn't log in". I di
-
am creating a document with Pages. all pages using "portrait" orientation, except 2 appendices need to be in "landscape". in Word for Windows it is possible to have different page orientations for different sections of a document. is that possible
-
SAVE: still having to click twice
1. load 10.6.1 onto Macbook Pro 2. go to www.wikipedia.com 3. find an article 4. save as .PDF format 5. document will default to correct name, and 10.6.1 will ask you where to save. 6. click save. dialogue should disappear 7. instead - it represents
-
Hi. I have a Macbook Pro running Leopard and Vista. Is it safe to install Vista SP1 in Boot Camp 2.0? I haven't heard of too many issues, but just making sure it wasn't going to break anything. Thanks.