Accessing DLL buffer data after receiving Windows Message

[nathand]

Just to be clear, you shouldn't need to write a CIN.  I think you can make this work with just three additional DLL calls.  The functions you need to call are provided for writing CINs but work fine when called directly from the LabVIEW environment.

[rolfk]

---

nathand wrote: 

I think you can do what you want by calling DSNewPtr to get your block of memory.  This will return a pointer that you can pass to SetDecodeBuffer.  Then, when you need to retrieve the data from that pointer, call MoveBlock.  The source is your pointer and the destination should be a LabVIEW array.  When your code terminates, call DSDisposePtr to release the memory for the buffer.

---

This is indeed how this should be tackled properly. My answer from the other related thread is a somewhat more quick and dirty solution. You can make LabVIEW keep an array or string in memory for as long as the according wire is running through the diagram. This would basically remove the need for the DSNewPtr and DSDisposePtr calls (But the MoveBlock or similar call still is required). However such a diagram is fairly unintuitive for the unsuspecting viewer so above solution is indeed the prefered, although somewhat more low level way.

And as nathan already said there is no need to go to CIN or external DLL creation for this. The Call Library Node is able to call those LabVIEW manager calls directly that the CIN Code Reference manual documents, (although this is not really documented in the manual, but manifold in discussion threads including by NI people themselves).

[Anil_Reddy]

Hi Nathan,

I did as you mentioned in the post. I have a question, Do we need to take any special care while handling these memory management functions??? Why I am asking this is because LabVIEW freezes as soon as i start using these functions. I mean not jsu when i run my application. But frequently after using these functions

One more issue is....I am getting different data on each run though I am requesting the sam einformation from the device. There is no problem from device end. It works properly when i run VC++ example. I am i missing something in creation of the buffer? or copy of the buffer

Thanks

Anil

Message Edited by Anil Reddy on 12-14-2009 10:56 AM

[nathand]

Is it possible you have the parameters to MoveBlock in the wrong order (perhaps source and destination are backwards)?  That could cause unreliable behavior, and might also explain the inconsistent data you're receiving.  You do need to take care using those memory management functions, since you're asking LabVIEW to act more like C.  Can you post your code?  Do you have a simple test VI that only interacts with the scanner and does nothing else?

[rolfk]

There is nothing that is special to calling these functions. Since you seem to be able to call it sometimes I do not suspect it to be the calling convention, which for all LabVIEW manager functions is cdecl instead of stdcall.

The fact that you do get different information for each call makes me believe that you did somehow something wrong however. Also the fact that it sometimes freezez might stem from when you allocate a to small memory block.

Show us your code and we can stop guessing and start pointing to possible problems.

[Anil_Reddy]

Hi,

Please find attached ZIP file. It has SSIDLL.dll and the test VI...

Thanks

Anil

[nathand]

Are you on a 64-bit system?  Check that your pointer sizes agree.  If you're on a 32-bit system, you should set the return type of DSNewPtr to be a 32-bit integer.  Right now it seems to be returning a 64-bit value, which you're then passing to SetParameterBuffer (which probably expects a 32-bit value).  Avoid using "Adapt to Type" for your pointer parameters, since you know the type of the data; make sure to pass them by reference.

Also, I note that Symbol's web site indicates there's an ActiveX component, and maybe a serial interface, available to control this scanner.  While I think you can get this working with the right DLL calls, is it possible one of those approaches would be easier?

[Anil_Reddy]

I tried using that ActiveX, but it doesnt work with LabVIEW. and the Technical Support people say that the ActiveX works with VB only. We have Serial Interface for this scanner, but we need to work using SSI protocol to communicate with this device..........

Thanks

[rolfk]

---

nathand wrote:

Are you on a 64-bit system?  Check that your pointer sizes agree.  If you're on a 32-bit system, you should set the return type of DSNewPtr to be a 32-bit integer.  Right now it seems to be returning a 64-bit value, which you're then passing to SetParameterBuffer (which probably expects a 32-bit value).  Avoid using "Adapt to Type" for your pointer parameters, since you know the type of the data; make sure to pass them by reference.

Also, I note that Symbol's web site indicates there's an ActiveX component, and maybe a serial interface, available to control this scanner.  While I think you can get this working with the right DLL calls, is it possible one of those approaches would be easier?

---

First I don't have LV 2009 installed on my computer so can't look at the VI.

Second since LabVIEW 8.6 or so pointers should be configured as pointer sized integers so that the whole 32/64bit issue is handled automatically. they will be 64 bit integers on the diagram but the Call Library Node will access the right 32 bit on 32 Bit platforms in all cases.

SetParameterBuffer() should get the returned parameter from DSNewPtr() passed by value, not by reference. The char * dataype is a pointer as is the value returned from DSNewPtr() albeit this function will return void *, but that is for our purposes irrelevant.

For the rest I can't say much without having seen the VI.

[Anil_Reddy]

Hi Rolf,

Here is the VI in 8.6...

Thanks

Message Edited by Anil Reddy on 12-14-2009 02:35 PM