Complex controller application - Need suggestions!

[Lars915]

First off - I'm a long time LabVIEW programmer, but mainly with instrument drivers and small apps. Sorry if these issues have been covered before, but I'm under quite a time crunch and need a little guidance while I keep researching.

I am putting together an application that controls a temperature chamber for long term testing (30 to 60 days per test.) The application performs logging and UUT status checking at regular intervals and provides a configurable user interface. During the main application loop, the program must read and write several flags, run the timers that control the flags, interact with the user interface, interact with the UUT's, and provide closed loop control for the temperature chamber. It looks to me like I'll be running several parallel loops, an event structure driven state machine, and several user events.

What I'm looking for here is a suggestion on the high level application architecture. I need to monitor three or four flags, set three or four flags, write some data to file, send data to a user interface (similar to the structure described in "A Software Engineering Approach to LabVIEW." Is a central event structure capable of handling something like this while using parallel timer loops to effectively generate interrupts? How stable is event handling overall? Again, sorry if this is old stuff, I have to come up to speed in a hurry. (Oh, this is a slow application with no real time requirements. If I get 15 second response times I'm good.) I'm familiar with several state machine algorithms and am coming up to speed on user events and the event structure.

Hope this isn't too vague. I'm not looking for solutions to the worlds problems, just a general idea as to what architecture can handle a potentially high interprocess communication load so I don't get too far down the wrong road.

[mross]

I would use an Event Driven Queued Producer Consumer. If you want an example, ask.

You might want to mention the make and model of thermal chamber and the manner of communication to it. If it is an older chamber the com maybe serial. This is automatically non-trivial and you may get some help specific to that protocol on this list. At any rate, you will be forced to learn the command protocol for the chamber and this may not be a fast job. If you are lucky the chamber has a beautiful set of LabVIEW drivers to use. In that case it won't be so bad. That odds of that are probably slim.

I have worked with two chambers, Tenney/Lunaire and Cincinatti Sub Zero. Both designed and manufactured in the 90's and not so easy to work with. Both have pretty bad documentation, the CSZ is notable in its crappiness. The CSZ GUI is seriously crapulous (they say they are better now since getting rid of the Eurotherm controller). Usually these companies have some old dude who can help solve specific problems.

If you have an older Tenney/Lunaire I could give you what I was using for a while. It was saddled to a PC that no else could stand to use anymore. It was painful to use and I didn't have the inclination to keep working on it. Tenney did have a better PC interface that the free one they gave me, but I didn't have enough need to justify buying the good program.

Whatever chamber you have it maybe that for a few hundred someone has already written something that does what you want. I can promise you that a few hundred is less than you will spend writing something. If you have to start from scratch you may be in for some long nights for a couple weeks. It will be interesting though, and you will learn something that could be handy.

Mike

[Eugen Graf]

Hello, would you try it out:

http://forums.lavag.org/index.php?act=atta...ost&id=7462

I think it is exactly what you need. You can manage complex applications dynamically. This design pattern supports 4 communication types incl. User Events and Notifiers, but the best one you can debug it remotely over TCP/IP.

Eugen

[Lars915]

QUOTE(mross @ Nov 19 2007, 09:39 AM)

I would use an Event Driven Queued Producer Consumer. If you want an example, ask.Whatever chamber you have it maybe that for a few hundred someone has already written something that does what you want. I can promise you that a few hundred is less than you will spend writing something. If you have to start from scratch you may be in for some long nights for a couple weeks. It will be interesting though, and you will learn something that could be handy.Mike

It lookes like that pattern is the one I'm looking for.Unfortunately, the temp controller is a Modbus based controller with very generic Serial to Modbus converter VI's. I'll end up creating a lot of the stuff I need for it (gotta learn it, we have a few of them.)

Anybody have a Watlow F4 library?

QUOTE(Eugen Graf @ Nov 19 2007, 10:17 AM)

Hello, would you try it out:

I think it is exactly what you need. You can manage complex applications dynamically. This design pattern supports 4 communication types incl. User Events and Notifiers, but the best one you can debug it remotely over TCP/IP.Eugen

That's a great example. It'll help get over some of the initial hurdles of understanding how to implement the pattern.

Thanks!!

[Eugen Graf]

QUOTE(Lars915 @ Nov 19 2007, 06:44 PM)

