.dll configuration

[RONIN10]

Hey there,

I inhereted a .dll file from another group in my company to use to connect to a datastream which their data acquisition system creates. I have the source code for the .dll, however I have all of zero expertise in C syntax and can't tell if there are just superficial or meaningful differences in my prototype and the actual function statement within the source code. Here's my LabVIEW configuration:

and the function call within the source code is:

static int get_stream_item(int item, datastream_t *ds, int IDx, void *vp)

I had my local NI rep and another NI guy visiting from TX sit down with me and take a look at this together. It was beyond their certainty as to what was wrong, but they seemed to key in on the void pointer as being the likely culprit and (unfortunately) didn't have a solution in mind.

So when I go to run this, the node execute succesfully in that I get a zero return value (specified in the source code as successful completion of the function), but the I32 I'm wiring to the void pointer doesn't get populated with information I'm requesting (number of parameters in teh data stream, in this case). It also causes an Error 15 code in LabVIEW and crashes the whole application after hanging for a few seconds.

Any suggestions of ways to correct this and why it is behaving as it is? Thanks in advance!

[Rolf Kalbermatter]

QUOTE(RONIN10 @ Dec 7 2007, 04:34 PM)

Hey there,

I inhereted a .dll file from another group in my company to use to connect to a datastream which their data acquisition system creates. I have the source code for the .dll, however I have all of zero expertise in C syntax and can't tell if there are just superficial or meaningful differences in my prototype and the actual function statement within the source code. Here's my LabVIEW configuration:

and the function call within the source code is:

static int get_stream_item(int item, datastream_t *ds, int IDx, void *vp)

I had my local NI rep and another NI guy visiting from TX sit down with me and take a look at this together. It was beyond their certainty as to what was wrong, but they seemed to key in on the void pointer as being the likely culprit and (unfortunately) didn't have a solution in mind.

So when I go to run this, the node execute succesfully in that I get a zero return value (specified in the source code as successful completion of the function), but the I32 I'm wiring to the void pointer doesn't get populated with information I'm requesting (number of parameters in teh data stream, in this case). It also causes an Error 15 code in LabVIEW and crashes the whole application after hanging for a few seconds.

Any suggestions of ways to correct this and why it is behaving as it is? Thanks in advance!

There are two things that could be wrong: datastream_t is not a standard C type so I'm not sure if treating it as an int32 is ok. If it is just a handle you get from some open function then it should be ok.

The void pointer quite likely is the culprit here. Unfortunately C is not a language that describes parameters in itself sufficiently in terms of the exact meaning and context of their use. void pointers are especially bad in that respect as they can be really anything you can think of. What it is can only be decided by knowing the exact context of that function, which you didn't give in any way.

It could be a byte buffer in which the function is supposed to write the data from the stream. In that case the caller (your LabVIEW diagram) needs to allocate that buffer. As the function has no parameter to tell the size of that buffer and therefore you would need to know that size before calling that function I can only think of a few possibilities:

- The function works with a fixed size buffer always.

- You can pass in a NULL pointer and get the needed size as return value of the func'tion to allocate that buffer and call the same function again.

- There is another function that can tell you what size is required.

These things can not be deducted from the function prototype you show but only from the source code, a possible code example or the function description in some programmer manual to the library.

Another possibility is that the function allocates the buffer itself and returns a pointer to it in the void parameter. In that case you would need the exact structure of that buffer and hope it is a flat buffer. Retrieving non flat data (pointers inside that buffer) in such a way is a mature pain and for me ALWAYS a reason to write a wrapper DLL or in your case since you have the DLL source code an additional more LabVIEW friendly exported function.

Also since the DLL allocated the buffer it should provide you with a function to deallocate it later on after you don't need it anymore as otherwise you are creating memory leaks.

All in all there is way to little information available to tell you what exactly goes wrong and even less to give you detailed ideas about how to do it correctly. And that is not LabVIEWs fault but the nature of C which does not fully document the parameter datatypes of functions in general und the exact usage context in special.

Rolf Kalbermatter

[RONIN10]

Forgot to enable notification so I'm just getting back to this. I apologize for that.

QUOTE(rolfk @ Dec 8 2007, 05:45 AM)

There are two things that could be wrong: datastream_t is not a standard C type so I'm not sure if treating it as an int32 is ok. If it is just a handle you get from some open function then it should be ok.

Feeding datastream_t with an int32 is working fine. Throughout the library I've made prior calls (prototyped similarly as regards to datastream_t) to other functions and it has worked out all right. I'm confident in the ability to handle that portion of the code. In fact, this chunk executes just fine, passing through the already established DataStream_ID successfully.

QUOTE

The void pointer quite likely is the culprit here.

I'm starting to hear that from numerous sources.

QUOTE

void pointers are especially bad in that respect as they can be really anything you can think of. What it is can only be decided by knowing the exact context of that function, which you didn't give in any way.

