Jim Kring

So far, by poking around, i've found that there are several dll's that you can install to give you support for specific hardware.

Be careful not to do any "reverse engineering". Its a violation of your software license agreement (Section 3) :roll:

If you are interested, please post your findings to:

OpenG.org:LabVIEW Docs:Application Builder:7.0

-Jim

ok, serpdrv has been removed from the shared run-time folder in 7.0. Where has it gone and do I still need it for distributions?

Nope, you don't need serpdrv... now you need VISA. All serial port IO now needs to be done using VISA.

-Jim

OK, can someone please explain how the static vi reference helps me in LV7? I mean you can drag a vi into it and it gives you a reference but is it really just for property nodes? The online help says:

The Static VI Reference acts as a subVI and appears in the VI hierarchy of the top-level VI. You cannot use the Call By Reference node, Run VI method, or any other method to run a VI inside the Static VI Reference node. You also cannot use the Abort VI, Revert VI, Make Current Values Default, Export VI Strings, or Import VI Strings methods on the Static VI Reference node. To avoid recursion, you cannot have a reference to the top-level VI that the Static VI Reference is in.

How boring... NI, why do you give us crippled capabilities?

I just ran into this problem a few days ago. Yes, it is amost completely useless. If you are not going to either Call or Run your VI by reference, then there is really no need for a static reference. I believe that you can use "Call by Reference" if the VI is reentrant - but then what is the point? The only reason to do a "Call by Ref" on a reentrant VI is so that you can have multiple dynamic instances of it. Here you can only get one reference to your static VI.

I figured that I would hold back my initial disgust by looking for an example VI showing how NI sees us using such a tool, but there aren't any examples (that I could find) which use this new "feature".

I give it 5 "Eye Rolling Emoticons"

:roll: :roll: :roll: :roll: :roll:

-Jim

With dynamic events, I was wondering if there was a way to have controls with multiple functions. A good example would be a START button that would change into a STOP button. It would be great to have one event case per funtion and determine dynamically which case will execute for the specified button press. I was thinking that you would have to register the control for each individual function you wanted. Then the question arrises, how do you switch registration over to another event case. Any suggestions?

Here is an example that does this. However, it appears that there is a LabVIEW bug that is causing problems with the reregistration. :?

Download File:post-15-1073111573.vi

I create a strict-type indicator of enum datatype.

I place it on the front panel of a VI.

I right-click on the diagram terminal and select "create constant".

The diagram constant is a strict-type as well. This is correct, however if you notice the wire connection to the indicator has a coercion dot. Why?

Also, on another note. Before (in lv6.1), if you right-clicked on a

I have not "kept up" with the latest advances in how to structure a program in LabVIEW. My greatest evolutionary jump was to embrace the state machine form and force myself to think in terms of a state queue and state variable cluster.

So I have been coding away watching versions 6, 6.1 and now 7 go by. I seem to be doing just fine, without using any of the alternative archetecture functions. By these I mean basically ALL the program structure functions under Advanced-

-Semaphore

-Occurrences

-Notification

