Error, in Getting started with Labview. Chapter 3, part 4.

[Dennis_Knutson]

And even the Express VIs can be made to look consistent with the error in/error out in logical locations. Right click on one and select 'View As Icon'.

[Mark_Yedinak]

---

Ravens Fan wrote:

Deciding to abandon LabVIEW because something like an Express VI looks one way one time, and slightly differently another, is a pretty poor excuse.

Ultimately, you really want to get away from Express VI's.  There great for getting some code up and running quickly, great for newbies, and they can be configured to do a variety of things, but in the end, you'll find you want to do something more advanced than what the Express VI can handle.  At that time, you'll start doing some real programming with LabVIEW with the real functions.

---

I agree wholeheartedly. LabVIEW is an extremely powerful tool. Deciding it isn't good enough simply because of an inconsistency in a tutorial seems a bit extreme.

Also as Raven said you should avoid using Express VIs. I am very happy that I started with LabVIEW long before they ever existed and therefore never got into the practice of using them. You need to understand that Express VIs are basically UI wrappers around real code that make configuring properties easy. If you really want to learn LabVIEW drop the Express VI and convert it to a subVI. Then look at what i actually going on inside the VI.

[JÞB]

---

LandyRover wrote:

Nope..

I

Again, I've been involved with PC's and other similar stuff for decades now, it's just LV I'm new to.   Little errors in documentation, can seem trivial, even irelivant, for those who know the system already, but are often confusing total show-stoppers for new users, who don't know their way arround.

In my industry, little errors like that, can create huge costs when you applying inapropriate stimulus to something, and blow it up by, because you followed bad (or just plain confusing) instructions.

---

LandyRover,

It almost sounds like you want to learn LabVIEW development in 30days from a self-paced study.  That's particularilly unrealistic!  The "Getting Started" exercizes are a Great intro to the LabVIEW IDE however, they are designed to give you a nice feel for the power LabVIEW has while focusing on the fact that you do not need a Software Engineering degree to put together a simple Virtual Instrument. 

 I have to be honest here, I've used an express vi's only a handful of times-  they didn't exist when I learned LabVIEW and I'd rather just code the functions from the programming pallate. ButI do know a few things about the IDE that may explain some of the behaviors you see.

There is a LabVIEW.ini file that contains many USEFUL settings.  You can edit most of those setting from "Tools>Options" in the menu bar.  I would encourage you to explore this after pressing <ctl-H> (ctl-H displays the help window.)  It sounds as if the default settings for "configure express vis immediatly" and "place structures with auto-grow enabled" may have changed to the point where this type of behavior for new express vis could happen.  

I'm kind of curious to know if any combination of these settings would resolve (or worsen) this interaction.  Anyone got the time to dig?

[LandyRover]

Hi Ravens Fan.

Good post, kudos given, thank you.

I just wish others could explain in as much well thought detail as you can.

Anyway, I got past that stumbling block (things already showing etc) and now have something that has stopped me dead.   When I eventualy got the Write to File part of the exersize working, automaticaly saving values to a file all the time the "program" runs, no problem (can create large files!)   So I progressed to the next part...   "Saving Data When Prompted by a User"  (page 3-15 of the Getting Started document)

This works fine, but only once!  Subsiquent clicks on the "Write To File" rocker switch, bring up this.....

The error "wiring" is me trying to figure out what is happening.   If I put an error indicator on the "error out" of the "Write to file" VI, the program does not stop, it continues, but no more values are written to the file, the "Saving Data" indicator does not flash, and there is a fleeting error (way too quick to catch) shown in the error indicator (not shown on the above, so I can post this stop error message.)

The file path and name is fine (after all, it has created the file, and written one value to it previously just fine, several times now in fact) and even without the "error in" wired, it still croaks.  The file is not locked, and can be opened in Notepad or Textpad just fine, finding exactly what is expected, except for the fact that there is only one vallue added per program run.

So, what input is invalid?  It's obviously upset about something, but what?   How does one find out "Exactly" what it's complaining about?

This is the last part of section 3 in the Getting Started document, it then goes into section 4, all about communicating with instruments.

As to "giving up just because a VI user interface does not work as expected each time".  Well, there is only so much time in the day, and this is intended to be an addition to our already vast number of strings to our collective bow.

As I explained before, I don't just sit in front of this PC all my working days (though some seem to think I do)  We have other work to do that brings in the money etc.    So far, this "45 minute exersise" has taken me well over 8 hours time over several days.  Purely because I'm forever finding things that don't work as advertised, work counter intuitively, or are just plain different each time you do something.

For a "newby" (to LabVIEW, but not PC controled "systems") this is just too time consuming, and as my colegue said, does not give one a "warm fuzzy feeling" as to the quality of the code crafting that is going on behind the scenes.   Belive me, we can appreciate the complexity of it all, but there would appear to be much more "functional" QA testing needed to nail all these things down once and for all.  But sadly it seems to be left to the users to do that.

