Can someone please check my VI??

[Bunny]

Purpose of the VI is to generate  and random numbers on graph, and also to compute the average of the random numbers.

Since i am a learner, i want someone to check it for me.

Thanks........

[TimoS]

hi bunny,
delete the time delay, theres no need for it.
so the for loop runs "faster"

[Bunny]

Ok, Thanks...otherwise its fine??as per the requirements of the VI

[PJS]

Yes, it is fine.  As a general rule of thumb, if it works....

As with any language there are good habits and bad habits.  Your VI is pretty simple and works as it should.

Now for constructive critisism:

1. Try to minimize unneccessary bends in the wires.
2. Apply comments to your code.  You can utilize the Free label decoration in the decorations palette, so as to provide for a standardized color...but feel free to adopt your own color codes.
3. Do not create unneccessary tunnels in loops as it will create increase your memory allocation.  In your example you ran the same data out twice, thus causing twice the memory to be utilized.
4. Get used to using the error clusters.  If a VI has error out, it should be wired.  You can also use these to sync your data flow (error out to error in.)

Once you get better at this and in the short term, I would also recommend the following.

1. Standardize your naming conventions for VIs and sub-Vis.  Usually very descriptive names are better.
2. Turn off the automatic error handling in LabVIEW.  You should control when and where errors are handled.  Some errors are OK and can be handled by your application.  Auto error handling will put up a prompt every time an error is passed out.
3. Turn off the auto-wiring and auto-wire routing.  This usually leads to unnecessary bends in wires and frustration from LabVIEW wanting to wire to the wrong terminal, especially when they are close together.
4. Use the VI icons.  Set the default font in the Icon editor to small fonts 10 point and at least type in some text.  If you are a creative individual, draw pretty pictures.
5. Always include extra terminals when setting up the inputs and outputs to allow you expandability without having to re-compile.  I personally perfer the 10 or 12 terminal block as it is nice and symetrical.
6. Always, always, always document your VI and what it does in the VI documentation property.

I could go on and on, but this should be enough to get you started.  Remember, good habits are easy to follow, bad habits are hard to break!

My $0.02

[Bunny]

HI,

This is a great great help. I appreciate that, coz. this information i wontuse fr 1-2 vi's, but forever. NIce idea to learn more about LV. I would definitely do that. thanks alot......

Bunny

[tbob]

I somewhat disagree with Paul's suggestion of turning off Auto Error Handling.  I agree that you should write your code to handle all errors that can occur.  That is proper programming and is an elegant way of handling a situation that would otherwise crash your program or cause some mischief.  By leaving the auto handling on, you can catch any error that pops up during development, and install code to handle the error.  After development, it is still a good idea to keep auto handling on because there may arise some condition that causes an error, and that condition was not anticipated.  You may have a problem or may get bad results and not even know it.  Or you may have a crash and have no idea what caused it.  I always keep auto error handling on and let the messages pop up.  But I have trained myself to fix each error as they pop up to the point that I don't have any errors in my final code.  Since noboby is perfect, I am covered if some error that I have not foreseen should arise.  This is a matter of personal preference, and not everyone would agree with me.  You choose what you think is best for you.  I don't like surprises and I don't like not knowing what caused a problem so I leave auto error handling on.  At the same time, I strive to not having any auto pop ups due to errors.

[PJS]

I may have needed to be more clear on this point.  If errors get passed along that are not handled by code, by all means, pop up an error.  Usually, my top level VI has an error handler with a message pop up.  Sometimes, depending on code complexity, I may have many VIs that have error handling pop-ups.  HOWEVER, if you use the auto-error handling to do this a couple of proplems may happen.  One, if your error happens in the middle of a DAQ acquisition, depending on who generated the error and such, you can then cause a buffer overflow or other similar nasties.  Second, since some errors are intentionally caused, you do not want a pop-up happening for a situation that you are prepared to handle.  For example, I wrote a VI that goes through a directory structure and insures that LabVIEW components are properly documented.  If I try to open a VI reference to a non-LabVIEW file, a specific error is generated.  I do not want a pop-up everytime telling me about this, rather I simply ignore that specific error code and go on to the next file.  It was a down and dirty way to acomplish the task, but it works well.  So well, that it is getting upgraded to a full blown app for use here (in which case, the file list will be pre-sorted.)  This may or may not have been a good example, and there are other ways of having handled the issue, but it was a  real life instance of intentionally handled error handling.  Again, error handling is just good sound programming, so it MUST be handled one way or another, so as to not cause the problems listed in the post above.  The Auto-error handling can be useful during debug, to be sure, but after about two weeks of using it after it's introduction in LabVIEW 7, I had to turn it off as error messages were popping up from the far depths of the code and had me looking in the wrong place for the cause.  As with most preferences, it is up to the user/programmers discretion. 

Do what feels right for your situation.  If it doesn't work, then you are aware of alternatives.  When it comes to programming, there are always 10 ways to skin a cat (ok, not politically correct). 

Happy wiring!

[tbob]

Great comments, Paul.  Every programmer must weigh the options and choose what is best for their needs.