06-20-2016 07:07 AM - edited 06-20-2016 07:14 AM
Hello I have a question about parallel processing and shared hardware.
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.
Here are my questions:
Solved! Go to Solution.
06-20-2016 07:19 AM
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
06-20-2016 08:14 AM
@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
06-20-2016 08:20 AM
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
06-20-2016 08:37 AM
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
06-20-2016 08:49 AM
did you post an example? I dont see anything
06-20-2016 11:42 PM
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 ?