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

[shoneill]

I suppose you're right that your intelligence and professionalism has been severely attracked in this thread, but it's all your own work.

We're mostly private people here, many of whom have learned LV themselves (Without books, without courses) but there's one major difference between us and you. We're willing to listen to what other people are telling us and to learn from their advice.

You have consistently given an very bad account of yourself in this forum, and although I wouldn't go as far as to say I "Love" LabVIEW, I DO recognise that it has many advantages over other "Standard" languages and see a need to defend this against people making unqualified negative remarks about it.

You have posted a total of, I believe, three questions regarding programming in LabVIEW. All three were answered with speed, accuracy and politeness. Your unwillingness to accept these answers and the associated programming style is the real limiting factor in your learning LV.

Other points such as event-driven programming being the solution for sequential logic is simply false. Nobody said this. I believe you have mininterpreted a previous post.

I'm serious whan I repeat what I said earlier that I find it a shame that you don't step back a little and reconsider having another look at LV with an open mind as to how it works. I believe you would find it surprisingly flexible and stable.

I wish you lots of luck in your future programming endevours (in whatever language you choose)

Shane.

[tst]

I suggest you take the time to reread this thread. You may realize why it turned out the way it did.

You say you asked one question - "how do I do sequential logic?". That's not true.
In your first post you asked how to have a latched button so that the dialog will stop popping up

---

"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.".

---