That's a great example. It'll help get over some of the initial hurdles of understanding how to implement the pattern.

Thanks!!

I think it is not difficult, in the ZIP you will find 4 example clients, one for each communication type.

Eugen

[mross]

QUOTE(Lars915 @ Nov 19 2007, 12:44 PM)

It lookes like that pattern is the one I'm looking for.Unfortunately, the temp controller is a Modbus based controller with very generic Serial to Modbus converter VI's. I'll end up creating a lot of the stuff I need for it (gotta learn it, we have a few of them.)

Anybody have a Watlow F4 library?

That's a great example. It'll help get over some of the initial hurdles of understanding how to implement the pattern.

Thanks!!

I have a MODBUS motor controller so you might be interested in the programming for that. I think there is a CRC, twos compliment and all that, whichmust be dealt with. Otherwise MODBUS was simple enough for me to manage.

[bmoyer]

QUOTE(Lars915 @ Nov 19 2007, 01:44 PM)

It lookes like that pattern is the one I'm looking for.Unfortunately, the temp controller is a Modbus based controller with very generic Serial to Modbus converter VI's. I'll end up creating a lot of the stuff I need for it (gotta learn it, we have a few of them.)

Anybody have a Watlow F4 library?

I checked the Watlow website and they have some drivers for download: On the page http://www.watlow.com/products/controllers/f4/ramping.cfm they have a link for Modbus Driver rev c.zip.

Is this what you're looking for?

Bruce

[Lars915]

QUOTE(bmoyer @ Nov 19 2007, 01:17 PM)

I checked the Watlow website and they have some drivers for download: On the page http://www.watlow.com/products/controllers/f4/ramping.cfm they have a link for Modbus Driver rev c.zip.

Is this what you're looking for?

Bruce

I've got the Watlow VI's, but they all deal with command numbers and values (Modubus commands). I like to deal with english commands so I'll have to wrap them in a higher level layer. No big deal once I get the time to understand the order of operations and all the options.

[PaulG.]

Been there. I've done exactly what you are doing. Some of my earlier ap's ran for days at a time and I couldn't always be around to put out a fire. But for some reason I indeed woke up around midnite worrying about one of my programs ... and ran to work around 1 AM just in time to avoid a "moisture overload".

Stick with a basic state machine design. You can think of 99% of just about anything that can happen and code accordingly.

And if you get nervous ... plan on spending just one evening with your project ... if you want to live in peace ...

LV is automation, and it's very cool ... you can do this. :thumbup:

[hviewlabs]

NI has a LabVIEW Modbus library:

http://sine.ni.com/devzone/cda/epd/p/id/4756

As you can see, people reported it had problems in 8 (and above?) but since the file name is currently ni_modbus8_2.exe, I would assume they have been corrected.

As for the arcitecture, of course, I will not miss this chance to suggest mine:

I found that if we keep separate notions for state, action, and event, think (and treat) the code in the cases of the consumer loop as actions rather than states, maintain separate queues for events and actions, not only it allows creating a more flexible and powerful architecture, but, most importantly, developing code on a higher level of abstraction (when in this state and this event happens I need to do this, this and this action and switch to that state). Please see the following for further discussion and a more advanced architecture:

Despite the pattern discussed there doesn't support hierarchical states (for those implemented see labhsm.com) I found it much more powerful and flexible (yet producing uniformly looking and easily modifiable/maintainable code) than the more primitive producer consumer single queue QSM patterns.

[hviewlabs]

NI has a LabVIEW Modbus library:

http://sine.ni.com/devzone/cda/epd/p/id/4756

As you can see, people reported it had problems in 8 (and above?) but since the file name is currently ni_modbus8_2.exe, I would assume they have been corrected.

As for the arcitecture, of course, I will not miss this chance to suggest mine:

I found that if we keep separate notions for state, action, and event, think (and treat) the code in the cases of the consumer loop as actions rather than states, maintain separate queues for events and actions, not only it allows creating a more flexible and powerful architecture, but, most importantly, developing code on a higher level of abstraction (when in this state and this event happens I need to do this, this and this action and switch to that state). Please see the following for further discussion and a more advanced architecture:

Despite the pattern discussed there doesn't support hierarchical states (for those implemented see labhsm.com) I found it much more powerful and flexible (yet producing uniformly looking and easily modifiable/maintainable code) than the more primitive producer consumer single queue QSM patterns.