From: gsussman on 21 Feb 2007 13:10 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 21 Feb 2007 13:10 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 21 Feb 2007 17:10 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 22 Feb 2007 18:40 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.
First
|
Prev
|
Pages: 1 2 Prev: CWGraph3D cursor visible property available ? Next: time with 'Write to measurement file' |