What is the best way to achieve the following

[Lloydy]

This is a real situation.

We have been asked to write the software for an automated test.

The equipment consists of 6 test stations (but it could be 7 or 5)

Each station will test one sensor

Each station can start the testing independant of the others

Each station will have a set of valves to control the gas flow

All the above is connected to a compact DAQ chassis and one PC.

We have thought about having one process that reads the inputs from all test stations but how do we get the relevant data for each test position?

I would welcome any ideas

Thanks

Ian

[swatts]

What we have done before is have a test component that drives the test equipment based on settings from a configuration file.

In this case the settings will  be a task based affair reliant on the system number.

Make this test component re-entrant and have as an input the test system number and any other settings.

If sharing of hardware resources becomes an issue you can always queue them up through a centralised queue system, similarly filing and displays can be queued up centrally.

Hope this helps.

SWatts

[Swinders]

OK so I understand that we can have a re-entrant test component will allow the system to scale and using a single queue (that's one queue not a single element queue which would be silly as you'd loose data or lock parts of the system) to send requests to the hardware.

This works fine for setting DAQ controls but when we need readings to be passed back to the test component I'm thinking of something like creating a queue for each test position and the hardware interface loop passing the relevant data back up through these. Does this make sense or is there a better method?

[swatts]

I'd only use a queue for hardware if you can't set tasks for independent tests.

With regards the queue for displays, it's a design decision based on number of updates to the display per test system, if the queue is running red hot maybe you need to split it. My feeling is a single display queue where you pass the test system identifier as part of the queue element data. This could then update the relevant parts of the display.

[Swinders]

I was only thinking of a single queue to update the front panel, the multiple queues idea was for passing the measurement data back to the test components (re-entrant vi, multiple instances to run the same test accross a number of test stations).

So we would be looking to have two main queues, one for hardware and one for the front panel updates.

When a start condition is encountered (could be hardware or onscreen button, not decided yet) a new test component is started which uses the hardware queue to trigger various valve sequences and take readings from the DUT. Depending on the readings taken, the timings for parts of the test may change so we need to perform some simple analysis of the readings during the test. The method to pass thes readings back to the test component was the thinking behind multiple queue.

At the end of the test sequence the front panel queue would be used to show the result for the relevant test station.

For taking the measurement we are looking at the cDAQ Chassis with an NI 9205 32 channel AI module. The thinking behind having one task is all inputs could be read at once rather than individual requests from each test component. The correct measurments would then be routed to the required test componet if it was running.

Does that make sense?

[swatts]

Sounds good to me,

Alternativel Adrian has a plan involving dynamic spawning if he gets a chance to describe it .

[Swinders]

Just googled 'dynamic spawning' and it came back with Zombies... sounds interesting.

Thanks for your input Steve.

[CRoebuck]

I like Adrian's idea. Spawn off a dynamic components, one for each test socket, all instances feeding back into a centra "hub" via some sort of inter process messaging construct (queue unless you're hammering it)

If they're independent then make the central hub responsible for the life time of the queue. It passes a queue ref to each instance of these test clones and says "talk to me down this if you want to"

[Tark]

OK, so I'm not a great fan of dynamic vi's but in this case it was the best solution for the job.

We had several (potentially any number) of ethernet pressure scanners on a network and we had to collect data from all (at whatever rate they chuck out data).

So, for every node we spawn a vi instance from a template, they start up and start collecting data from the corresponding node, and then put this data onto a queue.....the data is marked with the node number so that the consumer knows where the data has come from.

The consumer vi then collects the all the data from the queue.

So, I guess this could do the job for each test station. The queue can work in reverse if you want to send commands to the stations.

[Jpina]

Hi,

I had a similar situation, we had 4 units that had to run in parallel and one DAQ card collecting the data. These units could re-start test cases in case of failure and then for other cases test cases I needed to synchronize them.

As SWatts says I did my VIs re-entrants and I launched them asyncrhonously. To solve the problem of collecting the test data I created a class with this purpose and I send a new instance of the class to each call of the re-entrant let's say "controller" doing this I had a each test data in a different memory space and I could collect the data when the execution of each test finished using the "wait for asynchronous call".

The biggest problem though was to access to the DAQ Readings simultaniously, to solve this problem I decided to create a task that was reading all the analog inputs that I needed and placing then in a FIFO that was storing about 5 seconds of data (which was more or less the maximum amount data I could need). Finally when any of my test needed the data I passed them a reference to this FIFO so they could access to the data.

I hope this helps.