I'm not sure about LabVIEW, I'm not as good as Knutson, but I'll take a look at the sequence you have uploaded and see if there is anything I can find in TestStand. UI Messages are probably your best bet or your CVI workaround.
↧
Re: Can I keep a LabVIEW dialog floating in front while displaying a Message Popup?
↧
Re: Failed Pre-UUT callback does not fail whole test
Pre-UUT is not meant to contain steps which evaluate the UUT. Therefore, the whole process model does not take care about Pre-UUT in regard to evaluation and reporting of the UUT.
That being said, i am wondering why you break this "paradigm". What are those steps in your Pre-UUT which obviously do evaluate the UUT and why are they not part of MainSequence (and its connected call hierarchy)?
If there are evaluation steps in Pre-UUT at all, why do they connect to the status of the UUT rather than the status of the test system?
Norbert
↧
↧
Re: ict test
Hey,
i'm just wondering if NI has hardware (as SCXI accessories) to deal with pinped PCB in circuit tests.
proven concepts, etc. at a cost of lets say 10000 Euros, which is generic to test different kind of PCBs with digitals IO and analague IOs (pwm measurement), etc.
thx
koen
↧
Re: Pause and Resume sequence
HI
UI is one of the option but our sequences we are not going to run through UI .hence the requirement.
Thanks for the help.
↧
Re: ict test
koen,
NI does not create ICT systems as turn-key solution. If you are looking for that, you should get in contact with NI alliance members. You can search for one here.
Please note that some alliance members have "standardized turn-key solutions" already defined, so creating them takes less time (hence money). But it is important to talk about your requirements with the partner first in order that he can provide the best solution.
Norbert
↧
↧
Re: Pause and Resume sequence
Still, i recommend you to use a graphical UI.
You can, however, modify the process model to create a parallel running thread which displays/controls the popup dialogs. This thread has to be synchronized with your actual test sequence, so the test sequence itself has to contain appropriate synchronization steps. In that setup, the effort to create and maintain test sequences is far higher compared to a solution with a "standard UI".
Norbert
↧
Re: Pause and Resume sequence
Never thought of it!! I will look into it and at the same time will try to go for a UI option
↧
Re: Loading default limits for every execution
MimiKLM wrote:I'm worry about not the speed of loading you mentioned associated with your solution but the potential problems with the memory. Let say, I call the main sequence 1000 times without interrupting of the execution. So instead of having one copy of the sequence called with cleared/reinitialised all variables and properties I have 1000 copies in the memory. I'd call it a waste to have 1000 copies only because I need to have the the properties and variables cleared.
The copy only exists while the sequence is running. Once the execution of the sequence completes, the copy will be destroyed/freed. At least as long as your code modules don't hold their own reference to it somewhere (which typically they should not be doing).
So if you call main sequence 1000 times in a loop, you should still only ever have one runtime copy in memory at a time. The difference is a new copy is created (and destroyed once the sequence is done running) each time, rather than creating a copy only once and reusing it. There is a performance hit to this per call of your sequence that is somewhat proportional to the size of your sequence, but unless your sequence is really huge, or you test execution is extremely fast, you probably will not notice the difference.
Hope this helps clarify things,
-Doug
↧
Re: Failed Pre-UUT callback does not fail whole test
Norbert,
Thanks for your reply and the education.
Here is what I am trying to do. I have a test system and a product that I have to serialize. The problem is that if I have to retest I need to read the SN from the unit under test. The issue is that this is a high voltage product and before I can check to see if the unit has a serial number, I have to do several power tests to make sure I don't blow it up. If I want to set the serial number in TS myself, it seems like the power checks have to live in Pre UUT, as well as the read operation, so I can see if there is a pre-existing serial number or if I need to generate a new one.
TS assigns the SN to the model only during the Pre-UUT callback or within it's internal portion of the model if you do not create your own callback. At least that is the best I have been able to find.
I've been able to make this work in Pre-UUT by assigning my serial number (new or pre-existing) to the RunState.Root.Locals.UUT.SerialNumber property, which as far as I can tell, is available only in Pre-UUT. Any time I look for this in Main it doesn't exist.
Confusing, I know, but I don't have a better way to explain it.
If you can show me how to assign a SN to the serial number that the model uses anyplace other than Pre-UUT you will have solved my problem.
Thanks,
Dave
↧
↧
Deleting unused sequences in a report generator plugin
I'm using an unmodified version of ModelSupport.seq that came with TS 2013, and have created a result processing plug-in using the Configure > Result Processing > Advanced... > Create New Process Model Plug-in... method. This creates a sequence file with many sequences in it, which are empty, not called, nor are they callbacks.
As these sequences aren't being used, is there any harm in just deleting them to clean up the sequence file?
My understanding of how ModelSupport.seq works is that it goes through the enabled result processing plug-ins, parses all the sequences that are "Model Plugin - ...", and then at the appropriate steps in the process model, uses a ForEach loop to execute each sequence. So if a plug-in doesn't have (for example) Model Plugin - UUT Start, then ModelSupport will just not execute anything when ModelPlugins - UUT Start is called.
Thanks in advance,
Seth
↧
Re: Deleting unused sequences in a report generator plugin
Yes, you can delete the ones you don't need.
↧
Re: Reset global/static global variables in DLL loaded by TestStand
For (1), is that an analyzer warning or a runtime error? I used that expression in TestStand 2014 (I don't think 2014 has any difference in behavior than what 2013 had) and it worked in the cases which I tried. You can always do PropertyExists("RunState.Caller.SequenceFile") if you need to.
For (2), yes, I mean as the parameter or return value data type in the DLL adapter or CVI adapter. Basically, you can store a raw C/C++ pointer in an Object Reference variable using that data type.
I'm not sure I completely understand your description of your proposed architecture. But yes, if your globals represent shared instruments then leaving them as globals might make the most sense, you will need to acquire a lock or a critical section in each thread before accessing the gobal or instrument though. I have no idea what the global variables are/were for that you are using in your dll, so it's hard for me to know what kind of state is in there that could be thread specific, but if there is any thread specific state you might want to not use global variables for such state, or you could perhaps use thread local variables (kind of like per-thread globals) rather than passing a context variable around. Passing context variables around is a bit more flexible than thread local storage though in that it's not tied to a specific thread necessarily, but rather tied to the ownership and usage of the context variables.
-Doug
↧
Re: SSH and 64 bit Teststand
You cannot directly load and call 32-bit dlls in a 64-bit process. I would recommend looking for a 64-bit alternative to ExtraPutty. It is possible to do a remote sequence call from 64-bit teststand to 32-bit teststand to call legacy 32-bit code, but it would be much simpler if you can just find a 64-bit SSH API to use instead.
Hope this helps,
-Doug
↧
↧
Re: Why FindFile() cannot support *.txt this kind of file name?
If you want to do a file system search you can use a .NET action step and set it to use mscorlib, and the System.IO.Directory class and then call the GetFiles method.
Hope this helps,
-Doug
↧
My TestStand Deployment Utility Aborts With No Errors Specified
Subject says it all. Below is the log...
Starting a log for the deployment.
Starting Analysis
Processing Workspace...
Workspace Processed
Finished Analysis
Building...
2:51 PM
LabVIEW Version: 13.0.1f2 (2013 SP1) (32-bit) English
Creating an installer...
Adding files to installer
Validating...
Copying files...
Scanning files...
Updating files...
Build complete successfully.
Done adding files
Preparing to build deployment
Copying products from distributions
Done building deployment
The installer is finished.
Loading product deployment information
The build is finished.
2:54 PM
Aborted
+++++++++++++++++++++++++++++++++++++++
Any help as far as figuring out what is going on would be appreciated. I have no clue as to what is making this build abort.
↧
Re: Failed Pre-UUT callback does not fail whole test
Dave,
setting the serial number is by default in Pre-UUT, correct. You can, however, change that behavior by modifying the process model or simply overwrite the SN from your MainSequence. The lookup string you mentioned is the correct one when you are using the NI Sequential Model. It is no hidden property, so it should be accessible (and viewable) in the MainSequence at any time during execution. But as it is a "Run State Property", it is only available during execution (breakpoint!).
That being said, i feel that this discussion is not constructive for you. This statement is based on the following assumption:
The evaluation of the DUT regarding FAIL/PASS does NOT depend on a fail in the high voltage test. A fail in the high voltage test is more an ERROR which makes it impossible to test the DUT.
So maybe you can dig into that, while keeping the general setup with the Pre-UUT.
Norbert
↧
Re: Execution of TestStand-Sequence in LabVIEW via TS-API: Different Execution times for same sequence
Hi Norbert,
I wanted to follow your advice and implement the TS UI messages in my calling VI.
To get into the topic "UI messages in TestStand" I searched for a simple example thats a bit similar to my target application and found the following on the NI-Website:
https://decibel.ni.com/content/docs/DOC-38982
I've started the Top-Level VI (" BasicUIwithNativeControls.vi") of this project, loaded a sequence file and executed it. The VI was executed as expected (about 6 seconds). After the designated end of the execution I've stopped the Top-Level-VI using the X-Button of the application-window. The appropriate Project left open. Afterwards I've started the Top-Level-VI again and repeated the loading/execution procedure. The second execution took a longer time (about 30).
In case I shut down LabVIEW between the two executions of the sequence, both executions take the same duration (about 6 seconds).
Now I'm asking myself if I'm on the wrong track with my debugging attempt, because the example shows the same behavior as my own created VI.
Thanking you in anticipation
↧
↧
Re: Execution of TestStand-Sequence in LabVIEW via TS-API: Different Execution times for same sequence
Tobi,
i followed your description on how you reproduced the issue with the example. I use TS 2014 and LV 2014, both 32bits running on Win7 64bits.
I cannot reproduce the issue. Do you use 32bits LV as well?
Therefore, i request you to try a different machine.
Also, you might check if configuration of the "LabVIEW Adapter" to "Runtime Engine" changes the performance.
Norbert
↧
Re: Execution of TestStand-Sequence in LabVIEW via TS-API: Different Execution times for same sequence
I have already tried to use another machine. On both machines the following software versions are installed:
- Win7 (64bit)
- LabVIEW 2013 (32bit)
- TestStand 2013 (32bit)
A difference occured during the execution of the example on the second machine (lower performance system). The second execution takes more time (about 70seconds) as on the more powerful system (30 seconds).
Further I tested the setting of "Always Run VI on LabVIEW Run-time Engine" for the VI in the TestStand-Sequence. There were no major differences between the execution duration of the first and the second execution of the sequence. (The first execution has been executed a little bit faster)
That the reproduction on your system did not lead to the same (erroneous) result is a ray of hope for me. 
Have my instructions been comprehensible or is further description necessary to resolve all doubt?
↧
Re: Execution of TestStand-Sequence in LabVIEW via TS-API: Different Execution times for same sequence
Does running the sequence show the same behavior when using the NI Sequence Editor as UI?
Norbert
↧