Jim Kring

QUOTE (mballa @ Dec 23 2008, 07:17 AM)

Ok I know the first 3 from left to right.

Norm, Ed, Jim

but who are the other 2?

The other champs are Buddy Haun (hat) and Albert Geven (beard). And, the NI guy on the far left is Todd Sierer.

QUOTE (crelf @ Dec 22 2008, 07:34 AM)

I'm starting to think that Jim's got shares in NI's marketing department...

Is it my fault that the hot photographer babes are always taking my picture? Probably, since I'm http://thinkinging.com/2007/08/17/front-row-tickets-to-niweek/' rel='nofollow' target="_blank">always in the front row.

I've noticed problems when the class data contains a queue/notifier/event reference that includes the class data type -- this is a recursive type definition. You should (do as Tomi suggested and) make your Notifier use a generic LVClass reference and then upcast it to the more specific type after you receive the notification. This solution works very well and is how we solve this problem at JKI.

QUOTE (lenny wintfeld @ Dec 17 2008, 02:41 PM)

I've been teaching myself labview using Travis/Kring's "Labview for Everyone" and I have been making excellent progress on my own so far. I'm stuck, though, with one of the example VI's: "Disable All Controls While Busy.vi" from chapter 15. It's attached along with my version "Disable all while run.vi".

Hi Lenny,

I'm happy that you're making progress in learning LabVIEW with LabVIEW for Everyone and that you found the LAVA forums

Cheers,

-Jim

Hi Ton,

I think that we should position the discussion topic as:

Is a Polymorphic VI a good mechanism to conveniently access the members of a "library" (set of related) of VIs?

The main problem that this technique solves is that there is no easy way in LabVIEW (without using palettes) to access the other members of a library from an existing member (or reference/lvobject) on the block diagram. For example, Property Nodes and Invoke Nodes provide quick access to a menu of available properties and methods of various "objects" -- we need something similar for lvlibs, where we can quickly access other members.

So, what are the pros and cons of using the PolyVI in this way?

Pros

• Can use the poly selector terminal
  
• Can show instance icons
  
• Nice menu structure that can be used to group related functions
  
• All VIs must have the same connector pane pattern. (This is a "pro" if you like to enforce that all VIs must use the 4-2-2-4, or other, pattern. See "con" below)
  

Cons:

• All VIs must have the same connector pane pattern. (This is a "con" if you use different patterns for different VIs. See "pro" above.)
  
• It is not an expected/standard (yet) use of poly VIs
  

Can anyone else think of other pros and cons, or have comments on the ones that I listed?

Of course, this technique involves using a LabVIEW feature in a way it was not intended, but this wouldn't be the first example of overcoming a major LabVIEW limitation through creative use of other features. I'm starting to think that if we educate the LabVIEW community on this clever use of polyVIs that it might be a very useful tool.

Another side note is that polymorphic VIs are actually just a work-around for two major limitations in LabVIEW:

1. run-time (true) polymorphism (such as that which was finally made available in LVOOP)
   
