Best architecture for testing multiple (8) serial devices

[BernieSAIC]

I am not new to LabVIEW but am being tasked with a challenging project I want to be prepared for as best I can.  I am familiar with Event Structures and State Diagrams but feel these may not be adequate for the following specifications:

1.  Most likely 8 serial devices need tested simultaneously

2.  Tested every 2 hours for 48 hours

3.  Records for each one must be created and saved at each interval

I want to learn Queue's etc and am thinking a combination of producer consumer and the above two mentioned may be required.

Any basic architecture recommendations that may work would be appreciated.  FYI, I have never used Producer Consumer.

Thanks

[JÞB]

You are going to want a Producer-Consumer archetecture here to allow for scalability of the "common" portions. 

I'm thinking a event driven producer enqueueing "test" commands (with address data, a referance to a status cluster (on the GUI) and options) to a selectable number of consumers operating in parallel.  (esentially 8 instances of the same, reentrant "Test Serial Dev X with Options.vi" - don't forget to make it re-entrant and do not share instances).  Additionally- the UI would have a cluster of status indications for each cell that would be updated by each "test" instance.

You should be able to debug on one cell and scale up- pretty easy with this aproach

[tbob]

Software architecture will depend largely on hardware architecture.  In a previous job, I tested 48 sensors in parallel and my software was a plain old state machine.  One test at a time.  The hardware is what drove the parallelism.

Will you have 8 different serial ports, one for each device under test?  I can't think of any other way to do this.  Will each test run simultaneously?  In other words, will test 1 run on all units, then only when test 1 has finished will test 2 start, etc.  This is synchronous testing.  A simple state machine would do this.  But if the tests are asynchronous, meaning device 1 can be on test 1 while device 2 is on test 3, then you would need a producer-consumer with queues and re-entrant subvi's.

So you need to describe your hardware setup to better get an idea of software architecture.

[cirrusio]

As tbob pointed out, the architecture will be fully dependent on the exact details of the problem.  That being said, I do have my two cents to put in.  In my work, I deal a lot with serial communication (too much, in my opinion); in some instances, I am dealing with the same device on different machines and in other instances, different devices talking on different ports on the same machine.  Regardless of what the implementation is, you will find that there is a lot of commonality to be found in serial IO (open port, close port, configure port, send ascii command, receive ascii data, block simultaneous attempts to R/W, etc, etc) that is really independent of implementation.  To me, this just screams for an object-oriented approach.  The ability to reuse or change the details of the code while limiting changes to the interface itself is awesome.  In your case, if you have 8 similar devices, I see 8 instances of a class which inherits properties from a Serial IO superclass; if we are dealing with different types, then you can exploit the inheritance features of objects to basically call 8 instances of different children of the Serial IO superclass. 

All that being said, I think some of the details are missing as tbob pointed out.  However, instantiation of 8 objects will prevent some of the issues that might be associated with asynchronicity as all of the properties and methods would be associated with an instance. 

Anyway, that's my thought.  Give me another week or two and I will probably have an example of this up.

Cheers, Matt 

[BernieSAIC]

Unfortunately I am uncertain of most of the hardware involved (I just got wind of this today).  Government property so I can't give most of the details but I will update the thread tomorrow after I get more information.  Until then I will be practicing withthe producer consumer and familiarizing myself with reentrant subvi's.

Thanks for the replies thus far.

[tbob]

You should also get familiar with LVOOP as Matt suggested.  He has a very valid point and a great reason to use OOP.  One serial class, 8 children of the same class.  Sounds like the way to go to me.