Labview architecture and design for general purpose system (help!)

[johnnyt]

I'm developing some new software/hardware systems for use in research laboratories.  Many of the tests that are done range from very high channel count, multiple PID control, down to a simple thermocouple feedback controlling a hot plate.

The challenge is to develop a somewhat general purpose system that can do the big stuff and the small.  A laboratory may contain 12 small systems or one large system.  Due to cost and space constraints, it would not be possible to install 12 computers, monitors, keyboards and 12 Fieldpoint chassis.

So the idea is to go with one Fieldpoint or PC for the large system and share a Fieldpoint chassis for the small systems.  For 12 stands, we may purchase 3 Fieldpoints and do 4 tests on each Fieldpoint all talking to one PC located in the lab.

Right now, I'm struggling to find the best way to architect the program to be this flexible and reusable.  I may be asking too much, but I thought I would toss this out there to see if anyone may have some tips on structures, such as using events, producer/consumer, queues, notifiers, tcp/ip communication etc...

I'm leaning towards an Event structure for the UI with communication to the hardware using TCP/IP.  I may even communicate TCP/IP for hardware running on the UI pc.  Any thoughts would be highly appreciated.  Thanks.

Here's my wish list:

User Interface (UI)

I'm looking for something that can handle 1 to 12 test stands at once, selectable at startup.  The UI will be responsible for display, graphing, performing calibrations, loop tuning, starting/stopping tests, test monitoring, test setup, hardware communications, and data storage.

The UI will run on a PC.  The UI can interface to hardware in three configurations: hardware running on the UI's PC (such as USB), hardware on a separate PC (using TCP/IP), and to multiple Field Point remote devices (again with TCP/IP and possibly a router). 

The UI will not be critical to test operation (except if the hardware is installed on the UI's PC).  In other words, I can turn off the UI's PC and the remote hardware will continue to run the test until data logging ability reaches its limit.

Hardware Interface (HI)

The hardware interface will perform all hardware I/O, PID control, test sequencing, safety shutdowns, error handling, limited local data logging, UI data for screen updates, and data transfers.  The HI will do the logging real time and transfer blocks of data for storage on the UI pc. 

The HI must be able to run 1 to 4 test sequences at the same time.  Due to the costs of Field Point hardware, it would be too expensive for each test to have its own FieldPoint brain, so we need to share.

[Matthew_Williams]

Hi Johnnyt.  Sounds like a fun project.  We have done similar projects with multiple FieldPoint controllers
reporting back to a central pc.

You are on the right track with an event structure driven UI.  Take a look at queued state machine concepts
as well, especially as relates to talking with the hardware engine.

My suggestion would be to completely isolate the date management (sensor to disk) portion from the UI (disk
to user) portion.  That way you can have multiple, plug-in 'hardware' managers (local i/o, remote pc i/o, fieldpoint i/o)
with the same UI.  It also makes it easier to move to multiple, simultaneous UI instances, if that becomes
a requirement.

One of our current development projects uses a Node Engine on a workstation to communicate with FP
nodes and stash the data into an SQL (local or networked) server, a Workstation Client to handle the UI (same
pc as the node engine or another) and then smaller, specialized apps like the Notification Client to handle
specific tasks.  The FP nodes queue data as it is generated, then upload it to the Node Engine via shared
variables.  The Workstation Client(s) never needs to talk directly to the nodes (hardware), just the SQL server, which
makes multi-user a snap (well, not completely, but very close).

Hope that helps some.  This isn't a trivial undertaking 😉

Matt

[johnnyt]

Thanks, Matt, for all the ideas.  I've read a bit about shared variables.  They seem interesting.  I will look into the Node Engine, that's something I haven't heard before.

Yes, the project will be very large, but I would really like to get the software design and communication figured out first.  Once I understand how things will communicate, then fillng in the blanks will not be as bad.

[Matthew_Williams]

The Node Engine is an application that we developed; not sure if that was clear.  It
isn't a component or function of LabView.

Design first is a very good approach.  Sure wish everybody did that!

Good luck with it, let us know how it goes.

Matt

[Emm]

JohnnyT  Have you managed to physically control the hot plate's temperature knob?  I'm trying to do the same -- I can program it.  I'm trying to set up the physical part.  I'm considering a toy's DC motor, but I don't know how to make it run in both directions, to turn the temperature down.

Thanks! 

[johnjt]

Emm: for the hot plates, we had to open the case and intercept the wires going to the heating elements with a solid state relay.  I then wrote Labview code to turn the relay on and off based on temperature, using a pulse width modulated technique.  The hotplate will still work as a safety shutoff as long as you do not interfere with other wiring.