LabVIEW
vxworks: LabView LStrHandle structure
Solved!
Hi all!
I want to receive a cluster from vxworks to LabView.
Is it possible only when Cluster->String initialized?
It is seems code "c->s = (LStrHandle)malloc(sizeof(void*));" is incomplete. LabView requires something else. But what does LabView require?
CODE:
#include <string.h>
#include <assert.h>
#include <stdlib.h>
typedef unsigned long int32;
typedef char Char;
/* Long Pascal-style string types. */
typedef struct {
int32 cnt; /* number of bytes that follow */
Char str[1]; /* cnt bytes */
} LStr, *LStrPtr, **LStrHandle;
typedef struct
{
LStrHandle s;
} Cluster;
extern "C" void changeStr(Cluster * c, LStrHandle lvs)
{
// does not work
c->s = (LStrHandle)malloc(sizeof(void*));
*c->s = (LStrPtr)malloc(10);
(*c->s)->cnt=3;
strcpy((*c->s)->str,"bad");
// works
*lvs = (LStrPtr)malloc(10);
(*lvs)->cnt=6;
strcpy((*lvs)->str,"works!");
return;
}
Your problem is trivial and shows a certain lack of C programming knowledge.
Take this prototype:
MgErr MyFuncPassByValue(LStrHandle lstr);
There is no way LabVIEW can pass a NULL handle into the function if the function has to be able to return a valid handle since only parameters passed by reference can be returned. So LabVIEW allocates an empty handle (a handle pointing to a memory area that contains the array dimension size 0, but no other data) and passes that to the function. The C function can now resize the handle as needed and return information.
MgErr MyFuncPassByReference(LStrHandle *plstr);
Now the handle is passed by reference and LabVIEW can and will pass a NULL handle to the function if it is empty, since it internally does use NULL handles for empty arrays and strings to save both on memory and performance as allocating an empty handle requires almost as much CPU than allocating a large one and also adds to memory defragmentation.
A handle embedded in a cluster is technically also passed by reference and therefore LabVIEW will not do any extra work and simply pass the NULL handle to the function too.
And your use of malloc to allocate a LabVIEW handle is simply outright wrong. malloc allocates a C runtime memory block not a LabVIEW handle. In order for LabVIEW to be able to work with the handles you MUST use LabVIEW memory manager functions as described in the External Code Reference manual whenever you allocate, reallocate, resize or deallocate LabVIEW handles and pointers.
kolan wrote:
In other words, is there any way to implement NumericArrayResize function on vxworks?
Why do you want to implement NumericArrayResize on vxWorks? This function is provided by the LabVIEW runtime kernel and you can simply call it from your own C code.
No I'm not only a Windows user although I mainly develop on Windows. I have written libraries such as the OpenG lvzip library that is multiplatform and incidentially even ported it to the vxWorks environment. Although I had not a CompactRIO system available to test it myself I have reports from users that it does indeed work. One C module in lvzip does use LabVIEW manager functions although not NumericArrayResize(), so I know that simply by making the correct Makefile for the VxWorks gcc compiler one can create a shared library that compiles and runs on VxWorks while using LabVIEW runtime functions.
I have installed LabWindwos CVI but not 9.0 and also not LabVIEW 2009 yet since I use this computer for active project development and can't risk destroying my existing and fully working LabVIEW 7.1.1, 8.2.1, 8.5.1 and 8.6.1 versions on this machine.
The implementation of arrresize.c you show is not availalbe on my computer but just because it is there like that does not mean that it has to be buggy. The CCodeGen part in LabVIEW was up until now limited to use for Embedded targets. VxWorks on CompactRIO is in that sense not an embedded target but a realtime target. NI has created a runtime kernel for those targets that is much more similar to the desktop runtime systems than what an embedded target ever could be.It doesn't surprise me that they to not install the full source code to the actual runtime kernel for their embedded targets but only a slimmed down version for the needs they do have on those systems.
Maybe CompactRIO in LabVIEW 2009 is treated indeed entirely different than in previous versions rather as an embedded target than a realtime target but I somehow doubt that since I have it from NI support that nothing has changed in terms of VxWorks support for their realtime target between LabVIEW 8.6 and 2009 when inquiring if users might have to expect troubles when using the lvzip library in this version on CompatRIO and other NI PPC realtime targets.
