run two independent tests in the same program

[astroboy]

Any suggestions or advices for me?
I will be starting to build the program. Before I can start. I am asking for your advices.
I have a test jig that will run two tests independently from each other. For example. the operator will put the device on first station and start the test program, then she puts another similar device on the second station and start another similar test program. They should be able to run independently from each ther although they are built in the same program.
I will be grateful for your generous advices.

[devchander]

One question.

Do you have some DAQ/serial communication devices that each of your tests use??

Do you use/call the same hardware device in both the tests??  If yes, do some pre-planning on how you resolve 'device reserved' conflicts that 'may' arise

[Pnt]

Allhough you will already know that:

I think the more simple way, is the best way...

just use two parallel loops in your main vi or two (for example) producer/consumer loops in parallel.

[astroboy]

Hi all thanks
Yes I will be using the DAQ device and it will be shared. But the IO resources will be divided for each station, meaning that each group of DIO and AIO pins for will be solely for each station. And if possible, i would like to use event structure. So how do I use event structure?

[astroboy]

Hi All share your comments on my attached.
Clement

[Pnt]

It is not ok.

You have to press the START button for more than half a second to be triggered.

Same, if you press for a momment the STOP button, while a test is in progress it hungs.

I think the timeout case is doing nothing. I don't fully understand what you are tring to do but

i whould sugest one event producer - two consumer loops.

Can't you use a functional global for storing and reading all those values?

[Ray.R]

astroboy,

Which development package do you have available?  Personally, I would use TestStand as a test sequence manager.  I won't go into details unless you have it.

You can implement a solution using Labview.  You will need a higher level interface that can call and configure tests, thus allowing more than one UUT.  If the tests are the same, simply make the "test.vi" re-entrant.  A good architecture is important to get the correct operation / behavior of the test software.  In the case of multiple UUTs, a starting point is to describe how you want to select tests and configure them for each UUT.  The configuration includes communication to/from each UUT, as well as power up, shut down, etc.  The hardware may dictate how you can proceed.  Therefore starting from the ground up means looking at your test resources within the test setup / fixture.  Once that is established, you can place those considerations as part of your test software requirements, which may influence your software architecture.

Hope this helps,

RayR

[astroboy]

Hi I need your advice.

I am not sure if I am doing the right thing or not.

If not, what is the correct thing to do?

Clement

[altenbach]

---

astroboy wrote:

I am not sure if I am doing the right thing or not.

---

You should really attach the VI instead of a picture, but here are a few points:

• You should probably use a queue instead of notifiers, else you might lose data.
• You don't need to place the queue/notifier wire inside shift registers. They don't carry any data
• Why are you afraid to wire to the stop button terminal? Use it in the code! (e.g. in one of the loops)
• The lowest loop makes no sense at all. Is there anything in the other event cases?
• Use local varaibles (sparingly!) if needed. Value properties are much less efficient and should never be used like that.
• You should wire the error terminals.
• What is the purpose of the sequence frames?

[Ray.R]

I agree with Altenbach on all points.

You should never use notifiers if you are passing data. 

More than showing the diagram, you should explain what you are trying to attempt.  There isn't enough information to determine what you want to accomplish with this.  Other than being a basic exercise to understand the architecture.

R