CVI UIR to LabVIEW

[mrbean]

We are working with another company on a two highly-hardware intensive test rack.  We both plan to use TestStand, but their implementation will be in CVI whereas we're seriously considering LabVIEW.  Although we're delivering two separate products, our customer would like our top-level user interface to look and feel the same.  This other company proposed sending us their .UIR file (but not the source behind it). 

1) What are our options as far as getting our GUI to look/behave similarly.  Do I somehow convert the UIR to LabVIEW or do we need to have the first (TestStand) screen be CVI-created.

2) I have a little experience with TestStand and CVI (little in LabVIEW), but I've not had to do any operator interface customization.  Do I start in TestStand and tell the process model that I'm modifying the operator interface, OR, do I create the LabVIEW User Interface (using the TestStand Palette) and then tell TestStand I'm modifying the OI.

3) There are probably applications where CVI is better suited and others where LabVIEW is better suited.  However, since we plan on controlling the overall sequence/management of the tests with TestStand, is one of these tools favored?

[Dennis_Knutson]

TestStand will run steps written in either LabVIEW or CVI (or VB, MS C++, etc.). An operator interface can be written in either language and run steps from either language. If you look at the shipping examples of the CVI and LabVIEW operator interfaces, you will see that they are very similar. Either one will run with the exact same default process models. If the other company is designing their own custom operator interface, then you can probably make a custom LabVIEW operator interface look the same but you would need more information than just the UIR to make your operator interface act the same. Since you haven't done any customization of the operator interface, you could just get the executable version from the other company and run it with your sequence. If their custom OI also requires modification to a process model or step modifications, you would need this information from them.

[Dennis_Knutson]

I forgot to mention that another difference could happen with custom callbacks. Say you don't like the default serial number dialog and you write your own and have it in a sequence file callback. If the other company uses the standard dialog, this would be another user interface difference.

Without a lot of cooperation between the two companies, I can see the potential for some serious confusion. Someone has to be in position to arbitrate and make some decisions as to a common look and feel.

[JonathanN]

Hi mrbean,

Dennis was fully correct in all of his statements. TestStand by default provides five built-in operator interfaces written in LabVIEW, LabWindows/CVI, Visual Basic .NET, C#, and C++  (MFC).  Every operator interface provided by TestStand all have similar GUIs and functionality.  They allow you to start multiple concurrent executions, set breakpoints, and single-step just like in the sequence editor.  Unlike the sequence editor, however, the operator interfaces do not allow you to modify sequences, and they do not display sequence variables, sequence parameters, step properties, and other programming variables in TestStand.   

The full-featured operator interfaces are located in the <TestStand>\OperatorInterfaces\NI\Full-Featured directory while the simple operator interfaces are located in the <TestStand>\OperatorInterfaces\NI\Simple directory.  These operator interfaces are a useful starting point when designed your own customized operator interfaces. 

Dennis is definitely right in saying you need somebody to coordinate the GUI layouts. It might be best to start of with a simple operator interface and work your way up.

For a more detailed reference on creating custom operator interfaces, see Chapter 9, Creating Custom Operator Interfaces, located in the TestStand Reference Manual. 

Hope this helps!

Best Regards,

[mrbean]

You bring up a point that I may not have understood until now.  You said, "Unlike the sequence editor, however, the operator interfaces do not allow you to modify sequences, and they do not display sequence variables, sequence parameters, step properties, and other programming variables in TestStand".

Am I correct in that while you're developing, you're working in the sequence editor, and once you run, you're then in the operator interface.  And, the operator interface is customizable, but the sequence editor is not?

Is your statement above "the operator interfaces do not allow you to modify sequences ..." true regardless of the OI (default or customized)

How can you debug an application during runtime?  Where are you at that point (OI or SE)?

[Dennis_Knutson]

I develop and debug in the sequence editor. Surely you've run your sequences in the editor. The run button is right on the toolbar or you use Execute on the menu bar. No, the sequence editor itself is not customizable. The operator interface is used once the sequence has been debugged and you release it to production. You don't need and probably don't want the sequence editor on the tester at all once it's been released. It's called an "operator" interface because you don't want to give the production operators any chance at all of modifying a test sequence. It's like using the LabVIEW development environment to write a program and the using the app builder to distribute an exe.

If the test sequence has a problem when running under the OI, then you have a couple of options. You can set a break point and step into the code module. This assumes that you've distributed the VIs themselves, still have their diagrams, and you still have the LabVIEW development system installed. You still won't be able to view TestStand variables, modify the sequence, properties, etc. You can also install a debug version of the TestStand editor (separate license from the full development license) in which you can do these things. Or, if you left the development system on the tester, start that up and debug from there.