Parden me for breathing, but it all has the feeling of being very much a work in progress academic system, not a tried and tested industrial control system, that it is often advertised as being.

Thanks again for your time.

Regards.

Dave B

[LandyRover]

Mark..

The problem is that the "Getting Started" document only calls out "Express" VI's, as far as I've got anyway.   Maybe that is the cause of the trouble.  Bad information?

Dave B.

[LandyRover]

Jeff..

I don't in any way expect to "learn LabVIEW" in it's entirety in 30 days, not that I can spend 30 real days in front of it anyway.  As you say, that is unrealistic.

I do however expect the basic introduction information (the infamous "Getting Started" guide) to be wholly accurate and thoroughly tested so that if you follow the instructions to the letter (with a default install of the IDE) everything will work exactly as it says, each and every time.  Is that too much to ask?

If the "Express" VI's are less than recommended items to use, then why have them?

Regards.

Dave.

PS: I remember "programming" with switches and lightbulbs.  If a bulb had failed, it sometimes got interesting.

[LandyRover]

Yes Dennis!

Consistantly small icons.  In's to the left, Out's to the right.   I can see that can be good for large crowded diagrams, but not for us newbies, yet.

Dave.

[JÞB]

---

LandyRover wrote:

Jeff..

I don't in any way expect to "learn LabVIEW" in it's entirety in 30 days, not that I can spend 30 real days in front of it anyway.  As you say, that is unrealistic.

I do however expect the basic introduction information (the infamous "Getting Started" guide) to be wholly accurate and thoroughly tested so that if you follow the instructions to the letter (with a default install of the IDE) everything will work exactly as it says, each and every time.  Is that too much to ask?  Not really too much.  NI probably could have done a better QA on the Getting Started.  Regardless- I'm interested to learn if you are grasping the concepts of using LabVIEW that the tutorial exposes you to?

If the "Express" VI's are less than recommended items to use, then why have them?  For this exact purpose - LabVIEW is not only a programming language it is a GRAPHICAL programming language.  This allows just about anyone to be able to understand (almost intuitively) the symbology of the program.  So since its easy to understand why not cater to the demographics of students, hobbists, and business needs that are of limited scope.  Express VIs meet these niche market needs, in a manner no other IDE can come close to fulfilling, without a single sacrifice to the high-end utility LabVIEW does offer.  In effect, Express VIs, broaden the market that can use LabVIEW and encourage scientific academics.  In all- pretty worthwhile. 

Regards.

Dave.

PS: I remember "programming" with switches and lightbulbs.  If a bulb had failed, it sometimes got interesting.  

---

Comments. in italic above

Still, from your posts and the AR UK web, it sounds a lot like you are triing to meet a real business need.  Specifically, a test and measurement systems architecture that is robust yet has a minimal development cycle time.  From my experience (20+yrs in electronics testing) you are looking in the right place - LabVIEW meets that need like nothing else.   I might suggest that you may be a bit cross focused by attempting your evaluation of the tool without a good book or an intro class.  In fact LabVIEW has a wide acceptance in the test and measurement industry (it pays my bills) and few Test Equipment manufacturers can afford to ignore writing LabVIEW drivers for their devices.  The fact that you post at all shows that you recognize the value of other peoples knowledge, why not grab a book or a class to leverageyour evaluation of this new-to-you tool?

[Mark_Yedinak]

Dave,

In one respect it appears that you have already made up your mind about LabVIEW. I would recommend that you try to at least be open minded about it and not look for fault at every step along the way. I will confess that I have never gone through the "Getting started" tutorial so I can't comment on how well it is designed. One area that I believe NI has failed at is the marketing hype that anyone can pick up LabVIEW and program an application in 30 minutes. I have found that I can develop faster in LabVIEW than any other language (assembly, C, C++, Tcl/Tk) that I have used. However like every one of these languages it does take time to learn. For simply tasks LabVIEW is easier for nonprogrammer to learn than most other languages. For large complex systems you obviously need to know what you are doing not only with LabVIEW itself but with designing the system.

LabVIEW can be challenging for some to learn given it is such a different programming paradigm. Most people need some time to get a good grasp on data flow programming. Most folks who have been exposed to programming think in terms of sequential flow. Once you learn and embrace data flow programming you really appreciate the power it has.

All I can say is that LabVIEW has been around for over 20 years and has proven itself in the field. Even NASA used it to control the Mars rovers. It is not some academic experiment that is full of bugs and not ready for prime time. It has been and is being used to develop some very large complex systems that demand reliability.

With respect to your specific code could you post the VI? It would help to narrow down the issue you are having. The error message you are getting is pretty generic and there is a ton of stuff going on in the Express VI. One thought might be that the DAQ task is becoming invalid during your execution. Without the specific code it is hard to see if this is the issue or not.