LabVIEW

[fsustudent]

Hello,

I am an extreme newbie without much programming experience just starting labview, the attached PNG is meant to give you an idea of what I'm trying to do-- warning: it will probably break your heart.  I know it's breaking all the rules of good programming, but I have to start somewhere.  ANY comments or suggestions would be VERY VERY much appreciated. Basically, I want a program to send and receive text-based (visa) messages to set and read out some (~200, including all channels) hardware parameters.

Instead of having the user enter a setting and press "set,"  (using case structures) I would like a change in the control on the front panel to trigger an event which sends a visa message for that particular parameter only.  The problem is, I only have the 8.5 base package, therefore no access to event structures.  All the online resources I can find basically say "this is why to use event structures instead of anything else." My question is: what is the best alternative to event structures? What did you guys do before them? And most importantly, does anyone know where I can find some examples?? From what I can tell, my options are: somehow use the "wait for front panel activity" with (?!?!?different subpanels?!?!), use the "occurrences" function, use "notifier operations" functions, polling (note: everyone talks about polling, I haven't really been able to find any examples OF polling in a general sense, of course there are the examples of GPIB polling, but that's a function and doesn't help much), or somehow use a queued state machine.

Sorry this question is vague, I can figure out how to implement it if someone could suggest which of these is the best direction to start going in... Thanks!

Best regards,

Anna

PS. Thanks to Altenbach for GetVIImages.vi

http://forums.ni.com/ni/board/message?board.id=170&message.id=123849&query.id=139385

[johnsold]

Anna,

To answer the simplest of your questions: What is polling? Polling is placing the control in a while loop with a shift register and comparing its current value with its previous value on each iteration of the loop.  Since your are monitoring the front panel, put a Wait of 100-200 ms inside the loop so it does not become greedy and consume all available CPU resources.

Lynn 

[F._Schubert]

Doesn't look too bad for being 'extrem newbe'. Don't care too much about the event structure, your code looks a bit like when I was starting to learn LabVIEW and those days there was no event structure. Here comes some tips to improve your coding:

* What you do is polling, each iteration of the while loop you read all buttons. BUT: place a wait (50 to 200 ms) in the loop to have a responding interface.

* Place the VISA Serial initialze and the case loop.iteration=0 outside the loop (to the left and wire to the first case)

* Use a stop button to stop the loop and place cleanup code after the loop (connect by wires to ensure the execution)

* Remove all that unnecessary (oand wrong as there might be race conditions) stuff that reads from a local to the value property (or vice versa) of the same indicator/control.

* Use flat sequences instead of stacked sequences as long as you can't avoid them.

Felix

Edit: And it is 'Wait for front panel activity' that will replace the wait function for the polling, not notifiers or occurances.

Message Edited by F. Schubert on 10-16-2008 02:16 PM

[fsustudent]

Thank you Lynn for your simple explanation of polling.. And thank you Felix for your helpful suggestions- I will definitely try to implement them!  I just tried to make a simple polling while-loop with a "wait for front panel activity" as you suggested, (it works!) and I think that's how I will start re-structuring things.  Just one more question..

If I want to only send the hardware messages for the parameters that the user changed (instead of saying, something on the FP changed, update everything), do I need separate parallel while loops for each input control array (all 20 of them)?

Also, with VISA writing, is it better to open one session at the beginning and do everything with that (like I have it), or open and close sessions for each event? The latter, I guess, would require some kind of careful queuing..

I guess that was two questions. Thanks again- you guys have already been very helpful.

Anna

[F._Schubert]

Just your second question: Do the Open and Close session only once at beginning and end. Constantly opening and closing might really hurt performance.

Felix

[altenbach]

There are a few things.

• The "polling" isses have been covered. Make sure to still use a comparison for "changed" and a case structure, because the "FP activity" is often a bit too trigger happy.
• If you are really serious about LabVIEW programming, you should probably upgrade to LabVIEW full at one time.
• You make some serious "beginner mistakes" and use way too many local variables and value property nodes. You seems to use them like old fashioned "variables" of text based code. For example you get the loop iteration into a terminal, then read from the local variable of the loop iteration indicator and compare it with zero. All you need is wire [i] to the case structure and make one case "0" and the other the default. 90% less code!
• A local variable just points to the terminal, so for example in the image below you don't need to read from the local variable if the terminal is right there! Just bvranch the wire (see image). This also eliminates the race conditions (see below).
• In addition, you might get serious race conditions, because LabVIEW does not guarantee that the local variable is only read after the new value is written to the terminal. Most likely, a stale value is read first and placed into the value property. LabVIEW does not execute left-to-right. Order is determined by dataflow, and if dataflow is broken due to the absense of wires, execution order is unpredictable.
• Value property nodes are several orders of magnitude less efficient than wires or local varaibles. If possible, use wires, else local variables.
• Make a state machine instead of a code worm that is 10 screens wide. Code should fit on one monitor screen.

Attach your program and we'll show you some alternatives.

Message Edited by altenbach on 10-16-2008 01:37 PM

[waldemar.hersa…]

altenbach wrote: All you need is wire [i] to the case structure and make one case "0" and the other the default. 90% less code!

Don't do this on long term running applications. [i] will get zero every 2^32 iterations. Use the "First Call?" primitive instead, and make the "0" case "True".

[Jarrod_S.]

---

waldemar.hersacher wrote:

altenbach wrote: All you need is wire [i] to the case structure and make one case "0" and the other the default. 90% less code!

Don't do this on long term running applications. [i] will get zero every 2^32 iterations. Use the "First Call?" primitive instead, and make the "0" case "True".

---

Sorry, don't want to hijack this thread, but this is not true. The [i] terminal will not rollover. It saturates at x7FFFFFF.

[Gabi1]

Anna,

 Do not be put off by the constructive criticisim above. you did already an amazing job of documenting effectively the code, labeling the subvis clearly, and having a visually clear code structure. big KUDOS. You already know the most important things in LV programming.

Now is time for performance improvement, and learn some specifics about dataflow programming. Please do post your code (with subvis), and Altenbach (and others) will show you wonders in making your software really professional.

Gabriel.

[waldemar.hersa…]

Hello Jarrod,

I never tested this. It was just a guess that it will just count on and rollover. Thanks for this clarification.