Its working just fine but does it look good? Take a look and give me your advice!

[HFZ]

I got to say that this is my first finnished labview program, and  it's working fine, almost no problems. But i'm not that shure about

this huge while loop with all its instructions. Normaly a while loop takes 1 ms to iterate once, but this loop takes more than one ms,

I'm using another subVI to catch data up to 5 ms. / sample as output from measurement device to  the while loop in this Sub vi, and then from this sub VI i'm initializing the data value read from the Measurement device, to a global variable that i read in this huge while loop.  I belive that the subVI while loop iterates several times before the huge loop iterates once. Meaby thats why my graphs for the data are plotting more than one data at a time.

Take a look and give your advice, it seems that all the measurements are well. And I don't really got problems with the program when running, exept from small delays when I switch the sample rates.

Regards

Zamzam 

[TiTou]

quick advise without really talking about how it is coded :

  - you certainly  agree that it looks a bit like spaghetti, no ? So, the first basic goal, should be "make it more readable"
  - then, what if next week you have to add a new function ? Second advice "make it modular", I would advise to work on the architecture (state machine)
  - some operation don't have to be performed at every loop execution...
  - I also think you can use less local variables and less property nodes

By the way, have you read the "LabVIEW development guidelines" ?

Hope this helps

[Ray.R]

I agree with Titou.

Wow!  That's an eye-full. 

There are some functions like setting audio On / Off that may not need to be in there.  Or do they?  You'd have to describe what the loop is supposed to do.  Same comment for the indicator display settings on property nodes.  Do you intend to turn them on/off a number of times during an iteration of the loop?

You should "divide & conquer".  By that I mean, use sub-vi's that are function specific.  As mentionned by Titou, you should have a look at the development guidelines.   Basically, now that you have a working loop, you can improve it by creating some sub-vi's, revisit some items that may  not need to be in the loop.  As a matter of fact, you could create some control & indicators and maybe transform the loop into a sub-vi as well.  🙂

There are many Case Statements that you could convert to sub-vi's and that way, you could eliminate the global variables by using indicators and wiring directly to them.

However, I would have to say that the value for "Write Flow Data" might become unpredictable due to race conditions.  Revisit how the value(s) are set for that one.

But it does look like you had some fun doing this one.  Which is the most important thing.  To have fun implementing solutions with LV. 🙂

Happy wiring!

JLV

[ian_fung]

Hi,

Just being busy-body 🙂 Our two gentlemen had already pointed out many useful advise.

You might wanna consider the followings:

• use subvi whenever is possible (especially for code that is repeatedly use)
• use expandable structure (i.e. queue event structure etc. with that only intended case(s) will be executed at any one time)
• use Enum instead of Ring control for case control. It is more readable with Enum as each case will be named according to Enum item, rather than merely 0,1,2...

Attached is a very basic queue-event structure for your reference. hope it helps 🙂

Best regards

[chrisger]

hi there

your first LV app and you're using unitialized shift registers and an event structure? well, not that bad in my opinion...! i've seen code much worse inside vi.lib:-)

in addition to the others i suggest to use the event structure whenever it's possible instead of polling controls. that will improve your apps performance. then i recommend to use these famous FGV (fuctional global variables or LV2 style vis. search this forum for more information) instead of global variables. once you have learned how to deal with them you will always use them (well, so do i). i attached an easy example (a picture says more than 1000 words..)

[TiTou]

Ian... Why don't you follow your own advice in your example ?

Using a string as "case selector" can be source of error... I'd put a typedef enum instead for maintainability... 😉

Sorry for being a pest

[ian_fung]

My apologies...

I quickly created the VI for queue structure... and when I mean enum, I am talking about for those Ring controls that already in his VI.

I have queue structure either using enum or string array. I'll leave it open.

Thanks!

[HFZ]

Thanks for response all off you

It seems like I gotta use more time to the program. It happens so that Each timeI was finnish with the Program, My advisor came with other wishes

to the program, and so on, so more and more things was added on and on. I've read the usermanual for labview, but not enough in how to make a good structure for my program.  Meaby I need more time and experience  with labview. But ne thing is for shure, I had a lot of fun developing the program,  as you said,

A spaghetti menu it setainly is. 

Thanks for all help ..

Zamzam

[daveTW]

Hi Chrisger,
why do you insist in "strict type def" in your example, I always thought that the non-strict would be good enough for this?
Dave

[chrisger]

yes, you're right. just a confirmed habit.