Selection of structure.

[labmaster]

My application is to collect data after initializing.

All user interface were treated by simple "event structure".

When the user push the GO button, the application goes to long sequencial loop.

--- Initialize(time out event) ---
1. Open initial parameter file and treat it
2. Hardware initialize
3. Periodic hardware monitoring(transfering single data) periodically

--- Treat user interface (change value event in each button)---
1. Various resoponses(hardware connection & file name setting)

--- Go measurement ----
1. Prepare message for message box in various conditions
2. Check the elased time (while loop): 1 sec period
3. single measurement
4. step 2 & 3 will be repeated inside (while loop)
5. save the collected data
6. go to timeout event step 3.
>>> Go measurement is very complex using several sequence and while loops as you can see in the attachment.

Therefore the overall LV code was very complex in "GO" event.

My application will be update more in near future.

I believe this is not effective coding for next work.

During my taking in NI regular course (Basic and Intermediate),

I got to know some considerations for the good programming.

But the application was coded before the course.

I would like to remove the multi-staged sequence loop in GO event structure.

But I think It will be very heavy work.  Therefore I want to ask you prior to start to modify.

Would you please reccommend me which structure(event, user event, state machine, queue, producer/consumer) will be suitable to my case?

Any comment will be welcomed.

메시지가 08-25-2007 02:41 AM에 labmaster에 의해 편집되었음

[andre.buurman@carya]

As far as I can see now is that you need to detach the UI from the functional code.
By putting the functional code in a separate loop. This will require some inter loop communication (e.g. queue).

To be able to answer the question, please post a zipped HTML print of your block diagram, so the complete code for the GO event is seen.

Regards,

André

[mikeporter]

There are a number of problems in your code. (in no particular order)

1. All the icons are the default image. This makes it impossible to even begin trying to figure out what the code is doing.
   
2. There is no error handling. I find in inconceivable that in all that code there would be no places where an error might need to be either generated or responded to. Error are data too - in fact it may be some of the most important data in your system because it's what tells you whether you can trust the test results you are getting from the system.
   
3. You need to get rid of the sequence structures. Sequences as you are using them are never necessary and are just bad design. Moreover if you haven't already, you'll soon find out that they significantly increase the problems you encounter debugging and maintaining the code.
4. The block diagram is much to big. You are probably trying to do too much on one diagram. You have some subVIs you may need more - or at the very least a good code reorganization.
5. The wiring is messy - yes neatness counts. Neatness directly impacts readability and readability impacts cost of maintenance. Poor readability is one of the big reasons that maintenance costs go up over time for most programs. For well-designed and well-maintained code maintenance costs (and effort!) will remain essentially flat throughout the lifetime of the application.
6. Spell-out labels. They may take up more room, but they more than pay for themselves with improved readability.

Once the code is cleaned up we'll be able to tell whether it needs a separate loop like André suggested. Depending how much time is spent actually doing stuff - as opposed to waiting for timeouts to expire - you might be able to build the "Go" logic in a state-machine built into the timeout case of the existing structure. If the processing is intrusive enough that it effects the operation of the user interface, it will need to go into a separate loop.

Mike...

[labmaster]

Here is the whole structure written in HTML file.

Please comment the structure format.

Regards,

[mikeporter]

The comments are the same as in my first post. Until the code is cleaned up I can't tell what our code is doing or intelligently comment on its structure. One new comment is to use a single Format to String function instead of the dozens of string concatenators. It takes up much less room, makes it much easier to see the string that is being assembled and reduces the likelihood of error in assembling the strings.

Mike...

[andre.buurman@carya]

I really have to agree with Mike.

Some extra pointers for reducing the amount of wiring.

Try using more LV2 style globals or action machines.

Identify data types (also look at combining individual variables into cluster, e.g. all variables that are related to measurement configuration.)
Identify common operations done on the data in different places in the code.

For readability, convert stacked sequences to state-machines with meaningfull state names or flatten the code and put it into a subVI.

Make enums type def, in this way a change to the enum propagates through the code and case names are readable at no extra cost.

Kind regards,

André