We do have both but I do not know much details about calibrations.
Thank you!
We do have both but I do not know much details about calibrations.
Thank you!
Hi Trent,
(Thank you both, by the way)
I think at this point I'm leaning more toward using text to generate XML. (Your latter suggestion)
So, about the ORPU and offline results in general, since you asked:
Before I get into it, I should note that offline results are a great concept - I don't want to be overly harsh with it.
Here are the things we had a hard time with (please forgive my candor - I'm only answering your question)
That being said, there are people way, way more knowledgeable of TestStand than myself on here and I don't want to claim these were the only ways to do things, but those were the methods I eventually settled on. If the offline result and ORPU developers can make it a bit "lighter" (on memory for instance) and a little more customizable I would absolutely love it. We had really high hopes for it and I'm getting a lot of pressure within my job to come up with an offline results solution that fits all of our requirements.
A humble thanks for your soliciting feedback based on my early comment, and thanks for reading this ridiculously long post.
(P.S. I will be in Austin next month - maybe this warrants further discussion?)
Mr. Jim
One other thing I forgot to mention... I tried moving one of the offline result files (with 14,000 results) to another PC and a freshly opened instance of the ORPU, no other TestStand activity. I was stoked about the prospect of success, but alas, it ran out of memory in that scenario, too. (I'd love to reduce the data set, by the way. Clearly that would be the best workaround. )
Not sure what you're looking for, but this is the calibration procedure.
http://zone.ni.com/reference/en-XX/help/374564P-01/calexec/procedure_433x/
Hey Roxana,
Thanks for the suggestions. The bitness definitely matches. We initially attempted a Conda environment, but when we found that wasn't supported we also tried creating one through virtualenv with the same results.
Attaching the debugger gives me following message during the "Analyzing Sequence File" part:
Process name: niPythonHost.exe and Process ID: 12292
The exact Process ID varies randomly between multiple attempts at running the script.
With the debugger attached the sequence actually advances up to the first Python action instead of terminating immediately. But upon reaching the first piece of Python code it still crashes with a run-time error stating the interpreter session has crashed.
I have uninstalled TestStand again. Rebooted the PC. Deleted anything TestStand related entries still in the registry. Deleted any folders left on the PC. ( I think I did this before the registry action). Rebooted. Installed TestStand vi the NI package manager.
This time it has worked.
Although it’s now showing I have limited time left on my evaluation even though it extended the number of days. The LabVIEW is showing 26 days and I installed this the same time as the TestStand (the very first time) so if the TestStand installation is not going to be treated as a new installation and give me the full extended time then it should be showing me the same time left as the LabVIEW.
In the LabVIEW adapter configuration dialog box, does the override the module settings for all LabVIEW steps and always run the VI in the packed library prevent you from running a particular step in its source code version?
Have you tried stepping into your VI and step through your VI.
is your front panel showing your inputs?
are they passing through your code ok?
is they any errors?
DCXenics,
I ran into similar issue and hope the following helps.
The error message you have posted is from TestStand Analyzer. However, if we ignore the analyzer error, enable displaying console for python (using Configure >> Adapters >> Python) and execute the sequence file, the console displayed the following error for me.
Fatal Python error: initfsencoding: unable to load the file system codec
ModuleNotFoundError: No module named 'encodings'
If you are also getting same error, then do the following to fix the issue (which I got from this link that mentions about issue in anaconda that supports python 3.7).
Assuming that you have installed Anaconda to 'C:\ProgramData\Anaconda3', set the following environment variables.
PYTHONHOME => C:\ProgramData\Anaconda3
PYTHONPATH => C:\ProgramData\Anaconda3\Lib
Setting the above two environment variable and restarting the application fixed the issue for me. Hopefully it will fix the issue for you too.
Based on this link, it seems that the issue was introduced by anaconda that supports python 3.7. Hence, if you can use anaconda that supports python 3.6 or earlier, there should be no issues. Also, as mentioned in this link, take extra care if you are using python virtual environment.
-Shashidhar
Roxy, thanks for the response; that's good to know. That said, it leads to further questions (please pardon my TestStand ignorance here):
By "developing code modules," I assume you mean creating CVI/LabVIEW/C code that will combine a few different IVI calls in to a single, coherent operation. Is that correct? Or did you mean just write direct 'wrappers' for each of the IVI-C driver functions directly?
If the former, requirements state that I should expose all functionality directly, so while I assume it's a 'best practice' (and completely agree that would make sense), it's not the goal here.
If the latter, it's unclear to me what would be gained from wrapping the raw IVI functions. I used visatype.h to find the definitions for all the vi* datatypes, and am passing them directly as arguments to the IVI-C dlls. Is that a bad idea?
Thanks for sharing those details.
So we actually do ship the source code for ORPU if you're familiar with C# and want to modify it:
%TestStand%\Components\Models\TestStandModels\Offline Results Processing Utility
It's worth noting there's a bug with the source shipped in 2016 that prevents you from recompiling if you make any changes... That was resolved in 2016 SP1. TestStand 2017 also fixed a few other small issues with ORPU.
ORPU loads its own instance of the Engine and essentially just deserializes the offline results and runs them through the result processors like a normal TS execution would. If you can run a normal execution and generate a CSV report that large without running out of memory, but ORPU crashes... you might have found a bug. The only thing that comes to mind is that I'm not sure if ORPU is Large Address Aware (i don't have a 32-bit build handy to check), but the Sequence Editor is. We actually ship a utility you could use to check and change it if it's not. If that doesn't fix it, I'd appreciate you sharing some example files that could help reproduce it with myself and Dane.
Thanks!
Trent
I am using .VI applications with TestStand 2012. I have base deployment engine license and my applicaitons are working just with one user on computer. If I login with another user on computer , some applications not working and giving '' error loading step ...'' and '' Failed to load VI ...''. Do you have any idea ?
Hey Chris,
Yes, the first suggestion is recommended.
What is the functionality required to expose? Does the consumer of this code really need all of the inputs, or are some fixed and so on? What does the test developer need? That could determine the amount of functionality to expose.
If the goal is to expose the functionality, then why even wrap them in LabVIEW? Seems that would limit the scope more than expand it.
Thanks,
Roxy
A lot more detail is needed. However, my guess is that your files are located in that first user's directory (e.g. C:\Users\UserName\Documents)
When logged in as another user, TestStand's search directories can't find the files from the first user's directory. I would first set up the search directories (Menu->Configure->Search Directories) and make sure the directories for the sequence and all code that's called is somehow covered in all of the search directories.
wrote: Hey Chris,
Yes, the first suggestion is recommended.
What is the functionality required to expose? Does the consumer of this code really need all of the inputs, or are some fixed and so on? What does the test developer need? That could determine the amount of functionality to expose.
If the goal is to expose the functionality, then why even wrap them in LabVIEW? Seems that would limit the scope more than expand it.
Thanks,
Roxy
Roxy,
I'm not wrapping in LabVIEW - it would be a CVI wrapper if anything. I guess my concern was that I don't see a point in writing code modules in this case, given the functionality I need would basically just be a direct wrapper for the IVI-C driver. The only point I see in wrapping would be that using native C datatypes would allow the function signatures to auto-populate (which isn't a requirement). Is that a correct assessment?
Thanks!
Edit - For clarity, these aren't actually designed to test a DUT, they are designed to expose functionality to allow a user to access the hardware directly for diagnostic purposes. There will be some self-test sequences, which I agree, should be written as code modules.
A heartfelt thanks to both of you again - I will take a look at the C# code!
I'll also check the large-address-awareness in the hopes that we can buy a little more headroom.
Absolutely - regarding a proof of concept for what we encountered I should be able to reproduce it and make some files available at the next opportune time. (I'm sensing deja vu... I may have attached such an example to a support ticket at one point? It was a while ago. Regardless I'll get that going again.)
Kind regards,
Mr. Jim
I wouldn't consider 64-bit mode as a workaround for dealing with large data sets because that is pretty much what it is good for.
TSR files are not completely black boxes in that, in addition to being accessed in the public ORPU source code, they can be directly written with the ResultLogger class and read with the ResultLog class in the TestStand Engine API. Internally the files are mainly just serialized PropertyObjects. Specifically, serializations of most of the arguments that the model passed to the model plugin entry points when the UUT was tested, including the result list tree.
I am working on a test system where the sequence launches with a custom process model and then each sub-sequence of the top-level sequence is called in a new execution with the same custom process model (to generate results for each sub-step as well as the overall sequence). Although confusing, this seems to work OK - except for one issue...
When an error occurs in the new execution, the ErrorReported flag is not propagated to the top-level execution and the error status is...this means that any errors are always displayed/reported twice.
We have a custom ProcessModelPostStepRunTimeError callback which obviously also gets called twice.
How can I pass/set the ErrorReported flag to the calling execution so that when the second ProcessModelPostStepRunTimeError occurs it is ignored?
As an aside - I am sending the errors to the OI by way of a UserMessage which triggers an error dialog (asynchronously)...for some reason when the second error is triggered and I haven't closed the dialog, this causes the OI to lock up...I think because it is waiting for a thread/execution to finish which is why I am trying to suppress the second error - it only needs to be reported once (but the top-level step should still show it's status as 'Error').
I am having problems with this topic.
I have a simple PPL and I have a sequencefile with one step using the source VI, one step using the PPL VI and a third step with the project and the source.
The first two steps behave as previous versions of TestStand where one would have to relink from the PPL VI to the source VI to do any editing etc.
The third VI should be setup to try this new feature of TestStand 2019 where one can switch between source and PPL but its not working. I am getting an error with the OverrideBinaryProjectPath.
As you can see there is an error telling me it can not find the VI in the lvlibp file.
I have zipped up the labview 2019 project and the TestStand 2019 sequencefile for someone to tell me what I am doing wrong.
Yes,it is default PUUTPANEL in parallel mode. The picture in the attached file shows our request for 3 serial number boxes additionally. I feel that it is very complicated if change this default panel. I don't know how to easy to do this change.
Thank you