Software Architecture Test Bench with multiple test stations

[hrmpf]

Hello together,

I've a test bench with one Test station. The test bench includes one test mechanical setup to contact and put strain on the DUT, controlled by a cRio 9045. Data Aquistion is also done via the cRio.

The test bench is now being expanded to include three more identical test setups.

In advance I'm thinking about the software structure, so that the BD will not to extensive and confusing.

There are two approaches I think.

1. I build a few Vi's. One for Data Aquistion, one for each test setup control. But what are the oppertunites to communicate between the Vi's? The test setup has to interact with the measured Data, if there any limits overshouted. The communication should be fast and save ressource.

2. I build one Vi' which contains many SubVi's to keep the BD clear

Did anyone have experince what is the best way to handle multiple test setups? Maybe we can discuss advantages and disadvantages. Further suggestions are welcome.

[ZYOng]

You can only run one main VI on cRIO. Hence your first option is not possible.

What you need is a multi-parallel loops application that share data between each other. You can use subVI to keep block diagram clean and neat.

[GerdW]

Hi hrmpf,

---

@hrmpf wrote:

I've a test bench with one Test station. The test bench includes one test mechanical setup to contact and put strain on the DUT, controlled by a cRio 9045. Data Aquistion is also done via the cRio.

The test bench is now being expanded to include three more identical test setups.

In advance I'm thinking about the software structure, so that the BD will not to extensive and confusing.

---

Why do you need to change your code at all?

You have one testbench, completely controlled by a cRIO.

You duplicate that testbench several times, and each of the new testbenches gets its own cRIO: no worries!?

[hrmpf]

---

@ZYOng wrote:

You can only run one main VI on cRIO. Hence your first option is not possible.

What you need is a multi-parallel loops application that share data between each other. You can use subVI to keep block diagram clean and neat.

---

I created a simple test Project with two parallel running VIs on cRIO and it works.

[hrmpf]

---

@GerdW wrote:

Hi hrmpf,

Why do you need to change your code at all?

You have one testbench, completely controlled by a cRIO.

You duplicate that testbench several times, and each of the new testbenches gets its own cRIO: no worries!?

---

Hi Gerd

I don't want duplicate the whole Test Bench.

The four test setups should be controlled by one cRIO.

[GerdW]

Hi hrmpf,

---

@hrmpf wrote:

I don't want duplicate the whole Test Bench.

The four test setups should be controlled by one cRIO.

---

I recommend to duplicate the testbench including the cRIO controller.

What happens when you need to repair one testbench (do you need to switch off other testbenchens too?) or when the controller needs work/repair (do you need to switch off all testbenches)?

I guess this was part of your decisions (and you don't need 24/7 availability)…

[hrmpf]

---

@GerdW wrote:

Hi hrmpf,

I recommend to duplicate the testbench including the cRIO controller.

What happens when you need to repair one testbench (do you need to switch off other testbenchens too?) or when the controller needs work/repair (do you need to switch off all testbenches)?

I guess this was part of your decisions (and you don't need 24/7 availability)…

---

Hi Gerd,

the Test setups should run independentliy to each other. It should be also possible to choose how much test setups run, at beginning of the test.

Sure the Availability was part of our decision. Normally repairs are rare. And if repair of one Test setup needed, we can decied if we shutdown the whole Test Bench or one specially Test setup.

[GerdW]

Hi hrmpf,

---

@hrmpf wrote:
the Test setups should run independentliy to each other. It should be also possible to choose how much test setups run, at beginning of the test.

---

You didn't mention how you connect inputs and outputs of your testbenches to the cRIO.

I guess you use dedicated IOs for each testbench!?

Like using a NI9205 to measure valtages and using channels 0-3 for testbench1 and channels 4-7 for testbench2? (And the same scheme for any output signals to control the testbenches?)

Then all you need is one mainVI with as many "units" as exist in the frontpanel. Each "unit" could be a cluster of IO values. In the background you could use (reentrant) subVIs for each testbench and provide each instance some configuration information about the needed IO channels.

(Or you use DQMH and create one clonable module representing one testbench. Then call that module as often as needed.)

[hrmpf]

Hi Gerd,

@GerdW wrote:

Hi hrmpf,

---

You didn't mention how you connect inputs and outputs of your testbenches to the cRIO.

I guess you use dedicated IOs for each testbench!?

Like using a NI9205 to measure valtages and using channels 0-3 for testbench1 and channels 4-7 for testbench2? (And the same scheme for any output signals to control the testbenches?)

---

Yes, I didn't mention how I connect I/O sorry for that.

Exactly you are guess right.

One test setup belongs to four analog input, four digital outputs and some CANopen Messages. 

---

@GerdW wrote:

Hi hrmpf,

Then all you need is one mainVI with as many "units" as exist in the frontpanel. Each "unit" could be a cluster of IO values. In the background you could use (reentrant) subVIs for each testbench and provide each instance some configuration information about the needed IO channels.

(Or you use DQMH and create one clonable module representing one testbench. Then call that module as often as needed.)

---

Ok this is similar to the the second version, I discribed in my intial post. 

Grouping these variables into clusters is a good indication.

What is reentrant SubVis and DQMH?

[UliB]

---

@hrmpf wrote:

Hi Gerd,

What is reentrant SubVis and DQMH?

---

The Delacor Queued Message Handler (short: DQMH®) toolkit is a freely available reference design for LabVIEW. (https://dqmh.org/).

For reentrant VIs see: https://www.ni.com/docs/en-US/bundle/labview/page/reentrancy-allowing-simultaneous-calls-to-the-same...

DQMH uses Reentrancy for clonable modules. You program one clonable module and can use the module several times in parallel.