Momentary switches and sequential logic--- seeminly not available in Labview

[Moose Man]

I'm still not sure how to quote other responses to posts here. If I could I would quote the one at the bottom of the list, just above this one.
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 *which he himself had emailed me about* in the first place. In several messages, he's defended his non-response, but still not told me where the meetings are held (My hunch is that they are a prohibitively large distance away anyway, 40 miles or so of bumper to bumper freeway 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 since 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. One 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 in the download that is available for the book. Since he only alots 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. More significantly, after spending a good hour trying to figure out how to set "timeout" to either the supposed (according to Bishop) default of -1, or some time in milliseconds (which Bishop probably could probably told me how to do in a sentence or two, but didn't bother), I decided to give up on Labview. Thank you, Professor Bishop. Your list of credentials on the back cover of the book may well be impressive (except, of course, to someone who has actually worked at a NASA lab, and knows what those are are really all about, and how they operate), but of the literally hundreds of technical books I have purchassed over the years, yours is by far the worst. Had you doubled your discussion of even-driven programming--- to a full 2 pages-- I wouldn't probably have said this-- at least not publicly. But the slip shod manner in which you wrote this entire chapter, and the gall of you to say that the purpose of this chapter was merely to "stimulate curiousity," was the last straw for me.
As far as the need for a course and an instructor, I really don't think that's necessary. All I need (or needed) basically is (were) a few pages and a good block diagram or two that explain(ed) how the entire mess all works together. As far as I can tell, nobody has done that. Everyone tries to say it's all "data driven," but that completely untrue. To do anything other than a really simple system, you need event driven programming. How they got around this before version 6, when event driven programming was first introduced, I don't know. But since I'm not going to waste any more time on 7.0, I'm certainly not going to bother learning a 10 year old version of Labview.
But thanks anyway for your response.

[shoneill]

It's a shame you haven't taken the time to step back and cool down before evaluating LAbVIEW again. It's true that the differences in the "paradigm" or "programming model" or whatever you might want to name it can make things difficult for some users.

There's not much you can't do with LabVIEW that you CAN do in other languages. And as with other languages (computer-based or otherwise) it WILL take more than a few hours to get to the position where you can do anything useful with it.

At this point I want to agree with a previous poster (I forget who, sorry) who said that LV is a victim of NI's marketing. I agree. But just partly. I also agree that the name "LabVIEW" is still a handicap, making most people write it off as a real computer language (Sourceforge.org now recognises LabVIEW "G" as a proper programming language). Because of this, their expectations are completely different. Most people seem to approach LV with the expectation that everything will be done for them as with an application instead of being given the tools do do things themselves as with a programming language.

These expectations are (As we can see in this case) unfounded. I've never heard of anyone learning JAVA in a few days, let alone a few hours. The same goes for BASIC, C++, insert programming language here......

NI, change the name and "open" the development environment of LabVIEW so that we can expose the "G". THEN LV (or "G") will really fluorish.

My opinion.

Shane.

[tst]

I would like to state a few points:

1. As many here said, it's quite possible that Bishop's book IS bad. Since apparently no one here read it, there's no use in telling us how bad it is. Also, that book does not reflect on LV.

2. NI is a very big company. It's possible that some of its sales reps are not as good as others. Also, There are not necessarily user groups every 10 miles. How many C user groups do you know in your area?

3. You can quote posts if you click the Reply button for a specific post and then click the blue Quote Post button. NI's forums have some annoying things like that.

As for some more pertinent things:

4. The "crucial document" Dennis referred to was linked to in my first post (#11). Just in case you missed it, here is the link again. In the same post I also gave a link to several articles relating to LV as a programming language. In general, as was said earlier, both the LV help and this site have massive amounts of fairly easily found data on LV. Yes, there are holes and yes, it does not necessarily help beginners, but (once again, like was previously said), it takes time to learn.

5. Event driven programming is not THE answer to your original question. It as an answer, probably the best one, but it's not the only one. As the first 2 answers you got indicated, this could be solved simply by changing the mechanical action of the boolean (admittedly, that's something that's not the easiest to find, but you can't expect to know everything immediately). I'm not sure why you attach such importance to it. You yourself said that a user interface is a different thing from the underlying code and most people use event in LV mainly for user interface.

Event driven programming is an important tool in software design, but not all programs need to rely on it. As a matter of fact, many programs written in LV, which depend on communication and parallel loops, use event driven programming only in a small part of the application. Also, LV had (and has) some synchronization tools whose functionality is equivalent to that of events. For examples, if you use a queue with a timeout of -1 (similar to the -1 you talked about earlier), the function will wait until there is something in the queue. The loop will not iterate. Is that close enough to event driven programming for you?
These things are documented in this site (the design architectures Ben mentioned).

6. Probably all of us would like to see LV become more "general" and allowing project design internally and as time passes these things do happen. LV wasn't designed like VC++ and it takes time.
As everyone here said, LV is a programming language. It takes time to learn how to use it properly and once you know how to you can find different solutions to a problem. Just relax and start over. See if you can take the NI course. If you can't, see if you can find someone who knows LV. Just keep in mind that does not guarantee a proper learning experience either.

[Dennis_Knutson]

