Application Structure Advice - preplanning

[DL84]

Hi all -

Thought I would get some advice from you before starting up a new project.  Not really how to do it, just which structure to use...

Originally I took over a project at my work that is very unresponsive and the way its coded it cannot accurately do what we are going to want it to do down the road.  I've tried to tell myself it wasn't needed, but I'm going to have to just recode the whole thing.

After just going to the labview intermediate classes, i'm a bit confused as to which scheme would work out better for the application...producer consumer w/events or producer consumer w/data...

Basically the program is a final test that is completely automated on one side.  So the user interacts by inputting serial numbers, models etc. that change the procedure of the test cycle.  Communications are at a slow 1200 baud over serial and the test per unit takes about 2-3 days.  Slow speed monitoring is required on few indicators.  Thats about it on that end.  Also though there is an entire manual test capability, that tries to give real time results back about what's going on with our test unit.  Currently it allows for us to change settings on the test hardware programatically...again through the serial port.

Later on down the road we will need to start using DAQ equipment to enhance the testing.  At present there is about a 7-8 second delay from when you hit a control and something happens.  Granted the communications are extremely slow, but still c'mon now thats just rediculus lol.

Any recommendations on the kind of structure that should be used to control this?  Currently its being implemented as a huge state machine with 8 or so states.

[Nadim R]

Hi,


I would architect your application as follows- I would do a producer/consumer loop with a state machine.  The producer loop will send commands and recieve commands from the test devices, whereas the consumer loop will do processing on the data that has been received from the test device.  A qucik overview of a producer/consumer loop is shown here in the devzone article.  There are several ways for you to send the data to the consumer loop- queues would probably work in your case, where the quese will fill up with the data that is received from the test device.  Are you planning to change communication protocols away from serial?  If so, what kind of protocol are you planning to use?

I hope this helps

Regards,

Nadim
Applications Engineering
National Instruments

[mikeporter]

Something I believe in is that the hardest part of any new job is figuring out how to think about it. So I like to start by getting as much as possible on paper before I start coding. To begin with, you need to know what the desired User Interface is like. How do the operators want to use it? What will be the desired workflow for the tool? What are the response time requirements.

At the same time consider the system from the standpoint of the physical process that you're interacting with. What are the operational constraints? What are your users going to want to do in the future? What are the inputs and outputs? What is the instrumentation like? What sorts of errors can occur and how fast do you need to be able to respond to them? How do you recover from errors?

Finally, what data are you going to be collecting? How fast? What are you going to do with it? Is the customer expecting a report of some kind? What is the data's lifespan? How will results be archived and managed?

The reasons for asking these questions up front are two-fold: First, the answers to these questions (and a bunch more) will provide the nucleus of a document that will tell your customer exactly what they will get and you exactly what you need to do. Second, it should be obvious that there is no "best" universal system architecture. Each possibility has its own advantages and disadvantages. Knowing the answers to these questions will help you understand your problem and the best architecture for that particular problem. The biggest messes I have ever had to deal with (and in 20 years I've encountered some real architectural train wrecks) resulted from people deciding ahead of time what the system architecture was going to be and then trying to force-fit an application into a structure that didn't suit it.

Most important you need to sit down and have a heart-to-heart talk with your boss to set their expectations. If you do this right you may not develop any code at all for a couple weeks and if your boss is the type that "wants to see results" you need to educate them on what the results will look like. Sometimes its code, sometimes its documentation - but in either case it will be moving the project forward. And if your boss should acknowledge that "theoretically" working in this way is best, but then goes on to say, "...we don't have time to do it the right way..." Save yourself some time and start polishing up your resume now... it won't be long before you'll be needing it.

Mike...