From: gsussman on
Unfortunately I don't have any functions other than the ones that are included in the zip file I sent you.

LabVIEW errors (the type that require a shutdown) when calling a DLL
are normally indicative of passing the DLL the wrong data type(s) or
passing arguments that don't have the correct preinitialized size.
LabVIEW does not allow allocation of memory by the DLL, LV must pass
all parameters to the dll padded to specific lengths. The same holds
true for any data retruned from the DLL.

The best advise I can give you is to use the code I sent you as a
baseline for extending the functionality to other Refprop function
calls.
Use the calling convention detailed in my code. DO NOT use the calling
conventions used in the code you originally received from NIST. The
NIST calling conventions are not formatted 100% correctly. They will
work for pure fluids but will fail when attempting to work with
mixtures.
From: jacbenimble on
I believe that most of these calculations have limits on the ranges. If a calculation attempt is made and the data input is not a reasonable number you will get this error. Maybe you could use some sort of valid range check before attempting the call. You could use the example Excel program supplied on with the NIST CD to check the response with the given data. I believe that if you attempt to give it data that is out of range it will respond with an error and allowable ranges. (In the excel example)

 

 

 
- There are 10 kinds of people in the world, those that know binary, and those that don't
From: gsussman on
You are correct about the allowable ranges, however that should only
generate an error in the error cluster, and appropriate error source
text.
Range checking would be a pretty difficult operation in that in many
cases you have multi variable dependence. My recomendation would be to
simply perform the calculation and pick up any errors returned by
Refprop.


 That being said, I believe the error that he described (LV crashes) is the result of an improper DLL call.
From: Will Crowe on
As you say, I don?t think that it?s due to out of range values because sometimes it doesn?t give the error for several runs of the program, and then it appears even though the input values (and therefore the returned values) haven?t changed.

 

I tried to see if the error correlated with anything (time intervals between runs etc.) and the behaviour is pretty eratic ? sometimes the program runs and sometimes it crashes.

 

One strange thing that happens if I?m editting the program that calls TPFLSHdll, is that

 when I go to save or close the changed program, I occasionally get a report of an ?insane? object and then a message saying there has been a Fatal Internal Error. So, even when I don?t run the VI that links to the DLL, but simply edit the program that contains this VI, unusual errors can arise.

 

I will try to check the calls to the DLL, but they seem to be what?s documented by NIST. Also, would the fact that it works fine for pure substances not suggest that the calls are OK?

 

Regards, Will.