I really have very little sympathy. You've asked one question of the forum and had it answered. It seems like you've had many others but didn't bother to ask and now you're giving up. I and many others learned LabVIEW a long time ago before there were any on-line turorials, web forums, books, or user groups. The company I was working for, couldn't afford to send me to Auustin for two weeks (the only place to get training at the time). I went in with an open mind and studied the hundreds of shipping examples (many more now than when I started), read the manual and on-line help. I experimented and made many mistakes initially. I did not go into it with some pre-conceived notion that I would quickly learn LabVIEW and start charging a lot of money for my services. It was just another tool. A little different than the C/Quickbasic/VisualBasic tools I was already using, but still a tool that I had to apply the same sort of design rules I was already using. You place a lot of blame on Bishop's book. Get over it. In all likelihood, it was written long before NI introduced the event structure and the last chapter had to be quickly added to meet the publishing deadline. When 6.1 came out with the event structure, it was new to everyone. We learned what it could do by looking at the shipping examples and what was said in the manual and help. I love the event structure but an awful lot of LabVIEW programs have been written and are still running without it.

[AnalogKid2DigitalMan]

So I guess he's not going to participate in one of the coding challenges 😞

[tst]

---

@AnalogKid2DigitalMan wrote:
So I guess he's not going to participate in one of the coding challenges 😞

---

Good. More DVDs for the rest of us.

[dan bookwalter]

one of the problems i have with program design is that the mode i usually have to operate in is "holy crap we need this done today , tommorrow at the latest. LabVIEW has pulled us out of more jams than i care to count. you must realize these jams are not of my doing , but , rather the wonderful planning of people up stream from me. its just me that has to pull them out of the fire. my indoctorinization (spelling ??) into LV was a crash course in LV,DAQ and servo control to get a n entire system up and running within a week of receiving LV (vers 4) so the customers could see what they were paying for. i also agree that a programming background is extremely advantageous..

Dan

[Moose Man]

I would like to state a few points:
I will reply to these points

1. As many here said, it's quite possible that Bishop's book IS bad. Since apparently no one here read it, there's no use in telling us how bad it is. Also, that book does not reflect on LV.
Not true. The Book clearly has NI's Imprimatur. Their official logo is on the front cover of the book, and the back begins: "Learning with Labview 7 Express by Robert H. Bishop is the official text book for the Labview 7 Express Student Edition software from National Instruments." That is what hooked me into ordering this book in the first place, the alleged "official" sanctioning on the part of NI. Let me further add that what is really "bad" about the book is that it is woefully incomplete. Reading it does not give you enough information to write anything but trivial applications. As a result, I wasted a lot of valuable time pouring over nearly 600 pages, looking for what ultimately wasn't there. You say there is no poaint me saying this here. I counter argue that others have a right to be forewarned.


2. NI is a very big company. It's possible that some of its sales reps are not as good as others. Also, There are not necessarily user groups every 10 miles. How many C user groups do you know in your area?
In the first place, NI is not at all what I would call a "very big company," (Exxon Mobil is).In the second place, the sales reps are all fine. They're all in Austin. I wasn't talking about a sales rep. In the third place, it's not a matter of "miles," it's a matter of time. I could travel 25 miles to the south of me, for example, even in the late afternoon, and do it in about 25 minutes (some people could do it in 20). In the other direction, It would be at least an hour. And if I spent another hour going 15 miles further, I'm in the middle of street gang territory, and I need to be concerned about the color of the clothing I'm wearing. But I don't know for sure whether that would have been a problem because the person who informed me of the meeting in the first place would never tell me for sure where it was. But I do know that other NI meetings in the past have been in cities I would prefer not to travel to, and definitely would not want to be after dark.
Since you ask about C user groups, there are plenty of technical user groups of all sorts within 15 miles of me. But one doesn't really need a C user group to learn C because C is not a proprietary programming language, and it's a real ANSI programming language as well, with a real language definition. No little circles with numbers attached to corners of crosshatched bars.

3. You can quote posts if you click the Reply button for a specific post and then click the blue Quote Post button. NI's forums have some annoying things like that.

Well, I looked again, and didn't find anything like a "Reply for" button, just the one at the top of the heap. But no matter, I'm not going to be posting here anymore anyway. As to the Quote Post, that merely quotes the top post of the thread, from what I can tell.

What I had really hoped was that someone might recommend a book that was both concise and complete--- and didn't just throw a bunch of examples at you. One that really explained how it all worked. Maybe, that someone would even tell me the "trick" to setting paramenters in event structures--- like, making timeout something other than timeout(0). Since nobody did, I really am giving up. Labview, I've concluded, isn't a programming language at all, it's a religion. And as with any religion there are those who believe and those who do not. I most emphatically do not. If the rest of you do, that fine. It's still, if only just barely, a free country.

[unclebump]

I borrowed a book called LABVIEW Graphical Programming -- Practical Applications in Instrumentation and Control by Gary W. Johnson. 2nd Edition printed in 1997. I didn't start using Labview until around 2001. It was good enough to get me started, but I'm a self-taught user, mostly of the DSC module.

[dan bookwalter]

I think maybe you should take a step backwards here... yes you maybe correct in that LV may be somewhat of a religion... a book that many people use is "LabVIEW Graphical Programming" by Gary Johnson. i dont know if there are any excerpts from this book anywhere or not. as others have stated i doubt you are going ot find as comprehensive of a book as you seem to be seeking. i would encourage you not to give up just yet , maybe take a break then try to go back to it. i'll give you a hint , when ever you are not sure if something is available with a particular object in LabVIEW right click it to open its options. LabVIEW is a very powerful tool and as such it does take a little time to get up the curve , but , it doesnt take anywhere near as long as with other languages. also with the event structure in order to set a timeout other than 0 , right click the little hour glass and click on create constant , enter a value in the constant , the value you enter is the new timeout in milliseconds.

good luck

Dan