Dennis Knutson
Proven Enthusiastic Veteran
Dennis Knutson
Reply 13 of 29
Viewed 220 times
I'm still not sure how to quote posts here, so I just did a cut and paste.
Since the time of your response, I've basically given up on Labview. The book I have is absolutely horrible, and as far as local NI support goes, in 4 days the local rep couldn't find time to tell me the location of a user group meeting. In several messages, he's defended his non-response, but still not told me where the meeting are held (My hunch is that they are a prohibitively large distance away anyway, 40 miles of bumper to bumper traffic).
Had I read your post earlier, I might not have given up so readily. Part of the problem, I now know, is that I am working with an evaluation copy of 7.0, and do not have this very crucial document you cite. Also, I've sine figured out on my own that "Event-Driven Programming" was the short answer (maybe even the complete answer) to the question I originally posed in this thread. The main reason I never suspected this is because event-driven programming, which should be mentioned in the first chapter of any good book on Labviewe, isn't mentioned until the last chapter of this utterly horrible book I have. And then, on top of that, the author got particularly lazy in this chapter, and admittedly covered the material in less detail--- not even including a singe example of an event-driven programming. (Since he only allots a single page of text to it, perhaps he rationalized that it wasn't worth the trouble of writing a vi to illustrate it). In any case, Professor Bishop really threw me off here.
1 rating - 5.0 average
The "sequential logic design paradigm" is not the paradigm that LabVIEW or NI represents at all. The paradigm presented is dataflow with graphical programming elements. Data flow is much more than data flows in and data flows out. Put simply, data flow means a function does not execute until it's data is present. Unlike text based languages where you control the order of execution by the order of statements or goto's or function calls, execution order is determined by when data is present. This allows for inhereent parallel tasks in that if you don't connect functions with some sort of data, the functions will execute in parallel. LabVIEW is not so specialized that it only supports logic design. A logic design program can be created with LabVIEW just as you can create a logic design program in C++ or VB. A computer science class is much more applicable to thinking about LabVIEW than a digital design course.
It's unfortunate that you've found the book and the tutorials lacking. I can't comment on any because I've never read a beginners book or tried any of the tutorials. I firmly believe that there is no replacing a class with a real, live instructor. Many cities have classes so I would encourage you to try that route. If that's not possible, then try to find a local user group and of course, make use of this forum.
Lastly, let me point out a couple of things. LabVIEW ships with a document called the LabVIEW Development Guidelines. It discusses top-down and bottom-up design approaches and includes a style guide that should be read by everyone. And, since you mention state machines, this architecture is covered in a couple of shipping examples. There is also an add-on for LabVIEW in which you can graphically draw a state machine and then generate the code.
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
