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

[Moose Man]

I'm a new user of LABVIEW and yessterday discovered something fairly interesting: there are no "momentary action" buttons or switches. (Nor, for that matter, does there appear any concept of sequential logic (i.e., D or T of JK flip flops).
Why would I want a momentary action switch? Well, I started writing a VI to prompt user for input (ultimately to be a file name in which input setup paraments are to be stored). Without a momentary action switch, the simple VI I wrote wants to keep on prompting for input until that switch is manually turned off with another mouse click. But I'm not able to enter the that mouse click because I am continually being asked for input. Clearly, a momentary action switch would solve that problem. Alternatively, a "pulse generating" function or "triggering" function would half way solve the problem (I'd still have to manually turn the switch back off, which wouldn't be all that great, but that's not aailable either.
My tentative conclusion here is that there you just can't do this sort of thing in Labview--- at the very least, that there is no concept of either "sequential logic" or synchrounous logic more generally, in Labview. I know that I could at least in theory make my own "flip flops" out of NAND gates. But of course, there still would be no "system clock." Perhaps what I need to do is create my own digital one shot multivibrator using LABVIEW NAND gates. Fine, but why can't Labview simply provide a "momentary action" switch? One that would be of sufficient "duration" to "prompt for user input" once, after the virtual panel switch was hit, and only once.

[Dennis_Knutson]

There is momentary action. Right click on any Boolean and select Mechanical Action. Using Latch When Released will work in your case. Once the value is read, it will return to it's previous state. Look at the on-line help for Boolean controls for additional information on mechanical action and the different behaviors.

[John Rich]

There are several ways that you can do this. You could make the switch "momentary" by changing the mechanical action to "switch until released" for example. A better approach is to use a latching action on the switch. You can use latching to make the switch change until the first time that it is read. Latching does not work with local variables, but you should be avoiding those anyway.

In order to change the mechanical action of the switch right click on the switch and select mechanical action and the appropriate action type.

-------------------------------

Looks like Dennis got this one while I was answering

Message Edited by John Rich on 05-20-2005 12:57 PM

[EdDickens]

Dennis and John already hit on the solution for your problem by using the Latch action for booleans, but I just wanted to comment on your comment of a function not being available.

[climbing on soapbox]

You're correct in the fact that there are no D or T of JK flip flop functions built into LabVIEW, but why should there be. NI provides all the building blocks you need to make one. If NI attempted to provide a function for everything you can think of, LabVIEW would be bloated with thousands of functions that you would probably never use. There's probably already a thousand functions/subVIs that come with LabVIEW, and I know I've most likely only used a fraction of them.

LabVIEW is a programming language. If you need something that doesn't exist, build it and save to your user.lib directory so you can use it again later. Look at it his way, if you needed to add two numbers, then multiply the sum by 100, would you expect a function that did that, or would you just drop an ‘Add’ and ‘Multiply’ function and connect them together.

I think part of the problem here is NI Marketing. They tout LabVIEW as so easy to use, anybody can do it. And for the most part, that’s true. But then people start thinking that everything they need will be there in convenient icon they’ll just have to drop and connect. And to some extent, that’s true. Even if you have to drop a few and connect them.

[/climbing off soapbox]

Since you’re new to LabVIEW, you should start off by running through the tutorial. Open the Help menu and select “Search the LabVIEW Bookshelf”. This will open a PDF that is actually a searchable index of all the help available in LabVIEW. On the page that opens, you’ll see a section “New Users” and a link “Getting Started with LabVIEW”. This is a pretty good tutorial and will cover all the basics you need to know, like the different actions of the Boolean controls. There’s also a really good tutorial online at http://cnx.rice.edu/content/col10241/latest/.

Also, attached are a couple VIs I found somewhere a while ago. One is a JK flip flop, the other is a D latch.

Ed

[Moose Man]

