Jump to content

Gopel boundary scan DLL


Recommended Posts

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?

Link to comment

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 by Bjarne Joergensen
Link to comment
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.

Link to comment
  • 2 weeks later...
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 by Naity
Link to comment
 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.
Link to comment
  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.