LabVIEW error cluster/structure issues on RHE linux 4

[labwhat]

For all you LabVIEW Linux users,

Anyone encountered problems using the standard error-in and error-out of LabVIEW on linux?

I build a .so file using the LV project explorer and a C program referencing the functions build in the shared library.  Code compiles but when executed I get a labview error when the cnt != 0.  cnt is part of the LV error cluster which consist of status (int), code (int), and description (struct Lstr).  The description is broken down into a struct of an int cnt and a char[ ] str.  I am confused on the reason for this struct and for the error when cnt !=0.

Thanks

[griffindore]

Hi labwhat,

From Using Error Clusters in the LabVIEW Help, "Use the error in and error out clusters in each VI you use or build to pass the error information through the VI. In most cases, source also identifies where the error occurred." The error cluster contains three values, status (Boolean), code (I32), and source (string). It sounds like you are mapping a LabVIEW Boolean to a C int and a LabVIEW string to a C struct of int and char[]. How the error cluster works is that if an error occurs, the "status" is set to True, an error code will be written to "code", and a string explaining the origin of the error is written to "source". If source contains a string in your char[], it is likely that cnt contains the number of characters within the char[]. It sounds like the error is not caused by cnt != 0, but rather the error is setting cnt to something other than 0. In short, it sounds like your program is returning an error and that the error cluster is working properly. I hope this clarifies things!

[labwhat]

lion-o,

The program I created errors when referencing a vi/function where the errorin is wired to the errorout (no other logic is included in this vi/function), in this case I should not be getting any errors.  As previously mentioned in order to avoid this error I would need to initialize the cnt = 0 for the errorin struct.  When setting cnt =0 (for the errorin) the errorout returns a cnt = 0 thus the char [ ] = null.  So when I try to initialize the errorin to generate an error with cnt = total # char in the char [ ], I run into a LabVIEW error: "MemoryManager.cpp line 406".  This error is generated when I try to initialize the errorin in which the cnt !=0.

The following is the struct for the LV error description:

typedef struct {
 int32 cnt;  /* number of bytes that follow */
 uChar str[1];  /* cnt bytes */
} LStr, *LStrPtr, **LStrHandle;

What I dont understand is why the char [ ] only contains 2 elements.  Also the comments for both the cnt and str are not clear.

-r

[rolfk]

---

labwhat wrote:

lion-o,

The program I created errors when referencing a vi/function where the errorin is wired to the errorout (no other logic is included in this vi/function), in this case I should not be getting any errors.  As previously mentioned in order to avoid this error I would need to initialize the cnt = 0 for the errorin struct.  When setting cnt =0 (for the errorin) the errorout returns a cnt = 0 thus the char [ ] = null.  So when I try to initialize the errorin to generate an error with cnt = total # char in the char [ ], I run into a LabVIEW error: "MemoryManager.cpp line 406".  This error is generated when I try to initialize the errorin in which the cnt !=0.

The following is the struct for the LV error description:

typedef struct {
 int32 cnt;  /* number of bytes that follow */
 uChar str[1];  /* cnt bytes */
} LStr, *LStrPtr, **LStrHandle;

What I dont understand is why the char [ ] only contains 2 elements.  Also the comments for both the cnt and str are not clear

---

This is a native LabVIEW string handle. Do you try to export that like this to your C program? Then you really need to be very, very careful. LabVIEW uses it's own memory manager functions to manage it's handles. You can't just allocate some heap of memory somewhere using libc functions and pass that to LabVIEW as a string handle or even worse yet, try to resize such a string handle received from a LabVIEW VI (inside a shared lib) using libc functions to accomodate for new data to write in.

Also changing the cnt value in that structure does absolutely nothing in terms of the underlaying allocated memory. You first need to reallocate that memory handle using LabVIEWs DSSetHandleSize and similar memory manager functions in order to be able to fill in some data into the string part.

This all is very involved and without a through understanding of almost everything that is discussed in the External Code Reference Manual you are going to be in deep trouble. In general because of the need to use LabVIEW specific memory manager functions it is not a good idea to export the LabVIEW array and string handles as native datatype but instead make sure you export a more standard C friendly function prototype to your callers.

Rolf Kalbermatter