Compiling a DLL in CVI for use in LabVIEW that dynamically allocates memory

[KavehV]

I have a DLL I'm compiling in CVI that I'm trying to use in LabVIEW.  In labview, I have multiple calls to the DLL, but I'm afraid that the memory I've allocated in CVI in my DLL is not persistent across these function calls.  If I allocate memory in the DLL, how can I be sure that that memory will be the same on the next call of that DLL from labview?

[ColeTrain]

Hello KavehV,

As you may or may not have figured out by now, when you call a dll from within LabVIEW, LabVIEW will not call the dll itself into the same memory location each time.  This is something about LabVIEW that I do not know that you can change, but a better question might be, why exactly do you want this functionality? If you have a decent reason, this might be something to post on the LabVIEW forums as they could probably offer a better answer.

[KavehV]

My reason is code reuse.  I don't want to recreate routines that frankly are much easier to write/implement in C than labview.

[ColeTrain]

I absolutely understand the code reuse.  You are correct in stating that certain routines are not well implemented in LabVIEW.  I was more curious why you needed the persistent memory.  If there's a reason, I would imagine that we could just rearchitect your code a wee bit to get the functionality you're looking for.

[KavehV]

Based on the DBC file and various conditions, I dynamically allocate memory and read to/write from that memory to XNET interfaces.  This gives me complete control over what gets sent and let's me access everything I need through hashes and pointers quickly.

Rearchitecting is kind of out of the question.  It'd be easier to rewrite it from scratch (and even that isn't so easy).

[ColeTrain]

Just to make sure we're on the same page, you know you can interface directly with the DBC files from within LabVIEW, correct?  Also, I was probing to see if there was a smaller change we could make.  Just trying to throw out some helpful ideas here. How many objects are you communicating with through your card?

[KavehV]

Yeah, I'm aware of that, however I've written a bunch of code on top of the current XNET APIs that grabs pertinent information from the DBC and lets you do some nice things with it.  A colleague wanted to use similar functionality without having to rewrite it all.

[ColeTrain]

Well KavehV,

I apologize that I cannot give you a better answer.  I will encourage you though that if you think this might be useful to others to post it to the community site for others to use.  Or if you don't want to do that, you can just post it on here and I will be happy to upload it for you.  It also still wouldn't hurt if you maybe took a stab at the LabVIEW forums as there are some smart cookies out there and you might find someone who can give you an idea of how you can achieve what you are looking for with minimal effort.

[KavehV]

I'm not sure how usefull it would be, and a lot of it is proprietary so I won't be able to post it.

On a side note, though, when are we going to be able to grab custom attributes out of a DBC file using XNET?  I'm still waiting for this critical functionality to be implemented.

[ColeTrain]

Hey KavehV.

I did some asking around here and did not come up with anything solid.  Could you offer a few more details on what these custom attributes are that you're refferring to? Are you thinking just free fields that aren't neccessairly tied to any specific message/frame? More along the lines of a traditional database type file?