usnistgov / REFPROP-manager

A manager class for holding many copies of REFPROP in memory
9 stars 8 forks source link

RefProp Manager in LabVIEW #10

Open TommasoMigliorini opened 2 years ago

TommasoMigliorini commented 2 years ago

I am trying to use the RefPROP Manager. I compiled the 32bit dll and am trying to use it in LabVIEW. If I understand correctly, the technique involves creating a handle to pass to the various calls of the dll. For this reason I created two vi's, one to create the handle and one to destroy it. The handle number seems to increase but the LabVIEW call keeps giving errors, can you help me?

RefPROP Manager.zip

ianhbell commented 2 years ago

Why are you trying to use the refprop manager? It is for an advanced use case of multiple shared libraries loaded in memory

TommasoMigliorini commented 2 years ago

Mainly for 2 reasons:

ianhbell commented 2 years ago

First make sure you can do that in C++ or Python, or a similar environment. Labview integration should be tested only after.

ianhbell commented 2 years ago

Your use case makes sense for the manager. What OS are you on?

TommasoMigliorini commented 2 years ago

Windows 10 64 bit, with 32 bit exe

ianhbell commented 2 years ago

Why 32-bit? That's another wrinkle of complications with symbol mangling

TommasoMigliorini commented 2 years ago

In my application there are some other dll only 32 bit..

ianhbell commented 2 years ago

Ugh, and you can't update them?

My recommendation stands: first test in C++ or Python, then Labview.

TommasoMigliorini commented 2 years ago

We tried both 32-bit and 64-bit and immediately it works (in 32-bit we have an error in creating the handle but it doesn't create problems). We then started the system with a configuration that we usually use on our construction sites. The configuration foresees 25 calls to the dll for each calculation cycle, the calculation occurs every 500ms. The application crashes between 2 and 4 hours after it is launched, whether it is 32-bit or 64-bit. So in the best case we get to around 700,000 calls. We tried to decrease the number of calls to the dll per calculation cycle and to calculate at larger intervals (every 2 seconds). The duration of the application increases, the total number of calls to the dll remains the same.

Immagine crash RefProp

ianhbell commented 2 years ago

Please try your example in C++ or python to try to nail down where the problem is. I have no prayer of debugging with the given information.