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

[tst]

---

That wouldn't be so bad if there were a really good tutorial out there somewhere, that could in an hour or two, get you off and running on real world projects.

---

I really *really* doubt that. Is there a C++ tutorial that can get you up and running in a couple of hours?
If there is, please show me.
Seriously though, LV wasn't designed as a general purpose programming language. It did sort of "grow into it" over time, and still does so now, and there are many areas where it's lacking.
There's no getting around learning curves. You have to start small and you have to make the stupid mistakes because that's the way you learn. Now, if you said that you wanted to connect to an oscilloscope and display what's its showing on your screen then we could say "yes, you can do that fast", but something more complicated will take time.
It's quite possible that you're right and that there is no really good tutorial for starting out. Personally, I started by learning from someone and by working myself and having my mistakes explained to me. The rest of my LV knowledge comes from web sources like this site and from experience. I often send beginners Here and here as two examples for tutorials and I tell them to read the LabVIEW style guide. I haven't gone through these tutorials and it's likely they won't help you because they show how to start with LV and not how LV works, but you can try. The style guide is definitely worth reading.
I can't explain what you're asking about the LV programming model, because the description of "Dataflow" sounds perfectly natural to me. There are a few links you may wish to look at here.

[Ben]

HI Moose Man,

I may be making a mistake by stepping into this thread now but....

1) I am on your side.

2) Once you get over the learning curve you are going to be in good shape.

I am still somewhat suprised to see just how few LV types understand top down design. They seem to bottom up into a mess pretty often.

This link talks about using the LV State Diagram Editor.

http://forums.ni.com/ni/board/message?board.id=170&message.id=112440#M112440

Feel free to post follow-up Q's or comments if you like.

If this does not get you any closer to where you want to go, please ask!

Ex-hardware Engineer (that got better),

Ben

PS. I beleive the new SDE tutorial uses a vending machine as one of the examples.

Post conflict detected! I did not read Dennis and tst before making my post. I still thnk the answer is to start with the SDE because the Moose Man is comfortable there.

Message Edited by Ben on 05-23-2005 02:50 PM

Message Edited by Ben on 05-23-2005 02:53 PM

[Dennis_Knutson]

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.

[tbob]

I have not read Bishop's book, so it appears that you have wasted your $65. I am a self taught Labview programmer so I cannot recommend any book. As far as Labview's "Programming Model", what do you mean by programming model? I've never heard of a place/transition net or a colored Petri net. Labview is a programming language, not a hardware design tool. There is no simple structure that everyone follows. You create whatever you need. It is up to the programmer. I have programmed in lots of languages, Fortran, Pascal, C, VB, Assembly, and I can say that Labview is by far the easiest language to learn and to use. Not all of my programs follow the same structure. Not all of my projects start with top down design. It all depends on what you want to do. It takes experience to determine the best way to start and the best way to procede. Start with something simple until you understand what you can do with Labview. Look at some examples that come with Labview. I haven't taken it but I hear that NI's basic course is great. If you can't attend, you can buy the course material. If it is too expensive, try another book on learning Labview. I got off and running with Labview by reading the manual and looking at some example code that comes with Labview. It took me a few days to become proficient and it cost me nothing but time. When I started, I was already an experienced programmer. That helps a lot. You need to understand what a programming language is before you start attacking it. And if you attack Labview here, you can expect to get lots of reprocussion because we all love Labview. You will too once you understand what it is and what it can do.

[Ben]

OK it looks like it the bear and the moose vs the world!

I will try to reply on this battle front more if I find time.

Ben

(the evil one)

[tbob]

Ben, I don't see it as the bear and the moose vs the world. I just see that the moose is not understanding what a programming language is supposed to do. It's like hardware vs software. You can use digital logic in hardware to create a system. You can also use sequential logic in software to do similar things. Data flow is the same in both cases. The output is not valid until all data inputs are satisfied. I tried teaching Labview to a non programmer once, and he just could not grasp it. I had to start with simple programming concepts, like explaining what A=A+1 did. Mathematically speaking, A=A+1 is impossible, but programatically, everyone understands that you are adding 1 to whatever A "was", and storing the new value back to A. Once the moose understands programming, he will welcome Labview. As far as design methods, top down design is my favorite, but does not lend itself to every single situation. Yes I have seen some horrible approaches in my days, and it usually ends up in a mess. There are books out there that deal with this subject. Maybe someone could recommend a good book for the moose. Sorry, MooseMan, it will take time to get up to speed. There is no other way around it.

[Ben]

I will let the Moose Man speak for himself if he chooses to re-enter.

My point is that there is a big part of programming that is not covered in any of the LV courses I am aware of.

