Gopel boundary scan DLL

[Bjarne Joergensen]

Hi

 

I have a problem getting variable form Göpel Boundary Scan DLL.

All my SW works fine except when I want to get a variable from the DLL.

The documentation from Göpel is here:

 

 

My LV(8.2.1) has this setup.

 

 

 

 

 

 

 

 

 

Am I doing something wrong?

 

Thanks in advance

 

/Bjarne Jørgensen

 

[Rolf Kalbermatter]

Hi

 

I have a problem getting variable form Göpel Boundary Scan DLL.

All my SW works fine except when I want to get a variable from the DLL.

The documentation from Göpel is here:

 

Well the information is not really enough to make conclusive statements here but two or three things make me wonder a bit.

 

In the description it says "Pointer to the handle of the tCascon structure ...." so I'm wondiering if this parameter should be passed by reference. But the C++ prototype doesn't look like it should.

 

Are you sure the function is stdcall? The CASRUNFUNC might be specifying the calling convention but without seeing the headers it is impossible to say. If it doesn't specify it it will depend on the compiler switch used to compile the DLL but if nothing is specified and the CASRUNFUNC doesn't specify an explicit calling convention it is normally always cdecl.

 

Last but not least, what does not work? What do you get? A crash, an error return code, no info?

[Bjarne Joergensen]

Thank you ROLFK

 

 

 

All the other calls to the DLL is stdcall so I assume that this also has to be.

I only get "0" back as an answer. No crash - no error return code!

 

If I don't add an input at "buf" the vi will crash. I have trid with an 32 integer instead og an array, and bCnt =4, but got the same result ="0". I expect "31"

 

regards Bjarne

Edited May 13, 2013 by Bjarne Joergensen

[Rolf Kalbermatter]

Thank you ROLFK

 

 

 

All the other calls to the DLL is stdcall so I assume that this also has to be.

I only get "0" back as an answer. No crash - no error return code!

 

If I don't add an input at "buf" the vi will crash. I have trid with an 32 integer instead og an array, and bCnt =4, but got the same result ="0". I expect "31"

 

regards Bjarne

 

 

That shouldn't make any difference. A buffer of four bytes with bCnt = 4 is absolutely equivalent to an int32 passed by reference with bCnt = 4. The DLL function has absolutely no way to see a difference there.

 

The only thing that remains would be what the aVarId value needs to be. The description is totally cryptic and might be a very good candidate to have understood wrong.

[Naity]

The only thing that remains would be what the aVarId value needs to be. The description is totally cryptic and might be a very good candidate to have understood wrong.

 

Yes, it might be that. As I understand the document, it might be a char*

 

The "it begin with v" lead to think that the aVarID could be a string.

 

Cheers

 

EDIT: I did not read carefuly the function prototype at the beginning of the post. It might also as well not be that.

Edited May 22, 2013 by Naity

[JamesMc86]

 The "it begin with v" lead to think that the aVarID could be a string

I expect it is an enum somewhere in the header, certainly worth checking. Can you do something to force it to return an error e.g. Intentionally give an invalid variable so it returns non zero? Just to confirm there is life on the otherside! Also read the error terminals on the node in LabVIEW.

[Bjarne Joergensen]

HiDoes anyone know the value of other looking at your code?I just realised that I must become blind for the difference between g and s!I have used my set variable reference instead of my get variable reference ?So now my code is working ?Thanks for the help everyone and specially my colleagues ?regards Bjarne