LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Tab control with state machines

Hi,

 

I am new to Labview and will be using it to make automated test equipment.

 

I have made some good progress so far, and made a few fixtures which work well, using the USB6008 interface.

 

I am creating the test software using a simple state machine. However, i would now like the create a front panel where the user can chose which product they would like to test via tab control, and this then selects the correct state machine to use on the VI. I have tried a few options, with the nearest to a working solution being the tab control altering a case structure, with the correct state machine in each case. But this only works once, the program must the sotpped and restared to select a new product to test.

 

I would be grateful for any advice, and hope this makes sense!

 

Thanks,

 

 

0 Kudos
Message 1 of 14
(4,029 Views)

You face a situation most developers run into when starting to implement test applications. And honestly, it is a pitty that they/you do.

 

before giving recommendations on a solution, i want to urge you to talk to your manager. Test applications, esp. if it comes to parallel test, require sophisticated software development. That means that it takes a lot of resources like time, developers (accordingly software development licenses) and others.

Most managers expect the software of a test system to be simple and be developed within days. That is most often not the case. Development can easily take more like months (or even years) and most test applications are NOT simple. They are complex (esp. parallel testing).

 

The first step to develop a test system from scratch is to split test instruction and test sequencer.

Currently, you mix both and that is why you have such a hard time to develop good code.

 

The test sequencer is rather simple for a single, non-parallel test scenario. But it will be very complex for extended parallel test (e.g. 250 UUTs in parallel) including report generation for each UUT and dealing with shared resources. Therefore, one recommendation is to purchase a test sequencer rather than to develop on your own. NI TestStand is such a test sequencer.

Test instructions should not have any connection to the sequencer except that the sequencer loads the test definition file (sequence) and then calls appropiate source code to perform the test.

If you implement the sequencer using LV, dynamic VI calling is one way to implement the required flexibility. LVOOP with usage of dynamic dispatching could be another one.

The biggest question for the sequencer is: Are there standardized parameters for all code modules (VI connector pane)? How is reporting linked into the sequencer?

 

You see that starting from a simple state machine for a single UUT testing, it is a long and expensive way to get to a test software which literally can test any type of UUT including parallel UUT testing....

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 2 of 14
(4,003 Views)

Thanks for your reply Norbert_B,

 

I am booked on to a test stand course in March, so hopefully much of what you have just mentioned in your post will soon make more sense. We are healvily investing time into LabVIEW and understand its years worth of work and cont. development. Time is not a problem.


However, there must be a way to achieve my goal in the meantime using basic skills, I feel im so close. Basically I want tab control to select the relevant state machine in the VI, are you saying this is not possible without teststand or such?

 

Thanks again, 

0 Kudos
Message 3 of 14
(3,996 Views)

The point is that (from what i understand) you essentially bind sequencer and instructions in one implementation. That means that you duplicate the sequencer to be able to test the second UUT type.

This is not recommended.

 

Figure out a way to split instructions from sequencer and make the sequencer more flexible. Use parameters to call modules specific for the UUT type by the sequencer.

So the sequencer reads the information of the UUT type (active tab) and use this information to run a basic sequencing but calling different modules depending on the UUT type (active tab).

 

Depending on your software engineering experience/knowledge and your development skills, you will come up with a solution which will hopefully do what you need. However, going for TestStand (as you obviously do) is a good step in order to improve flexibility of the test system software beyond the current software approach.

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 4 of 14
(3,984 Views)

lvrichard

 

Norbert's advise is a good architecture for a test design that involves several test sequences However what I understood from your description does not seem very complicated.

 

I believe that what you want can be achieved by the following.

 

0. JKI state machines are my choice of preference when it comes to state machine architecture (especially when you want to execute multiple states sequentially).

1. Build your code on a state machine that captures the value-change event of the tab control and registers the selected tab in a the state machine Data cluster.

2. If you want each test to be executed on the tab (i.e. without opening a new window), include all the controls on the tab. Otherwise in a separate subvi.

3. If it is the later case make sure that once the test is complete you can close the subvi to go back to the original state machine. If not go to step 4

4. The test sequence that you will do can be divided into multiple states that can be used in other tests.

5. Your test sequence can be as simple as a sequence of states that you send to the state machine as a Macro (check the JKI example on how they use the Macro:Initialize)

6. Once the test is complete (and a report is generated if needed) you will go back to idle waiting for the user to change the tab (and thus the test sequence)

7. Familiarize your self with the JKI state machine architecture before you start for some stuff that I mentioned above to make sense

 

Sorry for the long post. Here is a potato with a jki icon

potato-sm.png

 

AA

Message 5 of 14
(3,974 Views)

Would you please share your code here?

 

Message 6 of 14
(3,960 Views)

Hi,

 

Thanks for the replies so far,

 

Here is a copy of my code. As you can see, there are two different prodcuts to test, an NC941 and an NC930 (the NC930 is dumbed down version of a NC941). I would like to add a few more products to test once ive got this working. currently you select the product you would lke to test by selecting the relevent tab.

 

Thanks,

 

Richard

0 Kudos
Message 7 of 14
(3,942 Views)

lvrichard wrote:  However, i would now like the create a front panel where the user can chose which product they would like to test via tab control, and this then selects the correct state machine to use on the VI.

I do not recommend this approach.  If staying in LabVIEW, then the state machine is what you want.  However, going to add the capability to run different UUTs will quickly become a nightmare and your VI will just become huge, bloated, and nearly unusable.

 

My recommendation is to make a different VI for each UUT.  You can then use a SubPanel to load the running UUT's panel into the main VI.  Use a combobox to select which UUT is being ran.  This will be A LOT more scalable and keeps each UUT's code seperate, making it simpler to develop a new test.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 8 of 14
(3,931 Views)

Some comment regarding the code you attached:

  • You have multiple infinite loop scenarios in your code especially when a test fails (example: OK Button pressed>Start test sends you to VE+ VE- O/P> VE+ VE- O/P will send you to Reinit values if condition fails which will send you back to Start Test, ...). Check all code for such problems.
  • You should not stop the main loop with the same inner loop stop button
  • I highly advise you to check the JKI state machine architecture which is definitely a better approach that the simple state machine architecture that you are using.

AA

0 Kudos
Message 9 of 14
(3,914 Views)

Would you please post the code saved for Labview 2013 please? I would like to help you if possible.

0 Kudos
Message 10 of 14
(3,880 Views)