-Queue (NI's implementation)

-Rendezvous

-First Call

Does anyone have an opinion on what the NEXT evolutionary jump would be after the embracement of the state machine archetecture? If more than one, what would be the order of importance, from your own experience or in general?

Does anyone have or could recommend a course, book titled something like "LabVIEW Advanced programming - Beyond the state machine"?

Subtitled: "How not to let your technique sink right out of sight, as LabVIEW evolves" or "For those who have neither the time nor inclination to tinker with every single element provided on the Functions palette, until they have a clear understanding of what it does and how to use"

Best Regards,

Joe Jasniewski

Joe,

Regarding the question of "What's the next step after state machines?", I believe that it is component-based architectures. These use the OOP principles of encapsulation and modularity to aid in application design and maintenance. Although components may utilize highly complex messaging, internally, this complexity is not exposed to the users of the components.

If you are interested in looking into using OOP techniques in LabVIEW you might find the links, below, useful.

Graphical Object Oriented Programming (GOOP)

OpenGOOP - OpenG's GOOP framework

I would also take a look at the examples of each of the tools on the Advanced >> Synchronization palette. These are the tools that enable messaging and event driven programming. Messaging and Events enable functionality that is not possible with dataflow, alone. It allows you to define timing and data-flow relationships that are not transmitted through LabVIEW wires.

Once you have a grasp of the basic tools for messaging and events, you should invest some time learning the frameworks, architectures, and patterns, which utilize them.

Good luck,

-Jim

Is there any way to create a linked list in LabVIEW 6.1?

Use an array of Clusters. One element of the Cluster should be an integer numeric, which is the link to the next element in the list.

-Jim

Here is a revised example that closes VI FP Prior to subpanelling the plugins.

-Jim

Ya but if the subpanel is closed already, it generates an error. I guess i should turn off that pesky internal autoerror dialog...

Automatic error handling isn't for "application programming", it is for "express node configuring". Now turn it off, already, before people start making fun at you

Here is a revised example that closes VI FP Prior to subpanelling the plugins. If you want to re-open them afterwards, you could do that, too. Too bad you can't check if the diagram is open and reopen it after subpanelling. I'd love that VI Server feature :wink:

-Jim

Download File:post-15-1073110109.zip

When using subpaneled VI's the need always arises to send a message to it telling the subpaneled VI to stop execution. This apparently is not required when you run the "remove VI" method. Labview automaticaly aborts execution of the subpaneled vi. This might be a problem if you wan the subpaneled vi to exit gracefully.

I think that your assumption is wrong. The Remove VI method's documentation states:

Remove VI - Unloads the VI in the subpanel control. If no references to the VI remain, LabVIEW removes the VI from memory. If references to the VI remain and the VI stays in memory, this method does not change the state of the VI.

If you have an open reference to the VI it should keep running. It may be aborting because LabVIEW is unloading due to the fact that you don't have an open reference to the VI.

I guess you could send a message via a queue mechanism but if you run the "remove VI" method after that, there is no way to know for sure if the subpaneld Vi has finished execution.

Use a "Message Queue" which allows you to use "Response Notifiers" (visit the OpenG.org site to take a look at this project)

Any suggestions to perform synchronization? It would be nice to have the "remove VI" method contain a switch that you could set to have it "wait until vi completes".

Take a look at the other thread that I started here. There are lots of different ways to use subpanels and most will require some wrappers that implement the desired functionality. The wrappers have access to the VI reference so they can look at the VIs state, set/get control values of the VI, etc.

I constantly have the need to see if my loop is running. I end up having to stop the vi and wire a small connection from the loop iteration terminal to the wall of the for or while loop. I can then probe the wire to see the iteration counts. It would be nice to have this built-in. All I would have to do is right-click on the node and select probe.

Actually this idea should be extended further to allow probing any terminal that is a data source. Your example provides a perfect use case.

I only have the evaluation pack, but it sure is there (Hide control under Advanced on the right-click menu).

That's interesting, it's not in my full version... Anyone else to confirm this?

It's not is my Professional version either :wink:

Since we're on the topic of hiding controls. I think I found a related bug that will cause other problems. You can create a strict-type control, save it, and then place it on the diagram. Now if you goto the diagram you can right-click on the strict-type control and select>advanced>hide control. You will see that the control cannot be hidden, it is still there but you cannot select it or right-click on it either. The image is there only...

Too bad that you can't get a block diagram reference and unhide your objects like you did for hidden SubPanels :roll:

There I go again with the crazy talk!

The new subpanel control must be unique in the sense that it is not represented by a node on the block diagram.

Yes, this seems to be the only control that doesn't have a terminal on the block diagram. I can't understand why they didn't just do what they did for ActiveX Controls -- have the value of the subpanel be the Reference of the contained object, in this case the VI reference that is subpanelled. (of course you wouldn't be allowed to write the value, only read it, because the subpanelled VI is set with the "Subpanel VI" method). Now that I think of it, I don't think there is a way to find out the reference of the VI that is being subpanelled.

More food for thought: Decorations can't have explicit references, or property/invoke nodes on the diagram. Decorations can also be hidden on the front panel, travelling around in VIs undetected.

This has one funny consequence:

If you select "Hide control" and then delete the invoke node, there is virtually no trace of it at all. You could link a property node to it and make it visible that way, but you'd never be reminded that it's there. A potential source for hard-to-track bugs?

What we need is an UI that gives an inventory of the object on the front panel of a VI. You can use VI server to do this. Just get a reference to the VI and then get its 'Panel::All Objects" property.

Take a look at the Copy-Paste Boolean Attributes project at OpenG.org. It uses this technique to operate on FP controls.

http://www.openg.org/projects/project.cgi?ID=7

-Jim

What ever happened to http://digital.ni.com/lvwish.nsf/lv+wish ?

It is now redirected to an "Email NI" submission form.

Here's NI's new way of getting user input on the direction of LabVIEW: LabVIEW poll "Features you would like to see in LabVIEW!"

They're sure setting themselves up for success :roll:

I noticed that NI updated App Note 154 to now include Variant, Refnum, and Waveform Data Type (WDT). This is great! They even describe the new subtypes of the WDT like timestamp, dynamic data, and the various waveform types.

Way to go NI!

Download File:post-15-1073109843.pdf

I am interested to see how people are using the new Tree Control. Are you going to use them in conjunction with an event structure? For example there are some pretty cool tree structure events:

Tree Events (unique to Tree Control)

* Double-Click

* Drag

* Drop

* Item Open

* Item Close

As I see things, a Tree Control is a tool for visualizing some data structure (as opposed to a control that actually stores your data). When the user changes the tree control, by dragging and dropping items, one then has to capture information about the changes and then implement changes to the data structure that the tree represents. The Tree Control's events seem critical in this process. More power is given to also Filter events. For example, if the user does some Illegal action, the event can optionally be discarded.

Have you learned any insights that might be helpful to others?

One thing that I discovered is that in order to clear the entire contents of the Tree Control you have to call the "Edit Tree Items:Delete" method and pass an empty string to the "tag" input (shown in the image below). This was very non-intuitive, to me. I don't like functionality hidden inside of other functions -- I would prefer to have another method called "Delete All".

There are a couple uses that I can think of off-hand:

Synchronously + Call-By-Reference

This would be just like how you would call a subVI, except that you want its UI to be sub-paneled. In this instance we would (1) sub-panel the VI, (2) Call the VI by reference, and then (3) un sub-panel the VI. You can even make the plug-ins flexible by using variant data in and variant data out.

Asynchronous + Data Messaging

This would be more like how you would interact with an ActiveX control. You would sub-panel the VI, which is executing asynchronously. It has its own process (while loop) and it executes continuously until it receives a "shut-down" message. You would message data into it and out of it using queues, notifiers, or some other means. This allows you to effectively create controls with code behind them.

:arrow: I have attached an example of the 1st use case (Synchronously + Call-By-Reference).

Any other ideas?

Download File:post-15-1073110083.zip

LabVIEW 7's app builder has added a VI for programatically building apps. I have created this command line tool. However, it requires that LabVIEW development environment is running :cry:

Usage:

build.exe -- RelOrAbsPathToScript

-Jim

Download File:post-15-1073109764.zip

Does anyone know of a way to do a "find wire" command by right-clicking on a custom LabVIEW 7 probe? Apparently you can only do this for the old style probes.

Yes, NI knows a way :wink:

Sounds like a good one for the wish-wiki.

Cheers,

-Jim

Hello LAVA folks,

I wanted to invite anyone who is interested, to take a look at a new tool that I created. I call it a "Message Queue". The nice thing about this queue, is that when a message is enqueued a response notifier may be obtained. Then, when the message is dequeued by the message handler, the same notifier is returned. Finally, when the message handler is finished processing the message, notification can then be sent back to the message generator.

You can download the tool at:

http://osdn.dl.sourceforge.net/sourceforge...eue-6.0.1.0.zip

The download includes a simple calculator example and installation instructions. It is packaged so that you can just drop the tool into your user.lib folder and a pretty palette will appear. Let me know what you think. Obviously this doesn't solve all messaging problems, but it does address simple message and response needs. I am interested in your feedback and seeing any interesting examples and use cases that you come up with.

-Jim Kring