01-22-2016 03:23 AM
In my Process Model Sequence is a call to DetermineReportFilePathNameExpr contained in modelsupport2.dll . (Teststand 2014 64 bit) This call makes the Teststand Sequence Editor stop working. I guess (?) that the reason are missing DLLs as follows
My system
In the Dependency Walker analysing modelsupport2.dll used in calling DetermineReportFilePathNameExpr i see the following DLLs missing on my system :
How can i get these DLLs ?
Best regards
Solved! Go to Solution.
01-24-2016 07:19 AM
Hi!
please have a look at the following stackoverflow question, which sounds very similar in my opinion:
windows - Win 7, 64 bit, dll problems - Stack Overflow
http://stackoverflow.com/questions/17023419/win-7-64-bit-dll-problems
Seems like it is connected to a missing/wrongly installed Visual Studio Redistributable Package.
Best regards,
Christoph
01-25-2016 10:10 AM
Hey Rainman,
It is unlikely that those DLLs are the issue. When I loaded modelsupport2.dll on my computer I saw the same missing DLLs and my TestStand system does not hang in the process model.
What I think is happening is that this function is trying to do is to get/set a path the TestStand process does not have access to. This could be because of Windows permissions or because you are trying to write to a get information from a network drive and it is taking a very long time to look up the path. Anti-virus is something else that can cause trouble.
Thanks,
-KP
01-26-2016 06:58 AM
Hi Kurt
thank you for your attention.
The following message occurs when the step is executed (single step, single pass). Unfortunately this is all, no further information is available .
Then the Teststand Sequence Editor works no more.
The step in my custom process model causing this message is as follows:
The values passed to the function DetermineReportFilePathNameExpr can be seen.
No network drive is used.
Thank you
Rainman
01-27-2016 07:56 AM - edited 01-27-2016 08:04 AM
Hey Rainman,
TestStand ships with the source code for modelsupport2.dll. It is located in the TestStand conponents directory:
32-bit: C:\Program Files (x86)\National Instruments\TestStand 2014\Components\Models\TestStandModels\modelsupport2
64-bit: C:\Program Files \National Instruments\TestStand 2014\Components\Models\TestStandModels\modelsupport2
You can compile it if you have CVI on the system. If not, you can at the very least still look at the .c files and see what is going on in the code.
For this particular funtion, it looks like we changed it over the years. The newer version of the function is DetermineReportFilePathNameExprEx2 and has two more parameters: processModelClientPath and uutPartNum. If you are creating a new process model from scratch, this is the call you should use so your process model is more exstensible should you ever decide you need that information.
Try the DetermineReportFilePathNameExprEx2, and pass values in for processModelClientPath and uutPartNum. If that still causes TestStand to hang, then I would recommend building a debug DLL to see the line of code where this happen.
Edit: Also try passing a value or empty string "" for uutStatus. Passing Nothing might be a problem. I don't expect it to be a problem because TestStand converts this to a Null point of the appropriate architecture, but it is worth testing out.
Thanks,
-KP
02-09-2016 02:20 PM
All,
I filed Bug report 572171 for this behavior. The work around is pass empty string "" or any value in DetermineReportFilePathNameExprEx2 for the uutPartNum parameter.
Thank you,
-KP
10-20-2017 10:02 AM
Hi Kurt,
i re-activate this thread because your suggestion resulted in another issue:
I used "DetermineReportFilePathNameExprEx2" and had no direct error. I passed an empty string to uutPartNum. But now the makro in "ClientFileName" in the "Report File Pathname Tab" is not present in the file name of the report in the file system. Instead it is replaced by some "UnsavedSequenceFile" part in the file name. But the affected sequence file of course is saved.
Curiously in the window for the "Report Options" -> "Report File Pathname Tab" the "ClientFileName" makro is evaliuated correctly as shown below ("testprüffall.seq" is its file name in this case).
Regards Rainer