The part that is missing is structure (maybe wrong term).

I have already said alot about design and will not repeat it now.

When I start a design for a project, I spend a good deal of time figure out all of the parts and how they will work together. After I complete that phase, I can proceed to the SDE work.

Some of the thing I ponder are similar to the thoughts that go into a database deign that is completely normalized (again maybe bad term).

What data am responsible for?

What uses what data when, and how often?

Other thoughts include WHILE questions like what happen while something else?

Durring this phase I draw-up fuzzy pictures and give things names like GIZMO_Watcher, GIZMO_Logger, etc.

The initial design functions are usually done use Power Point for the pictures and Excel for the what data where stuff.

Maybe this just my unique methodology....

But, I end up with relationships between my PP/Excel work anf the final VI.

Often the "tables" equate to arrays of clusters.

Widget_Watcher ends up being a VI developed via the SDE.

So....

My point there is still a lot of "top end" room for LV to grow into.

I'd like to see the full devlopement cycle from initail design onward to be supported by LV.

Just my dream,

Ben

BTW: Please do not take offense in my comments or pull any punches! This is a good topic and I can handle some mean jabs. Just don't insult the bear or threaten to shave him, etc.

Message Edited by Ben on 05-23-2005 03:50 PM

[Dennis_Knutson]

Been there and done that, too. I would much rather try to teach a die-hard C++ programmer LabVIEW than teach an engineer who's never had a programming course. I've often disagreed with the NI marketing of LabVIEW as "a programming language for non-programmers". If LabVIEW were truly so simple that you didn't need any programming knowledge, it wouldn't be the flexible tool that we all love. I think NI should include some basic information on programming that is read before anything else. I'd bet we see a significant drop in questions posted here. On the other hand, since it seems many don't read the manual anyway, maybe it wouldn't make any kind of difference.;)

[EdDickens]

---

I think NI should include some basic information on programming that is read before anything else. I'd bet we see a significant drop in questions posted here. On the other hand, since it seems many don't read the manual anyway, maybe it wouldn't make any kind of difference.;)

---

In fact, NI does include this ability, at least as it pertains to LabVIEW.

Open your LabVIEW.ini file and look for the key "IsFirstLaunch=False". Change it to "True", save and close the file, then launch LabVIEW. A different dialog opens than the one we normally see, because when we first installed, we zipped past this one because we didn't need it. But look at it. Big bold letters "New to LabVIEW?". And a direct link to the "Getting Started" manual. This may not be the best manual in the world, but at least it's something.



The problem is nobody (including myself) wants to sit and read anything. We'd rather just dive right in and get to work. Only after getting frustrated because we can't do what we want to do we resort to reading. By then we've turned off this dialog and there's no easy way to find it again. There's no link to it in the Help menu. You have to go to the Bookshelf to find it. And that's not very obvious to most. So you're right. It probably won't make any difference because that's human nature now. Do first, read later.

---

My point is that there is a big part of programming that is not covered in any of the LV courses I am aware of.

The part that is missing is structure (maybe wrong term).

---

The LabVIEW Intermediate courses actually attempt to teach LabVIEW programming structure. We go through Top Down and Bottom Up approaches as well as analyzing your application requirements, choosing the correct design pattern and data structures for your application, and a host of other topics. In this course, you develop a more complex application than the one you do in Basic 1&2 in a structured manner much more like what you encounter on the job. These are new courses and still need a little work. I've taught them a couple times and in order for the student to get the most from it, they should have several months of on the job work under their belt because it moves pretty fast. If you've just taken the Basics class and jump right into the Intermediate class, you'll probably be lost.

But that has nothing to do with the original topic of the thread. What is LabVIEW? One of Moose Mans questions was,

---

how *does* LabVIEW structure and organize things

---

. I think the answer is; it doesn’t. It only does what you tell it to do. And in order for it to what you want it to do; you have to learn how to manipulate the tools it provides. And unfortunately, there’s no shortcut for that. Only time and experience (maybe a class or two if you have the time and money) will get you there.

---

OK it looks like it the bear and the moose vs the world!

---

Good thing you don't use a squirrel for your icon. I'd be having flashbacks from many years ago. 😉

Ed

Message Edited by Ed Dickens on 05-23-2005 04:49 PM

Message Edited by Ed Dickens on 05-23-2005 04:51 PM

[tst]

Dennis, I must say that there is a point to not reading the manual - it's very long and not as useful as a tutorial for a beginner. I would say the manual would be of use to someone who has been using LV for a few months and can digest the stuff in the manual. A better tutorial than the "Getting started" (which includes some programming principles) is definitely not a bad thing to have with LV. It should probably also be interactive.