The first two messages were quite helpful. The tird one is two but in a very different sort of way. It's helpful in helping me to figure out why I'm having so much trouble with Labview. That is to say, I've done a number of tutorials with Labview. They're great except for one thing--- they really don't teach you how to do anything *new* or *innovative* in Labview. That is to say, they really don't tell you much of anything about the top level architecture of Labview--- they don't teach you how to "think about engineering problems" in a Labview environment. Instead, they hope to give youu enough "prefab" solutions to enough problems so that you'll be able to kludge together solutions to new problems.
This is a very old approach, dating back to antiquity. (The Great Roman Educator Quintillian (c.a. AD35-100) in his "Education of an Orator" complained about a new breed of orator that was taking the "canned solution" approach to arguing points (i.e., rote memorization of specific arguments. What Ronald Reagan did at the end of his last Presidential Debate, where he started reciting movie sript lines which he had memorized decades prior was an example of this approach. Ronnie did this not because he was getting senile, as some have supposed, but because he never was a deep thinker, but always did have a photographic memory).
In any case, I find this approach to be innefficient, stiff, and inflexible at best. What is worse, it makes Labview appear to be (rightly or wrongly) extremely counter intuitive in a number of ways. The matter of the momentary switch is but one example. Sure I'm glad to know how to do it, and I thank the two peopele who explained this to me, but please don't tell me this could have been either "figured out" or learned by way of any of the standard tutorials.
I also have Bishop's book, Labview 7 Express. Nice book if you're teaching a course in Labview. Also a good book if you want to get a good grade in a course on Labview. But for coming up to speed quickly in practical use of Labview, or as a reference guide--- worthless. I really wish this were not the case, but sadly, it is. I can also tell you that if I were to write such a book, it would be organized in a very different sort of way. The first chapter, for example, would discuss data reprentational forms in Labview (binary trees, flat strings, and so forth. I don't see how anyone could begin to understand Labview without knowing that). And the first example I'd give wouldn't be anything like anyn of Bishops. That is to say, I wouldn't just throw an example at someone and say "see, here is how it's done." Why not? Because such an approach doesn't really show you how to do anything. Instead, I would start with some simple application anyone can relate to--- like a VI that converted Farenheit to Centegrade. I would start by saying something like this: "Do solve this problem, first you have to give the user a means of entering a temperature to be converted, and a way of reading the result. You this in the Front Panel mode by... etc etc. Then, you have to create a function that actually does the conversion. That you do in Block Diagram mode by... Now, suppose you want to save the result in a file? That you do by..." In essence, this first example would be paradigmatic of the Labview design process-- one which more or less would be a simplified model for all designs.
As to my point about not having any sort of flip flops, I just can't begin to buy what you say. Anyone who has done any sort of logic design at all (even crude logic design with electro-mechanicaltimer relays--- the kind that used to plug into Octal Tube Sockets) knows that you need more than just combinational logic gates to do anything practical. Sure, I could pull out my old logic design texybook from 30 years ago, and refresh my memory of how to build a JK Flip flop, but why should I have to do that for something so elementary and basic? Plus, how robust would the implementation be if I did? No, I am not going to do that--- not because I'm too lazy to create a "JK" VI, but because I really doubt that this would be a productive path for me to follow.
Probably it wouldn't work very well, number one, and because it would likely make me a productive user of Labview any sooner.
The bigger point I was trying to make was that Labview simply isn't designed for a "logic designer's" point of view. Fine. How then *is* it designed? Actually I hoped I might get an answer to that question out of my initial post. Perhaps I still will. Perhaps I might even figuring out the answer to that question myself.

[John Rich]

I think that you missed the point of Ed's post. LabVIEW is a very powerful programming language with many built in functions. Unfortunately it would be impossible to have functions for everything that every user could ever want. However, since it is a programming language the building blocks are there. Furthermore, there are often solutions available if you look or ask for them. For instance, Ed attached a JK Flip-Flop vi to his post.

I have missed your point on the tutorials. It appears that you're saying that they don't teach you how to do anything new and innovative (JK Flip-Flops?) but then you say that a tutorial on how to convert Farenheit to Centigrade is how you would begin. I have found that the tutorials are very good for learning the basics of LabVIEW. To go beyond the basics you could take LabVIEW courses. Also, much can be learned by just tinkering around with LabVIEW and reading questions and replies on this forum. There are many of us who are self-taught LabVIEW programmers. Some are even involved in building large projects in LabVIEW. We didn't get there by expecting everything to be available in a canned solution. We began by learning the basics and then pushing the limits of knowledge. When we don't know we ask questions and usually get good solutions, often finding that someone else has already done what we're trying to do, or some variation thereof.

You asked how LabVIEW is designed. Well, its original application was in data acquisition and display. This is still a major role for LabVIEW, although new features have helped it to evolve into a much more versatile language.

[EdDickens]

---

I can also tell you that if I were to write such a book, it would be organized in a very different sort of way. The first chapter, for example, would discuss data reprentational forms in Labview (binary trees, flat strings, and so forth. I don't see how anyone could begin to understand Labview without knowing that). And the first example I'd give wouldn't be anything like anyn of Bishops. Instead, I would start with some simple application anyone can relate to--- like a VI that converted Farenheit to Centegrade. I would start by saying something like this: "Do solve this problem, first you have to give the user a means of entering a temperature to be converted, and a way of reading the result. You this in the Front Panel mode by... etc etc. Then, you have to create a function that actually does the conversion. That you do in Block Diagram mode by... Now, suppose you want to save the result in a file? That you do by..." In essence, this first example would be paradigmatic of the Labview design process-- one which more or less would be a simplified model for all designs.

---

The way you say you would write a book on the subject is pretty much how the LabVIEW Basics 1&2 classes are setup. We start out by introducing the basic parts of LabVIEW (front panel, block diagram, controls and indicators, data types, etc..) then start with a simple exercise. Then throughout the class, we build on the original exercise to eventually build an entire application that really does something.

---

The bigger point I was trying to make was that Labview simply isn't designed for a "logic designer's" point of view. Fine. How then *is* it designed? Actually I hoped I might get an answer to that question out of my initial post. Perhaps I still will. Perhaps I might even figuring out the answer to that question myself.

---

I think you missed my point. You're correct that LabVIEW isn't designed from "logic designer's" point of view. But I don't think it's advertised as such either. LabVIEW is a programming language just as C++ or Visual Basic is. It gives you all the pieces you need to do what need to do. Your job is to figure out which ones you need and what order to put them in. If it was designed to be a logic designers tool, then the person using it to build a vision inspection system for an assembly line would have a really hard time. Look at it this way, if C++ were written from a "word processors" writer point of view, a person trying to write a spreadsheet application would have a hard time. LabVIEW is no different except in how you create your application. Instead of lines of code, you use graphic symbols.

LabVIEW is a tool that anyone can use to build an application. There's a learning curve involved for the new user and we've all been there. When I started with LabVIEW about 5 years ago, I had the exact same problem you had with the boolean controls. How do I make a momentary switch? Like you I figured it out by asking the question. I eventually discovered that the LabVIEW Help is really one of the better Help systems that applications ship with. It's not perfect, none of them are. But there is a wealth of information in there if you look. And if you think something is missing, posting it here will get the attention of the folks at NI (yes, they do monitor this forum. Anybody whose name and participation bar appears in blue works at NI) that write the Help files and there's a good chance your suggestion will be implemented.

I hope that clears up your "How is it designed" question a bit. LabVIEW is used for many different types of applications. Just look at the number of addon packages available for LabVIEW and you'll get an idea of it capabilities.

Ed

[tbob]

To show that there are several ways to accomplish the same result in Labview, I have attached my version of TTL logic vi's. Ed took the actual logic gate approach which is what is really inside the TTL chips. I took a True/False approach. Both are correct but different. Since the actual TTL logic chips have clock inputs, my logic vi's also have clock inputs. Also included in the zip file are vi's to test the logic vi's, a clock divider vi which uses the D flip-flop, and a 4 to 1 demux vi. All of this is intended to show that instead of relying on NI to create everything you want, you can create your special needs yourself. I created these vi's for fun and practice, I have never even used them. It would be impractical for NI to have created these because they are not general purpose. It is up to you to create what you need using Labview as the tools for creation. Also, creation cannot be taught in a class, everyone must develop the ability on their own.

[Moose Man]

Let me try once more to clarify. But this is going to have to be it. There have been a lot of connections drawn here between things I've written that aren't really connected (like Tutorials and JK flip flops). First let me say, that my intention has not been to beat up on NI or Labview. NI is a good company run by some really nice folks, as far as I can tell. All of my interactions with the company have been extremely positive. My primary puropose, thus, is to learn how to use Labview well enough to make some money. There are other things I could do with my time that would be a lot more enjoyable than technical work, but I can't make a living doing them. Thus, I'm stuck with trying to make the best of using tools such as Labview, Matlab, and so forth.
Basically, my bacground is systems design, and logic design. I've done some analog, yes, but I'm mainly digital, and I'm mainly systems.
To start with the digital side of things, any university level digital logic design course is going to begin with cominatorial logic (Boolean expressions, Karnough maps, etc.). Then, once as a student masters all of that, and he thinks he's got it made, the professor points out to him that to do anything really useful, you need the concept of a "logic state." How do you implement logic states? With memory elements--- the most basic memory element being the flip flop (SR being then most primitive, as I recall). Then to define a total system, you decide on a number of specific "states." If say, you were designing a coin vending machine, one state would be machine empty, another "5 cents deposited," and so on. You would then move on to arbitrarily define specific states to represent specific conditions (where n is the number of flip flops, there are 2**n possible states of your system).
Anyway, if I were to design a hardwired logic (i.e., not using Labview) instrumentation panel, this is basically how I would do it. Of course, I'd be far more likely to use a microcontroller or "microprocessor" chip for most applications, but either way, I'd want to begin by defining a finite number of "states" of my system, and draw a flow diagram. If I wanted parallelism, I might use a Petri Net of some sort.
My point: this is clearly NOT the way Labview does things. My question was, therefore: if not this way, how *does* Labview structure and organize things (that is, if you hope to wind up with something better than what is commonly called spaghetti code, how do you do a top down design)? So far, nobody has even tried to ansswer that question. Instead, people have more or less dumped on me for asking the question--- accusing me of expecting to have every little thing done for me ahead of time. Well, the reality is just the opposite. I just want a few basic building blocks. In the world of logic design, flips are really quite basic. Which lead me to conclude: the sequential logic design paradigm is NOT a particully useful one for Labview. No, I don't want to try to change that fact by brute force, using JK flip flops implemented with NAND gates-- I want, instead, a more useful model of Labview as supplied by NI.

[Moose Man]

As far as the tutorials and the one book I have by Bishop go, I'm just saying, flat out, to put it bluntly, that they're all really terrible. As someone who has *recently* tried to pick this all up, and as someone with a certain background in education generally, I think there is some validity to what i say.
First of all, if you're an engineer working in the field, you simply cannot afford the luxury of a 3 month course to learn Labview, nor the hours that would be required to work through Bishop's book on ones own. Secondly, it wouldn't be necessary to do that if there were a decent book available (it may well be that one is, I haven't had a chance to look at very many of them).
What's wrong with Bishop's book? To begin, Chapter 1, the worst in the book, is a complete mental overload. He throws a proverbial million things at you at once. Even worse, nothing is really explained in that chapter at all. As a result, the reader keeps rereading and rereading to try to figure out what he missed, and where he missed it, only to eventually realize he didn't really miss anything because there's really nothing there at all. That is to say, the chapter tells you nothing. Everything you could possibly hope to learn by reading these 39 pages you could learn by taking a minute or two to open the Labview program and simply clicking a a few icons. If there is one useful page in the whole chapter, it is the bottom of page 32 and all of 33, where a few key tems are defined, like Block Diagram and Front Panel. (He mentions nodes on page 33, but doesn't really tell you what they are--- again making the real feel frustrated for having missed something--- something which isn't really there).
The chapter claims, of course, to "introduce the Labview Environment." The reality is that it does nothing of the sort. In point of fact, it tells you absolutely nothing about "the Labview Environment." It does tell you a little about the Labview User Interface, but as any undergraduate computer science student knows, a user interface is not the same thing as a programming envirnoment. As one web definition for "programming environment" puts it, "A programming environment implies a particular abstraction of the computer system called a programming model."
So, what is the Programming Model of Labview? Is it a place/transition net? A colored Petri Net? What? This is the queation I have been asking for some number of days now. Bishop in Chapter 2, page 44, mentions in passing something about "data flow programming." But what does he then tell you this means? That data flows in, and it flows out. Wow. And I paid $65 for *this*?
I could perhaps reasonably come to the conclusion that Labview is little more than an amorphous blob of code, originally written by some analog guys,that people are just somehow able to use (mostly by memorizing little tricks). But I really don't believe that--- even though a good number of Labview users, and book authors, seem to approach it that way. I do believe however that Labview shows more signs of "evolution" than it does of "intelligent design." (Two phrases I have borrowed from a certain theological debate that happens to be raging right now--- I hope people appreciate it). 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. But if there is, I have yet to find it. I'm half tempted to try to write one myself, by as I said at the outset of this post, I have bills to pay. Writing such a tutorial would be but another "fun" thing I could do, but sadly wouldn't help pay my rent.