I apologize for that, but this is a proprietary code (despite the individual function's simplicity) and I'm only able to superficially describe the code. I cannot actually post the exact code. In that vein, this function call is made to determine the number of parameters in the established datastream. It should be returning an integer.

QUOTE

These things can not be deducted from the function prototype you show but only from the source code, a possible code example or the function description in some programmer manual to the library.

Big company + employees at two different locations with two different bosses = the developers binning my troubles with their code as not a priority. As such, I'm not getting too much support from the originators of this code. They have their own worries to consider. Lucky me.

QUOTE

Another possibility is that the function allocates the buffer itself and returns a pointer to it in the void parameter. In that case you would need the exact structure of that buffer and hope it is a flat buffer. Retrieving non flat data (pointers inside that buffer) in such a way is a mature pain and for me ALWAYS a reason to write a wrapper DLL or in your case since you have the DLL source code an additional more LabVIEW friendly exported function. Also since the DLL allocated the buffer it should provide you with a function to deallocate it later on after you don't need it anymore as otherwise you are creating memory leaks.

This has my head spinning. I don't know that I've really added much more context to the problem description, but I'll run your thoughts by the C code developers and see what their thoughts are on the concerns you've raised. Of course, that'll happen whenever I can pin them down to discuss this.

QUOTE

All in all there is way to little information available to tell you what exactly goes wrong and even less to give you detailed ideas about how to do it correctly.

That's what I was afraid of. That my limited ability to show you what the function(s) does would prevent me from actually being able to narrow in on a solution.

Still, I greatly appreciate you taking the time to consider this. If any other ideas pop up in yours (or anyone else's minds), I'd love to hear them. Thanks!

[Rolf Kalbermatter]

QUOTE(RONIN10 @ Dec 11 2007, 04:03 PM)

I apologize for that, but this is a proprietary code (despite the individual function's simplicity) and I'm only able to superficially describe the code. I cannot actually post the exact code. In that vein, this function call is made to determine the number of parameters in the established datastream. It should be returning an integer.

If it is really just an integer that is returned it's very trivial. Configure the parameter to be an int32 or whatever integer you expect and also tell it to pass that parameter as Pointer to Value (contrary to as Value). That should take care of your problem.

Rolf Kalbermatter

[RONIN10]

QUOTE(rolfk @ Dec 12 2007, 12:49 AM)

If it is really just an integer that is returned it's very trivial. Configure the parameter to be an int32 or whatever integer you expect and also tell it to pass that parameter as Pointer to Value (contrary to as Value). That should take care of your problem.

Right. I have it configured that way now and I'm still hanging the code. Here's my prototype as it exists now: long get_stream_item(long Item, long *DataStream_ID, long Stream_Index, long *Data_Pointer);QUOTE(rolfk @ Dec 12 2007, 12:49 AM)

If it is really just an integer that is returned it's very trivial. Configure the parameter to be an int32 or whatever integer you expect and also tell it to pass that parameter as Pointer to Value (contrary to as Value). That should take care of your problem.

Right. I have it configured that way now and I'm still hanging the code. Here's my prototype as it exists now: long get_stream_item(long Item, long *DataStream_ID, long Stream_Index, long *Data_Pointer);

[RONIN10]

QUOTE(rolfk @ Dec 12 2007, 12:49 AM)

If it is really just an integer that is returned it's very trivial. Configure the parameter to be an int32 or whatever integer you expect and also tell it to pass that parameter as Pointer to Value (contrary to as Value). That should take care of your problem.

Right. I have it configured that way now and I'm still hanging the code. Here's my prototype as it exists now:

QUOTE

long get_stream_item(long Item, long *DataStream_ID, long Stream_Index, long *Data_Pointer);

Hmm. Not sure what happened with the double post...it cut me off.

Anyway, I did have the big ah-ha! moment before when I was having trouble and realized that I was sending the value itself and not a pointer to the value. I don't know if this will show up reasonably, but here's my http://i80.photobucket.com/albums/j173/ronin10/NoParams_BlockDiagram.jpg' target="_blank">block diagram.

[Rolf Kalbermatter]

QUOTE(RONIN10 @ Dec 12 2007, 11:03 AM)

Right. I have it configured that way now and I'm still hanging the code. Here's my prototype as it exists now:

Anyway, I did have the big ah-ha! moment before when I was having trouble and realized that I was sending the value itself and not a pointer to the value. I don't know if this will show up reasonably, but here's my http://i80.photobucket.com/albums/j173/ronin10/NoParams_BlockDiagram.jpg' target="_blank">block diagram.

Hmm if it is still crashing then something is not right. What, I really can't tell you from what you show so far. Without more details about the last parameter or some short C code excerpt showing how it is normally called my possibilities to help are completely exhausted.

Rolf Kalbermatter