bna08

This is what I am actually doing already. The question is if IMAQ Image pixels pointed to by the pointer obtained from IMAQ GetImagePixelPtr can be cast to a LabVIEW array.

I have an IMAQ image and I obtain the address of its pixels via IMAQ GetImagePixelPtr VI (see below). This address is passed to my .NET DLL which copies the pixel values to memory area starting at this address. Afterwards, I can access the IMAQ image directly in LabVIEW. However, I also want to access the image pixel values for direct processing. This could be achieved by calling IMAQ ImageToArray VI which is unfortunately quite slow (around 5-10ms on my 12-core Xeon CPU). Since we already have the pixel pointer address provided by GetImagePixelPtr VI, is there any way how this address could be cast directly to a LabVIEW array? Basically, I want to be able to convert (cast) this address to a LabVIEW array of UNS16: Is there any way how it could be done? I would like to avoid copying the values in any way which is what IMAQ ImageToArray does. EDIT: I am starting to realize that LabVIEW array is not really just a plain array of bytes/shorts etc. but a more complex data structure (holding the information about the array length etc.). Thus, simple C/C++ array pointer casting to a LabVIEW array is not possible. Am I correct?

Here is the cause and solution: Solved: Vertical synchronization when displaying video - NI Community

I have an IMAQ image in my application and when I try to write new pixel data to it and update it more frequently than approx. each 40ms, the image in the display is torn. If I am saving each image to the disk, it looks good. It's just slightly broken when an object is moving fast in the field of view. What I am doing is: Write pixel data (via pointer from IMAQ GetImagePixelPtr.vi) to the IMAQ image every 20-30ms. Immediately push (write) the IMAQ image with new pixel data to IMAQ Image control. Is there perhaps some kind of "native" refresh rate of 25fps (40ms) in the IMAQ image control that would interfere with me writing and displaying new image more frequently?

Sounds like a good idea, thanks!

I have multiple cases to be executed in a case structure as a result of user events in my application in a producer/consumer pattern. In one of the cases a new reference is created that I will only need once more in another case of the given case structure. All other cases have no need for that reference. However, if those other cases are invoked (e.g. Grab Frame, Stop Acquisition), a wire has to be dragged through the case from input shift register via case structure tunnels to output shift register so that it does not become invalid (Use Default If Unwired) and can be used once the case that actually needs the reference is invoked. This results in unnecessary wires (and often more of them) in other cases of the structure that pollute the diagram and have to be there just to carry the reference for any other case. Is there a way I could reduce this "pollution" and avoid dragging the wire through each case where it is not used at all? Here is an example: INIT VI generates a reference that I will need when calling the OPEN CAMERA VI so I pass it to next iterations via Shift Register: OPEN camera VI that requires the reference from INIT case: Other cases, such as Open Camera or Grab Frame have no need for this reference, yet it has to be dragged through these cases as well in order to pass the reference if I want to keep the reference value for future use: I could select Use Default If Unwired in these cases and not use the wire at all, however, that will set the reference value to null and I won't be able to use it anymore. Is there a way to solve this without dragging the wires in all cases of the structure?

Yes, uint64s. How do I get a 1D pointer of an array - do you mean pointer to a buffer created with DSNewPtr? And how does your parsing work? Where did you get the array? All I have is a pointer which I need to dereference with GetValueByPointer.xnode while you already have an array of uint64s which you split by 4 elements...? Sorry, I don't understand what you are doing.

Well, I was trying to keep things simple, so I omitted a "detail" where I am actually not passing just a single pointer into the DLL, but an array of pointers as my DLL is generating a few hundred bytes every 2ms that I need to have available in LabVIEW in a buffer of its own. mdAddress below is therefore an UInt64[] array. I pass the whole array of pointers to the DLL only once when the application starts - and then in every iteration of my DataGenerator method (e.g. DataGenerator::GenerateMetadata) a new set of metadata (e.g., eight different variables) is written to an mdAddress address. Basically, I am following the pattern of IMAQ GetImagePixelPtr.vi which I am using to get an array of image pointers (array of some complex data types) which I pass to .NET DLL which writes data to it. My example below with DSNewPtr follows the same logic, but instead of pixel array I am creating byte arrays and passit their pointers. After the DLL is done generating the data, I access them by dereferencing each pointer with GetValueByPointer.xnode (and since each pointer points to a buffer with multiple 64-bit variables, I add 8-byte offsets to the original pointer address to access the particular variable): I realize this is a pointer voodoo and would like to do it in a nicer way although at the moment I am happy I found a way how to make it work at all. Initially, I created an array of LabVIEW clusters which I wanted to pass to the .NET via an Invoke node, but passing array of clusters or clusters from LabVIEW to .NET is not possible if I am not mistaken. Therefore, I was looking for other ways how to get data from .NET DLL into the LabVIEW fast. Ultimately, I would like to use an array of clusters (structs) in LabVIEW, pass them into the .NET DLL and have the DLL write data to each cluster every 2ms.

I don't work with a DLL in C#. The DLL is in C++/CLI which allows working with managed and unmanaged data at the same time. Therefore, in this case I pass a 64-bit pointer to data buffer allocated with DSNewPtr (as suggested by ShaunR above) by calling one of the DLL functions as UInt64 value to the DLL where I use memcpy to fill the memory pointed to by the LabVIEW pointer. Basically: allocate a buffer in LabVIEW with DSNewPtr pass this pointer to the .NET DLL by calling my .NET DLL function SetExternalDataPointer(UInt64 lvPointer) use memcpy in the DLL to copy the data to lvPointer address read the data in LabVIEW by calling GetValueByPointer.xnode

Thank you, Rolf. However, what do you mean by "pass it as an Array as Array Data Pointer"? Pass where? Into which function? I am calling .NET DLL functions with calls via .NET Invoke Node in LabVIEW. Passing as Array Data Pointer is possible when calling unmanaged DLL functions via Call Library Function which I cannot use in my case, or can I?

In my application I need to get a few hundred bytes from a .NET C++/CLI DLL as fast as possible. This would be achievable by initializing an array in LabVIEW and then passing its pointer to the DLL so it can copy the data to the LabVIEW array directly. As far as I know this cannot be done. Or is there another way? Currently, I am achieving this behavior by using IMAQ GetImagePixelPtr.vi which allocates a small IMAQ image (array of pixels) and returns pointer to this image. Afterwards, I pass the pointer to the DLL, write my data to it and read the values back in LabVIEW. Is this too much of a hack? It seems to work OK.

That was it, thank you!

I agree it should be way faster. Here is my code snippet (pointer is just a constant number as an example, otherwise it points to an unmanaged array in my C++/CLI DLL).

I am using MoveBlock via Call Library Function to copy a few bytes. The duration of this call measured with two TickCount timestamps in a flat sequence around the call is about 40ms. Since MoveBlock should be similar to memcpy in C, I thought it would also perform similarly, however, if it's really this slow, I cannot use it in a meaninful way. Has anyone else measured its duration and can you confirm my findings?