Passing data between Java class and LabView dll

[Andy]

I'm fairly new to LabView (and Java for that matter), but I'm trying
to use JNI to link some Java to a LabView application (that is call a
LabView vi from a Java class).

As a test I've started with ye olde Hello World test, but I'm really
struggling (i.e. completely failing) to pass data (eg strings, arrays)
to and from my LabView vi. All I've succeded in so far is loading the
dll, opening the vi front panel, and returning an integer. If I send
an integer its value seems to be ignored (a pointer to the wrong
thing?), but if I try to return a string the program crashes... I
guess my problems lie in the settings when building the dll, but can't
find any that work!

In case I'm going wrong elsewhere, the Java method declar
ation for one
vi which (is supposed to) take an integer and return it plus pi) is:
public native double hello(int test);

Can anyone help?

Thanks,

Andy

[Dennis_Knutson]

I don't use Java but the function prototype for a LabVIEW dll with a I8 input and dbl output is "void Hello(int8 input, float64 *output)". If this isn't similar to what was defined when you created the dll, then you created it incorrectly. A LabVIEW output must be defined on the connector and added as a parameter in the dll and is not the return value.

[Randy_H]

Andy,

The best source we have on our web site is this KnowledgeBase.

Have you had any progress in this matter? If not, can you post your VI and Java code and we can see what we can do.

Randy Hoskin
Applications Engineer
National Instruments
http://www.ni.com/ask

[Andy]

> Have you had any progress in this matter? If not, can you post your VI
> and Java code and we can see what we can do.
>
> Randy Hoskin

Some progress thanks - I located a jar called jniwrapper that
simplifies Java jni calls. I've used this with some success, e.g the
following code simply loads testlib.dll and calls its 'hello'
function. This simply takes an integer and multiplies it by pi,
returning the result:

// function prototype: float64 __cdecl hello(int32 Numeric)
// load dll
Library firstTest = new Library("testLib");
Function piMultiplier = firstTest.getFunction("hello");
piMultiplier.setCallingConvention(Function.CDECL_CALLING_CONVENTION);

// define parameters
Int32 sendNumber = new Int32(5
);
DoubleFloat returnNumber = new DoubleFloat();

// call vi in dll
piMultiplier.invoke(returnNumber, sendNumber);
// print result
System.out.println("After: " + returnNumber);

Quite simple really. Now I've come across a bigger problem - I'd like
to make some calls to an instrument using LabVIEW VIs, but these need
the VISA resource name wiring through. If I want to take the name
back into my Java to pass into LabVIEW at a later stage I need to
create a pointer to LVRefNum. I have no idea how to do this - what
exactly is a LVRefNum? Is it time to give up?!

Thanks,

Andy

[Greg_McKaskle2]

....
> Quite simple really. Now I've come across a bigger problem - I'd like
> to make some calls to an instrument using LabVIEW VIs, but these need
> the VISA resource name wiring through. If I want to take the name
> back into my Java to pass into LabVIEW at a later stage I need to
> create a pointer to LVRefNum. I have no idea how to do this - what
> exactly is a LVRefNum? Is it time to give up?!
>

When you are dealing with opaque types, like the LV refnum, it is OK to
use an equivalent type that is the same size. At the simplest, least
safe side, you can just use an integer. It will be safer from the Java
side if you can use an opaque type that doesn't allow arithmetic, but
any of these can be made to work.

Greg McKaskle

[Andy]

Greg McKaskle wrote in message
>
> When you are dealing with opaque types, like the LV refnum, it is OK to
> use an equivalent type that is the same size. At the simplest, least
> safe side, you can just use an integer. It will be safer from the Java
> side if you can use an opaque type that doesn't allow arithmetic, but
> any of these can be made to work.
>
> Greg McKaskle

Sorry to be a bit thick, but what exactly do I need to do?! The
function prototype in my dll is:

void __cdecl VisaTest(LVRefNum *VISAResourceName);

Since a LVRefNum is the resouce name with some extra info wrapped
around it (I think) won't it be bigger than an integer? I tried
sending a pointer to an integer and got a memory access err
or! Do I
need instead to extract the integer representing the name from the
VISA resource name in LabView, return that to Java and send it into
the next VI, where it's converted back to a VISA resource name?

Thanks for the help,

Andy.

[Greg_McKaskle2]

> Sorry to be a bit thick, but what exactly do I need to do?! The
> function prototype in my dll is:
>
> void __cdecl VisaTest(LVRefNum *VISAResourceName);
>

No need to apologize, I just didn't know how much detail to go into.
A LVRefNum is just four bytes. It looks like this test function returns
you a refnum in the variable VISAResourceName. When I was telling you
that you could just use an integer, I wasn't aware that LVRefNum is
defined in extcode.h. There it pretty much tells you that it is a
Private reference.

I'm not sure if there is anyway to reuse extcode.h, probably not, but
you could easily make an equivalent definition. Something like...

typedef LVRefNum int;
LVRefNum visaRef;
VisaTest(&visaRef);
Nex
tFunction in DLL(visaRef);
OR
NextFunction in DLL(&visaRef);

If the NextFunction can modify the visaRef, it will need to be given a
reference to the value. If it only looks at the value, the first on
will work. At this point, the compiler will help keep you honest as the
functions will either take a LVRefNum* or an LVRefNum.


> Since a LVRefNum is the resouce name with some extra info wrapped
> around it (I think) won't it be bigger than an integer? I tried
> sending a pointer to an integer and got a memory access error! Do I
> need instead to extract the integer representing the name from the
> VISA resource name in LabView, return that to Java and send it into
> the next VI, where it's converted back to a VISA resource name?
>


I'm sorry I can't help much with the brewing of the JAVA code, but a
LVRefNum is just four bytes, and you won't get a memory access error
unless you try to dereference the refnum. It isn't a TRUE pointer, but
a synthetic pointer that LV can use
to do some checking and associate it
with your VIs.

Hope this helps.
Greg McKaskle