2. "anything" (undefined) datatype/control (that can be used to propagate wire data type, at edit-time, from a subVI's conpane terminals to polymorphic inputs of primitive functions and inputs of subVIs with undefined inputs).
   

So, there's really no reason (aside from the name "Polymorphic VI") that polymorphic VIs should be used only for edit-time switching between psuedo-polymorphic VIs. The polymorphic VIs is really just a convenient editing tool that allows the user switch between an organized set of VIs at edit-time, which is what we're trying to do, here.

:2cents:

-Jim

PS - great idea, Ton!

QUOTE ("http://www.boingboing.net/2004/07/27/elizabot-passes-sexc.html")

...psychotherapists, who, in one experiment, couldn't distinguish actual transcripts of therapy sessions with schizophrenics from simulated therapy with schizophrenic chatterbots

AQ wrote:

> Does emulating God suffice to pass the Turing Test?

Makes me wonder... does emulating a schizophrenic person who thinks they are god suffice to pass the Turing Test?

QUOTE (Norm Kirchner @ Dec 8 2008, 12:54 PM)

NI folk should be granted premium status just by the sheer fact that they support the careers of most people on the forums and anything to make our lives easier in turn makes your lives easier.

It would appear that your http://www.wikisummaries.org/Built_to_Last#Chapter_6_.E2.80.93_Cult-like_Cultures' rel='nofollow' target="_blank">assimilation into the NI corporate culture is nearing completion :laugh:

Cheers,

-Jim

QUOTE (brianafischer @ Dec 5 2008, 11:03 AM)

Where did the App:Project.ActiveProject property node come from? I have been looking for this feature for since the project was introduced. It definitely is not in the NI Class Browser.

If you aren't able to see it, it's probably http://forums.lavag.org/VI-Scripting-Readme-First-t1207.html' target="_blank">scripting (a.k.a. a private VI Server feature).

QUOTE (Phillip Brooks @ Dec 2 2008, 10:07 AM)

Out of curiosity, is the "::" path constant input to the Build Path function a Mac specific value?

LabVIEW for Windows automatically replaces "::" with "C:\:"

The relative path of "::" on Mac is equivalent to ".." (parent directory) on Windows and Linux.

I tested opening the vi (Test File Patterns.vi) on LabVIEW 8.2.1, 8.5.1 and 8.6 in Windows and it works fine for me:

http://lavag.org/old_files/monthly_12_2008/post-17-1228245191.png' target="_blank">

QUOTE (crelf @ Dec 1 2008, 02:21 PM)

We have a new TALM (Totally awesome LAVA Member): http://forums.lavag.org/Totally-awesome-LAVA-Members-t5196.html' target="_blank">Jim Kring.

Thanks everyone! You all make it a pleasure to be a part of and serve our great LabVIEW community

Confirmed by NI and CAR # assigned.

[CAR 818352] Status: Fix planned for next major LabVIEW release (post 8.6 ==> 8.7 or 9.0?)

QUOTE (Tomi Maila @ Nov 29 2008, 03:24 PM)

Sounds like a bug to me. For a work-around, I don't have a mac to test but...

We can assume that there is an OS primitive dialog that LabVIEW calls. So try to figure out what the dialog in question is. It may be http://developer.apple.com/DOCUMENTATION/Darwin/Reference/ManPages/mann/tk_getSaveFile.ntcl.html' rel='nofollow' target="_blank">tk_getSaveFile or something similar. Now check the manual page for the identified OS primitive, how you should pass it the file pattern list and try to mimic it in your LabVIEW file pattern input. I don't know if this helps at all but maybe gives you a little hope.

Hi Tomi,

Thanks for the suggestion. I guess a work around might be to create our own native file dialog using Carbon Framework API calls.

-Jim

[cross posted to ni.com]

The file dialog allows specifying multiple types (that can be selected by the user) by passing the dialog primitive a semicolon delimited list of patterns. For example, you can allow the user to choose TXT or INI file types by passing a pattern of "*.txt;*.ini" to the file dialog primitive, as shown below:

However, when this is run on Mac OS X, neither of the specified file types is selectable by the user, as shown below:

I have tested this on LabVIEW 8.2 and 8.6 for Mac -- both have the same problem. Here is an example that can be used to test the bug:

Download File:post-17-1227995063.zip

The help documentation for the File Dialog primitive states that this should work on all platforms -- there is no exception for Mac:

QUOTE

pattern (all files)

Restricts the files displayed in the dialog box to those whose name matches pattern (all files). pattern (all files) does not restrict the directories displayed. The pattern matching in this function is similar to the matching used in matching wildcards in Windows and Linux file names. If you specify characters other than the question mark character (?) or the asterisk character (*), the function displays only files or directories that contain those characters. You can use the question mark character (?) to match any single character. You can use the asterisk character (*) to match any sequence of one or more characters.

For example, a pattern (all files) of *.vi;test*.llb returns matches for any file with a .vi extension and any file whose file name begins with test and has a .llb extension.

To match multiple patterns, use a semicolon ( ; ) to separate the patterns. White space, such as blanks, tabs, and carriage returns, are taken literally. Avoid using white spaces unless they are part of the extension pattern. For example, if you use *.html;*.doc, the dialog box displays all files that end with .html and .doc. If you use *.html; *.doc, the dialog box displays only files that end with .html.

Does anyone know a work-around or if I'm doing something wrong?

QUOTE (Justin Goeres @ Nov 26 2008, 02:43 PM)

Turns out the program I'm looking at doing this with shows its "About" dialog if you call it with either no arguments or invalid arguments. So that's delightfully unhelpful . For 99% of the other command-line utilties in the world, that would work.

Does the EXE have a benign argument/mode such as /?, /help, /version, etc. that just shows the help or version information?

I heard that Norm was offered the deal, due to his NIWeek keynote dancing (DDR) skills.

QUOTE (Dean Mills @ Nov 21 2008, 04:32 PM)

In case no one has looked inside the semaphore VIs. The semaphore is just a wrapper for a queue. I haven't looked inside it for many years (LV6 likely) but the not a refnum got me thinking, what is it inside. The rendezvous VI's are also just a wrapper for a queue.

Same with the classic (compatibility) queue VIs.

QUOTE (Neville D @ Nov 21 2008, 03:07 PM)

Hopefully, by now most people have moved away from the classic non-native Q's and notifiers, so they are less likely to be bitten by this. These VI's have been replaced by native function calls that don't exhibit this behaviour since atleast LV 7x?

It would be nice if NI cleaned up the remaining categories still affected namely: Semaphores, rendezvous and config files.

<nudge> <nudge> AQ are you listening?

Neville.

Or, how about native semaphores that can also store a single data element and that allow us to specify inheritance of the semaphore reference type

Omar,

Thanks for sharing your story with us. This is certainly one of those "Why did LabVIEW let me make this mistake?" scenarios, and every LabVIEW user will eventually make this mistake a dozen times over the course of a long career.

It should also be noted that this affects any of the non-native by-reference "objects", such as: (classic) notifiers, semaphores, rendezvous, configuration files, (classic) queues, etc.

QUOTE (BrokenArrow @ Nov 19 2008, 06:10 AM)

Don't take my stab at humor the wrong way. I was trying to point out how absurd NOT owning that book is, for the price Amazon is charging ($53 with free shipping). I actually have your older version. It'll be on eBay when my Ed.3 arrives, complete with coffee and beer stains! :beer:

No worries

I hope you enjoy the 3rd edition. Feel free to bring it to NIWeek and I'll happily sign it -- but that might make it worth less on eBay than the coffee and beer stains

Cheers,

-Jim

QUOTE (jlokanis @ Nov 18 2008, 11:45 AM)

I think your 'no race condition' code still has a race condition. What is there to prevent the semaphone from being destroyed before the lower path is executed? I think you need to wire the semaphore or the error out of the release call in the lower loop to the border of the sequence with the destroy in it to 'ensure' that the destroy cannot happen untill all code paths needing the semaphone are complete.

Great point -- yes, there is a race condition that could cause the destroy to happen before the bottom modification occurs.

I originally (when I created the example) had something like the one, below, but I removed the error handling to emphasize the use of semaphores.

You're right that (short of using error chaining) wiring the bottom semaphore reference to the destructor's sequence structure (as shown below) is a good fix.

QUOTE (jlokanis @ Nov 18 2008, 11:45 AM)

Yes, you could definitely use a single element queue. You could also use a functional global variable. Along those lines, Appendix D of LabVIEW for Everyone (where I pulled this example from) provides a historical overview of the different mechanisms for doing by (non-native) object-oriented programming in LabVIEW (and shows the natural progression of technologies and features). However, it does not touch the single-element queue or other more advanced implementations of by reference objects.

Thanks,

-Jim

QUOTE (BrokenArrow @ Nov 17 2008, 12:14 PM)

Why can't I just give YOU $53 directly, and then you answer every question I have from now on?

When did this turn into a negotiation?

QUOTE (ragglefrock @ Nov 17 2008, 02:43 PM)

When did this turn into a bidding war?

Please try again -- it's now available for download from within VIPM.

There can be a delay between when OpenG libraries are released and when the package becomes available in VIPM.

QUOTE (BrokenArrow @ Nov 17 2008, 11:03 AM)

Thanks Jim! Illumination.

You're welcome.

Now, just imagine all the other good stuff in http://labviewforeveryone.com' rel='nofollow' target="_blank">LabVIEW for Everyone

QUOTE (jdunham @ Nov 17 2008, 10:28 AM)

This is just a race condition, but I wanted to give a more concrete example. Let's say you have some kind of cluster or array which is modified in different threads of your application. You may have to unbundle or index it, replace the element, rebundle it, and wire it back into the global (or notifier or lv2 global or whatever). Between the unbundle and the rebundle, you have to make sure that no other thread can start the same process of unbundling, or else one of the copies will be stale and be victim of a race condition.

The normal way to fix this is to wrap the operation in a subvi so you can take advantage of the blocking behavior of subvi calls. However, this means the subvi has to know about every type of data you might want to replace in this global thing, which may lead to running out of terminal pane connectors, and generally ugly code. The other alternative is protecting the updates with a semaphore.

Yes, and this is the exact example used in LabVIEW for Everyone >> Semaphored Data Store (pages 912-917). Here are some screenshots of the example VIs from that chapter.

Race Condition (Buggy Code)

No Race Condition (Good Code)

-Jim