NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Shared resources and processing many UUT's

Solved!
Go to solution

Hello I have a question about parallel processing and shared hardware.

  • single power supply for all UUT
  • common DAQ card (seperate DAQ channels for each UUT measurements)

 

I’m currently writing a sequence that will test 24 UUTs. These UUT will have a shared power supply to power all on and off at the same time and a shared DAQ module for measurements. The test seq should go as follows. These must be tested all at the same time during the test is the key.

 

  1. Turn on Power supply output to all UUT
  2. Wait
  3. Measure each UUT output (UUT0...UUT24)
  4. Change PS voltage output
  5. Wait
  6. Measure each UUT output(UUT0...UUT24)
  7. Change PS voltage output
  8. Wait
  9. Measure each UUT output (UUT0...UUT24)
  10. Turn off Power supply output to all UUT
  11. Finish test

 

Here are my questions:

  • How should I restrict the power supply control so that each cloned sequence will not try to control it too? Tie it only to socket 1 for example?
  • What process module would be best to use since they have to be all running at the same time?
  • Do I use the lock feature for each DAQ measurement and release it when done? I think I have to do this
  • What other environment settings should I be aware of? Multi-thread? Parallel sequencing?
  • What would you do?
  • Should the measurement be all at once or each indiviually. I will be using a UIMessage to send the data to the UI to a array of data
  • There will be other common things like locking saftey switches that need to be ran but how do i make sure that all of the parallel processes dont preform the same task. this only needs to be done once not each time in all 24 parts running
Bill Lewis
0 Kudos
Message 1 of 7
(5,371 Views)
Solution
Accepted by topic author Bill_Lewis

Bill,

 


Here are my questions:

  • How should I restrict the power supply control so that each cloned sequence will not try to control it too? Tie it only to socket 1 for example?
    • You write one module which handles the power supply (PS). You could also use IVI if you prefer that.
  • What process module would be best to use since they have to be all running at the same time?
    • I recommend Batch. The reason is that each DUT has to be tested in a way which is "synchronized" with all other DUTs.
  • Do I use the lock feature for each DAQ measurement and release it when done? I think I have to do this
    • Using the Batch model enables you to use "Batch Synchronized Sections" in your DUT test code (aka sequence). There is the option to run that part as One-Thread-Only (e.g. for power supply) and Sequentially (e.g. for reading analog values). Another option, which is preferable if measurements are 'complex' (e.g. require more than a single instrument including switching and stuff): Design and implement a separate component which i often call "IO Server".
  • What other environment settings should I be aware of? Multi-thread? Parallel sequencing?
    • If you implement everything correctly, there shouldn't be much stuff in addition. Please note that the following techniques already do some synchronization:
      • LV VI (default setting): Can only be executed by one caller at a time
      • IO Server: You design the multithreading and thread-safe capabilities
      • Batch Synchronized Sections: Synchronization measures inside of TS to make executions behave nice next to each other if used correctly. If you are not using these, you might want to use queues, notifications or rendezvous.
  • What would you do?
    • In case i'm not clear about things, i would ask NI for help in form of consulting on architectures and technologies or ask a partner for implementation services
  • Should the measurement be all at once or each indiviually. I will be using a UIMessage to send the data to the UI to a array of data
    • Depends mainly on your performance requirements and implementation skills. IO Server could help a lot in this question. From what you describe, taking all channels (24?) in one measurement seems possible, however when using multiplexing devices, you have to take care about "empty" channels. Otherwise, you might run into crosstalk/ghosting effects.

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 2 of 7
(5,367 Views)

@Norbert_B wrote:

Bill,

 


Here are my questions:

  • How should I restrict the power supply control so that each cloned sequence will not try to control it too? Tie it only to socket 1 for example?
    • You write one module which handles the power supply (PS). You could also use IVI if you prefer that.
    • I have modules that do the functions but they are in the sequence file. when these run in batch mode won't each UUT try to control the power supply since the seq is copied and ran on each UUT? or maybe I'm missing something.
  • What process module would be best to use since they have to be all running at the same time?
    • I recommend Batch. The reason is that each DUT has to be tested in a way which is "synchronized" with all other DUTs.
  • Do I use the lock feature for each DAQ measurement and release it when done? I think I have to do this
    • Using the Batch model enables you to use "Batch Synchronized Sections" in your DUT test code (aka sequence). There is the option to run that part as One-Thread-Only (e.g. for power supply) and Sequentially (e.g. for reading analog values). Another option, which is preferable if measurements are 'complex' (e.g. require more than a single instrument including switching and stuff): Design and implement a separate component which i often call "IO Server".
  • What other environment settings should I be aware of? Multi-thread? Parallel sequencing?
    • If you implement everything correctly, there shouldn't be much stuff in addition. Please note that the following techniques already do some synchronization:
      • LV VI (default setting): Can only be executed by one caller at a time
      • IO Server: You design the multithreading and thread-safe capabilities
      • Batch Synchronized Sections: Synchronization measures inside of TS to make executions behave nice next to each other if used correctly. If you are not using these, you might want to use queues, notifications or rendezvous.
  • What would you do?
    • In case i'm not clear about things, i would ask NI for help in form of consulting on architectures and technologies or ask a partner for implementation services
  • Should the measurement be all at once or each indiviually. I will be using a UIMessage to send the data to the UI to a array of data
    • Depends mainly on your performance requirements and implementation skills. IO Server could help a lot in this question. From what you describe, taking all channels (24?) in one measurement seems possible, however when using multiplexing devices, you have to take care about "empty" channels. Otherwise, you might run into crosstalk/ghosting effects.

Norbert


 

Bill Lewis
0 Kudos
Message 3 of 7
(5,365 Views)

here is a snapshot of my sequence. Each UUT will go into the sub sequences where measuements and power supply manipulation will take place too. I'm a little confused about how the power supply and other unique controls for the tester will be handled since TestStand will run virtual copies of the sequcence 24 times.

 

I'm thinking that these will be executed 24 times and the system will be fully out of control Smiley Tongue

Bill Lewis
0 Kudos
Message 4 of 7
(5,363 Views)

Bill,

 

well, the current sequence will duplicate 24 times if you configure 24 sockets for a parallel model. However, your Initialize Power Supply VI will execute socket per socket if it is default configuration (non-reentrant to be more specific).

So this is an example where you might use a batch model with a batch synchronized section with "one thread only" around it. This will perform the content of the section ONCE and all other sockets SKIP that content.

 

Please review the material in TestStand (help, examples,...) to get information on what to add to your sequence to make it working with 24 sockets without crashing everything.

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 5 of 7
(5,359 Views)

did you post an example? I dont see anything

Bill Lewis
0 Kudos
Message 6 of 7
(5,356 Views)

For a start you could look at https://decibel.ni.com/content/docs/DOC-23465.

And one question: What do you expect to happen in your setup , if one of your UUTs makes a dead short on the PS ?

0 Kudos
Message 7 of 7
(5,337 Views)