Can LabVIEW make use of an OCX (ActiveX) "Pointer to Array"?

[Mang]

Hi,
How about the problem now? I have the same problem. I am also using pleora iport.
Coud you kindly provide some example of iport using in Labview?

[WNM]

I never did get this working with a DLL. Igor Sales (email: igors@pleora.com) a software developer at Pleora was working to provide a DLL which LabVIEW could interface to but it's been a while since I have heard from him about the effort. It may help if he knows that others are interested.

I do have a 100% ActiveX LabVIEW/iPort/camera interface for a Pulnix camera we are using that I'll attach. It doesn't do streaming video because of the ActiveX "safedata" array bottleneck that this forum thread was all about, it it will grab & display camera images and change camera settings through the iPort interface.

Drop Igor a note to tell him you too are interested in more complete LabVIEW support for the iPort and good luck with your application!

[Mang]

Thank you for your useful information!
In my view, there are two main factors influence acquisition and display performance, one is "variant to data", another is to covert the array data to NI-IMAQ image format. The attachment file is the iPORT sample program, I just changed it a little to convert the array to NI-IMAQ format. But I'm not sure if it is helpful for you.

[Mang]

The file upload failed, So I upload it again

[rolfk]

---

@Warren Massey wrote:
FWIW, I have tried putting together a simple DLL which will take:
1) a pointer to an I16 array #1
2) the length of array #1
3) an I16 array #2
and it will move all the values from array #1 to array #2.
That is it will do it if the #1 array is also a LabVIEW array
(I get its pointer with another call to another simple routine in the DLL).

Unfortunately it won't work if I use the array pointer I get from the "LockForReadPtr" method. When the CIN executes, I get a message about something nasty having happened within the DLL and LabVIEW will be crashing as soon as I say it's OK to do so.

I'm running out of ideas...

---

If your Node returns an (u)int32 as pointer take a look at this post: http://forums.ni.com/ni/board/message?board.id=170&message.id=123468#M123468. It shows a way of getting the data from a pointer into a LabVIEW array/string.

Rolf Kalbermatter

[WNM]

---

@Mang wrote:
Thank you for your useful information!
In my view, there are two main factors influence acquisition and display performance, one is "variant to data", another is to covert the array data to NI-IMAQ image format. The attachment file is the iPORT sample program, I just changed it a little to convert the array to NI-IMAQ format. But I'm not sure if it is helpful for you.

---

Thanks, but I do not believe there is anything new here for me. I too, in my production version of the code, am using the IMAQ image format since I have the NI Vision toolkit add-on. I greatly simplified that version to eliminate IMAQ and use the more generic picture control data since most people would not have the rather expensive Vision add-on. I didn't see much noticable difference in performance between the two versions. The real "bottleneck", which is present in both versions, happens during the "variant to data" conversion since it involves copying all the image data from the ActiveX "safearray".

[WNM]

---

If your Node returns an (u)int32 as pointer take a look at this post: http://forums.ni.com/ni/board/message?board.id=170&message.id=123468#M123468. It shows a way of getting the data from a pointer into a LabVIEW array/string.
Rolf Kalbermatter

---

OK, I looked at that thread and have three questions.

1) Will this method work if the source array is not in the same memory space as the destination array?
More details on this aspect of the problem are in other posts in this thread, especially the one by Scott Y posted on 03-24-2005 04:50 PM.

2) Will this method accept other array data types? I have U8 rather than DBL data in my array.

3) Is the MoveBlock function documented anywhere?

[rolfk]

1) No! However if this pointer is really in a different memory space, that ActiveX method makes no sense at all. A C/C++ program also wouldn't have any simple means to access that pointer either if the ActiveX component would be instantiated as a separate process instead of in the calling process.

2) A pointer is a pointer! No matter what it points to. Just make sure that you adjust the length parameter from numElement * 8 to numElement * 2 for an uInt16 array for instance, or in your case simply numElements.

3) Check out in LabVIEW Help->Search the LabVIEW Bookshelf->Using External Code and there Chapter 6 Function Description.

Rolf Kalbermatter

Message Edited by rolfk on 06-03-2005 12:15 PM

[Mang]

I emailed to Igor, they are still working on new features of the SDK, one in particular is a set of C
DLLs instead of C++ DLLs. Compatibility of C DLLs with software such as LabView, Delphi,and Borland C
will be much more straightforward, since LabView does not accept calls to C++ DLLs. But currently they do not have a hard release date defined yet for this new SDK.

If you know some progress, pls letme know. lizhimang@ksbpm.com.cn

[WNM]

---

@Mang wrote:
I emailed to Igor, they are still working on new features of the SDK, one in particular is a set of C
DLLs instead of C++ DLLs. Compatibility of C DLLs with software such as LabView, Delphi,and Borland C
will be much more straightforward, since LabView does not accept calls to C++ DLLs. But currently they do not have a hard release date defined yet for this new SDK.

If you know some progress, pls letme know. lizhimang@ksbpm.com.cn

---

I just recently had cause to wonder if Pleora had finished this task so I wrote asking about it.
This is what Igor said:

"The SDK 2.2 was released at the end of last year [2005], and it can be downloaded
from  http://www.pleora.net/customer

You will need to download file: pleora 2.2.0 build 42.zip

All the C++ libraries now include pure C versions of the functions
so they can be called from environments such as LabView or Borland C."