A good and valid question which was answered by 2 different people within 15 minutes. In the ensuing discussion it was said that various functionalities in sequential logic can be implemented by using subVIs and Ben suggested you look at the state diagram editor (and referenced the vending machine example).
It sounds to me like you were mixing up things like Flip-flops and JKs (which I really know nothing about. Is there a field called "sequential logic"?) and sequential execution (based on logic), which can be achieved in several ways in LV, the most versatile being the various forms of the state machine, which is a standard software design tool. It seems that Ben understood because he gave you the answer.
Contrary to what you say, event driven programming is not necessarily the answer to the question (which you didn't ask). In LV, the term "events" refers to things which can be handled by the event structure. A state machine is an event handler in the sense that it does nothing until some condition occurs, but it does not only handle "events". A state machine could also be used, for example, if the vending machine was speaking to LV through serial or ethernet communication, which does not have "events".

So, what does it look like from our perspective?
You come here, you claim that no one "really understand" LV (I hope you realize how ridiculous that sounds).
You seem to ignore the suggestions we give you (Ben's link, my links) and our opinions (which exist for a reason).
You throw together several unrelated topics (books, sequential logic, LV design).
Instead of stopping and reprhasing your question so you can get an answer, you say you give up.

That should help you understand why you received the responses you did. This board has a lot of activity (I would say 150-250 posts on an average weekday) and most questions get answered quickly and politely. Even your posts got real answers (whether you think so or not). The people here are good natured (and humored. Look at the Rocky & Bullwinkle posts), but when they see something like this, they respond accordingly, so, believe it or not, this does reflect on you. Whether you want to use LV or not is up to you, but there is no reason to take it out here (at least as long as you do what was described in the previous paragraph).

[Ben]

"
talking about a level of programming lower than assembler--- the one at which assembler instructions in the VAX, for example, were implented.
"

Hi Moose Man et al,

I have traveled the road you your are concidering abandoning.

I started with discrete gates implemented using triodes, transistors, gates, ALU's and then microprocessors.

I studied the micro-code used in PDP-11's KL-10's and VAX's.

I moved through macro DCL and C.

I have now obviously moved to G.

I am sharing this to info in an attempt to let you know that I think I can appreciate some of your frustration.

In my case, my initial attempts at coding in LV were frustrating, and filled with problems. I think it took me about half a day to figure out how to wire two nodes. I did manage to get some basic stuff running and thought I had it figurted out,
BUT...

I then took a job with one of NI's Selecte Integrator's who insisted that I take the NI courses.

Durring these courses I learned why my programs did not work quite right sometimes etc.

BACK TO THE POINT!

Moose Man,

I believe the path from lower level languages to higher level languages is the harder of the of the two routes.

The challenge you have confronted is monumental.

You will have to go through a paradigm shift. The way you mentally structure code in LV is very much "inside out" from lwer level languages.

In machine language I would do something, etc etc then check if I should go back to the top.

In LV, I have to think about the check FIRST and then do the stuff. Inside out, upside down, whatever.

In my first reply to you I said you would be OK after you get over the learning curve.

In fact, I believe you will be at an advantage because of your background. You will have an insight into the elegance of of some of the operators and be able to grasp parallel processing and resource sharing that is hard to understand without the low level experience.

PLease look into the info on state machines! You will find that it plays out like the state transition diagrams that used to be used to describe micro-code.

let me close by sharing a "Sea Story".

After working hard to get a search radar working, I returned from a couple of days of leave to find out that the fleet commander had ordered the MY RADAR be removed from my ship and installed on another ship that was scheduled to sail. I found my equipment cabinets had been gutted and a pile of parts on the equipment room floor.

I had difficulty getting it back together and finally got to the point that had prevented the other ship from getting the system working in the first palce. I worked until tired and frustrated and ended up venting to my chief petty officer and uttered the words "I quit!". He looked me straight in the eye and said "Ben, the only way you can ever fail, is by giving up! As long you do not give up, you are just still trying".

Moose Man,

My chief was correct. I am not giving up on you. Please concider trying again.

We will continue to try to help you get over the LV hurdles.

Ben

P.S. Proving that there is life after DEC.

[ian_fung]

Hello all,

I am not here to attack anyone but to tell you my personal experience about LV 🙂

I started from LV5.1 and I have not really read to acommplish my tasks. What is so great about LabVIEW? The answer is the G!

I have many colleagues/ friends who once picking up LabVIEW, never wanted to quit.

Mr. Moose Man, you are the first since I come to know about LabVIEW. Perhaps, you really wanna re-consider 🙂

Just like most of my postings, I type less but wire more 😛 hence LabVIEW the G!

Cheers!

[Dennis_Knutson]

You are absolutely incorrect about your assumption that your "coke machine" requires the event structure. I don't know how many times it has to be said, the programming of your mythical machine can be done without a single event structure. Once a button on the front panel is detected, a state machine programmed with normal dataflow elements does the job. The event structure eliminates the need to poll the front panel for changes (a user event) but it is not required. Have you actually bothered to look at the examples? There is a VI called State Machine Test Sequencer (sounds like what you were trying to do). Look and compare Old Event Handler and New Event Handler. The Old Event Handler uses a shift register to contain the next "state" that the program should execute and it constantly polls the state of the front panel controls. The New Event Handler uses the event structure to detect a button pressed. The perform the same basic tasks in slightly different ways. Now look at Queued Message Handler. This is a more sophisticated state machine architecture. This design is actually much better in implementing complex sequential logic as you call it. Note that this example doesn't have a single event structure.

[Moose Man]

This makes no sense to me whatsoever.

[Donald]

---

@Moose Man wrote:
Well, when someone puts a coin into a machine, isn't thata "user event?" ... The idea of "user events" caused by a user depositing, a nickle, a dime, a penny, or whatever, is the same. In this example, the data driven paradigm really doesn't work. Nor does it work for a good number of other real world applications--- any application in which a user presses a "begin test" or "abort test" button. From version 6 on, NI recognized this by providing event structures.

---

Moose Man,

With all due respect, I disagree with your comment that the "data driven paradigm"/dataflow concept doesn't work for the given example or "any application in which a user presses a 'begin test' or 'abort test' button".

It has worked as far back as LabVIEW v2 and probably v1 (pre-Event structures, pre-local variables, pre-etc. etc., but with momentary Boolean controls). It works in a way not too different (for me at least) than what old PLC manuals might refer to as the "current flow concept" when explaining relay ladder logic diagrams to the uninitiated. While some see depositing a nickel as a "user event", others see it as a change of state that increments a value held in a shift register flowing around and through a While Loop until the correct total amount has been deposited.**

Good luck with whatever tool and paradigm you choose.

** If it's a retro Pepsi machine with pricing circa 1940, you get a nice big bottle for the nickel.

[John Rich]

Moose Man,

As has been stated before in this thread, LabVIEW is a dataflow driven language. In your example when a quarter is put into the machine this corresponds to data input to the machine. The algorithm is then written to react appropriately to this change in data. For example, in a state machine approach the insertion of the quarter into the machine would cause the "Quarter inserted" state to begin. This state could add 25 cents to the previous change inserted counter. Pressing the vend button on the machine causes the machine to go into the vend state. This state would check to see if the inserted change is greater than or equal to the required change. If not, it will go to an "insert more change" state. Otherwise the machine will go to a state which vends the product and calculates the change. Now granted there may be many states which are required in the state machine architecture, but all can easily be handled in LabVIEW.

You stated that you think that nobody really knows LabVIEW. I would beg to differ with you on that. Just look at some of the large applications which are discussed here. I don't think that these applications could be developed by people who don't know what they're doing.

You have never said whether you have tried any of the tutorials or looked at any of the many shipping examples that comes with LabVIEW as has been suggested. I think that you should start with those so that you can get an understanding of how the LabVIEW dataflow works doing very simple things before moving into the more complex state machine.

[Moose Man]

"You have consistently given an very bad account of yourself in this forum, "

Oh really? How so? How about some specific cites of me giving "a very bad account of myself?" And what about "proven" something-or-other who calls himself hbob? Was he just the perfect gentleman, in your view? Was he completely professional--- like you?

Even though I've said I'm through with Labview, and expressed regret over having ever posted here at all, you guys won't stop, will you? Since you people refuse to stop, I've placed a call to NI's legal department asking them to stop it.

[Moose Man]

"So, what does it look like from our perspective?
You come here, you claim that no one "really understand" LV (I hope you realize how ridiculous that sounds).
You seem to ignore the suggestions we give you (Ben's link, my links) and our opinions (which exist for a reason).
You throw together several unrelated topics (books, sequential logic, LV design).
Instead of stopping and reprhasing your question so you can get an answer, you say you give up."

This is completely false, and you know it. What you say I "came here with" was posted only after a mountain of personal attacks were made against me. These "unrelated topics" which you say I threw in here were all "thrown in" long after the discussion here had degenerated into a personal and professional attack upon me. And they were "thrown in" only to help show the charges and accusations made against me were groundless. I beleive I've have done a fairly good job of that.
Again, the relatively little time I have spent involving myself with Labview has proven itself to be a mistake. I'm not going to throw any more good time after bad.