Jump to content
FJ_Sanchez

Allocating buffers for external DLL

Recommended Posts

Hello,

 

I've been using Snap7 library for a while in the client role, so I can communicate with SIEMENS PLCs There is specific LabVIEW info here: http://snap7.sourceforge.net/labview.html

I can successfully use the Cli VIs to read/write from PLCs DBs (a DB is just a memory block). For reading I pre-allocate a buffer, but I'm not sure if I'm doing it properly. My main concern is about memory leakage, I don't know if the memory will be freed after the VI exits or it will not be freed as long as the VI is in memory.

 

Attached is what I have just now for reading. I define a typedef for each DB, it is a cluster of booleans, and reserve memory according to the number of booleans, but always in multiple of 8 (I read only bytes). I request the data with the CliDBRead and after that I make some conversions to return the data in a variant that I later cast to the proper typedef.

 

Can you tell me if this is the best way to do this?

 

Thank you!

post-50325-0-21770900-1416303699_thumb.p

Share this post


Link to post
Share on other sites

Sounds correct, I don't really understand the case in which buffer size is computed, but it may be there for a reason. You don't have to worry about leakage in LabVIEW code, since memory is managed by the runtime.

Share this post


Link to post
Share on other sites

Hello,

 

I've been using Snap7 library for a while in the client role, so I can communicate with SIEMENS PLCs There is specific LabVIEW info here: http://snap7.sourceforge.net/labview.html

I can successfully use the Cli VIs to read/write from PLCs DBs (a DB is just a memory block). For reading I pre-allocate a buffer, but I'm not sure if I'm doing it properly. My main concern is about memory leakage, I don't know if the memory will be freed after the VI exits or it will not be freed as long as the VI is in memory.

 

Attached is what I have just now for reading. I define a typedef for each DB, it is a cluster of booleans, and reserve memory according to the number of booleans, but always in multiple of 8 (I read only bytes). I request the data with the CliDBRead and after that I make some conversions to return the data in a variant that I later cast to the proper typedef.

 

Can you tell me if this is the best way to do this?

 

Thank you!

 

LabVIEW is a fully managed environment. As such you do not have to worry about explicit memory deallocation if you are not calling into external code that allocates memory itself.

 

You're not doing anything like that here, but use LabVIEW functions to create those buffers so LabVIEW is fully aware of them and will manage them automatically.

 

There is one optimization though you can do. The Flatten to String function most likely serves no purpose at all. It's not clear what data type the constant 8 might have and if it is not an U8 it might even cause problems as the buffer that gets created is most likely bigger than what you need and the Plan7 function will therefore read more data from the datablock. This would in the best case cause performance degradation because more data needs to be transferred each time than is necessary and could cause possibly errors if the resulting read operation causes to go beyond the datablock limit.

 

And if it is an unsigned 8bit integer constant, a Byte Array to String function would do the same but more performant and clear.

Share this post


Link to post
Share on other sites

LabVIEW is a fully managed environment. As such you do not have to worry about explicit memory deallocation if you are not calling into external code that allocates memory itself.

 

You're not doing anything like that here, but use LabVIEW functions to create those buffers so LabVIEW is fully aware of them and will manage them automatically.

 

There is one optimization though you can do. The Flatten to String function most likely serves no purpose at all. It's not clear what data type the constant 8 might have and if it is not an U8 it might even cause problems as the buffer that gets created is most likely bigger than what you need and the Plan7 function will therefore read more data from the datablock. This would in the best case cause performance degradation because more data needs to be transferred each time than is necessary and could cause possibly errors if the resulting read operation causes to go beyond the datablock limit.

 

And if it is an unsigned 8bit integer constant, a Byte Array to String function would do the same but more performant and clear.

 

I agree with you, I think that flatten to string is appending some useless information in this case.

 

Thank you.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.