Question for Experts: DVRs data pass to C DLL?

[JCC_(SK)]

Hi all

Is there any option to pass LabVIEW data saved in DVRs to C DLL call?

Background info:

• 5-6k of DVRs
• DVRs are same type
• DVRs will be accessed in read-only mode
• memory allocated by DVRs proximately 32 GB +/- 10GB - for one scan. One more scan could be in process of loading to memory.
• PC with 128 GB RAM
• C DLL will be created by us

Data are saved in smaller DVR chunks because size of all data is not know at beginning.

For memory management I expect that it is better to use this smaller chunks - then LabVIEW don't have to reallocated memory to create one long chunk where everything will fit it.

I am looking forward to your ideas.

Best regards

 Peter

[JCC_(SK)]

https://forums.ni.com/t5/LabVIEW/Creating-EXTERNAL-data-value-references/td-p/3873039

[Jacobson-ni · Accepted solution]

You could also try to more explicitly manage memory through some of the built in LabVIEW functions like this library does.

https://github.com/ryanpoulos/labview-memory-management-tools

[JCC_(SK)]

Great Library very nice job. Superb implementation of DSNewPClr, MoveBlock and DSDisposePtr.

This way I will have to move every block to DS pointer position. 🤔

DSNewPClr will create 'non-relocatable block of memory' - is this mean that LabVIEW will not move this block during memory house-keeping?

[rolfk]

---

@JCC_(SK) wrote:

DSNewPClr will create 'non-relocatable block of memory' - is this mean that LabVIEW will not move this block during memory house-keeping?

---

No! LabVIEW used to have DS and AZ memory heaps and AZ memory (if it was a handle) could be relocated by the memory manager at will. So if you wanted to access the content of an AZ handle you had to lock it first (there was an AZLock() function) to prevent the memory manager from relocating it and then unlock it afterwards. The AZ memory heap has been completely removed somewhere around LabVIEW 8. Also only internal functions in LabVIEW used AZ memory handles, everything that could be seen on a diagram (Strings, Arrays) were DS handles with the exception of Paths I believe.

But there is still a difference although not in a way that the memory manager stealthily could relocate your memory.

LabVIEW pointers are non-resizable by design. There does not exist a DSReallocPtr() method or similar at all. A pointer can only be allocated and deallocated. LabVIEW handles however can be resized with DSSetHandleSize() but not stealthily. DSSetHandleSize() may have to allocate a new buffer in the handle and copy the data over so when you have somewhere else stored a reference to the buffer inside that handle it gets invalid. This means you should NEVER store pointers to the buffer inside the handle but ALWAYS dereference the handle itself properly.

When your function receives a handle from the diagram through the Call Library Node you are the owner of that handle (unless the parameter in the Call Library Node is marked Constant!!!) for the duration of the function call. In this time you may resize or change its content (and don't forget to update the inherent numElement int32 accordingly to tell LabVIEW how many elements are in the array or string. LabVIEW doesn't usually check if the handle size is consistent with the number of elements variable and that could lead to nasty problems if you make the handle smaller but leave the numElements value at its old value). You may even temporarily use the buffer pointer directly. But once you return from your function you may NOT reference that handle anymore elsewhere in your code. It's NOT safe as LabVIEW may resize and deallocate that handle anytime it feels like it.

And watch out: If a parameter is marked as Constant in the Call Library Node, LabVIEW can use this indication to optimize memory allocations and use it to schedule code clumps in specific order to not have to copy memory blocks unnecessarily. But if your C code then goes and changes the handle anyways, don't whine when things start to crash.