Jim Kring

QUOTE (Val Brown @ Nov 17 2008, 10:13 AM)

There is "Not A Semaphore" for the simple reason (I assume) that one might want to test for its existence. This is similar structurally, is it not, to having "Not A Refnum..." and such.

Yes, especially since the "Not A Refnum" function does not handle Semaphores (or "classic", non-native Queues and Notifiers).

QUOTE (BrokenArrow @ Nov 16 2008, 10:53 AM)

I really can't see what you can do with a Semaphore that you couldn't do with a local, global, or a Notifier. Does anyone here commonly use them?

Semaphores are ideal for enforcing mutually exclusive access (i.e. locking and unlocking) to a shared resource (global data store, communication pipes/sessions, instruments, etc.). For one great example, see:

"LabVIEW for Everyone", 3rd edition >> Appendix D, "LabVIEW Object-Oriented Programming" >> Semaphored Data Store (pages 912-917)

Semaphores are rarely used, casually, in LabVIEW programming. However, they are extremely useful in certain situations.

QUOTE (hooovahh @ Nov 7 2008, 07:32 AM)

I too have played around with reuse libraries and adding them to the palette properly. A tool you might find interesting is the Palette API which was posted in LAVA some time ago which originally was found on NI's website but it has been taken down since. However the API is still available in the LAVA post.

http://forums.lavag.org/LabVIEW-Palette-AP...ased-t8292.html

It basically lets you programatically read and write .mnu files.

It's worth noting that the Palette API ships as part of vi.lib in 8.6, which might be why the code was removed from NI's website (which I haven't confirmed).

I am using "vi.lib\AppBuilder\BuildTargetBuildSpecification.vi" to build a Build Specification in my LabVIEW Project, programmatically. The build takes a while and I would like to get status information while the build is happening, just like the progress/status dialog shows when you run the Build Specification from within the Project Environment. I have not found any way to get the status information.

I did find a global variable, "ABAPI Dist Build Status.glb.vi", that looks promising. However, it probably only has status information in the Application Context in which the builder is running. I'm wondering what the name of this application context is, so that I can try to obtain the status information. Any ideas?

QUOTE (Daklu @ Oct 28 2008, 09:54 PM)

As much as I'd like to use it, cost is the barrier stopping me from using it. Yeah, it would pay for itself by saving me time, but my incremental cost is somewhat hidden while cutting a PO for n VIPM licenses is sure to raise a few eyebrows.

Why not start with just 1 VIPM license? This will allow you (or another member of your team in a reuse librarian mode) to build VI Packages that everyone on your team can install with the free VIPM Community Edition.

This could also serve as a way to demonstrate to your team the time (i.e. money) savings that is possible using VIPM to more effectively and efficiently reuse code.

QUOTE (TobyD @ Oct 29 2008, 12:26 PM)

Oops, I missed this post. I agree completely

QUOTE (Tomi Maila @ Nov 1 2008, 09:33 AM)

Any particular reason you do not want to interface the LLRP C libraries?

I haven't looked at them yet. I figured that I would cast a wide net and see if anyone's done any work with LLRP in LabVIEW, including possibly calling into the C libraries as a CIN or DLL.

QUOTE (jcarmody @ Oct 31 2008, 05:03 PM)

I hope I didn't hijack your post. Perhaps I misunderstood your original post and you won't need a state machine.

Hi Jim C.,

Regarding questions about best practices and design patterns using the JKI State Machine: If you ever want to start up a separate thread, we do have a forum dedicated to this, http://forums.jkisoft.com/index.php?showforum=46' rel='nofollow' target="_blank">here. Whenever you want to make sure that someone at JKI sees your post, that's a great place to start (although we do frequent LAVA, of course ).

Cheers,

-Jim K.

[cross-post]

Has anyone done work in LabVIEW with the LLRP protocol for RFID readers? I've googled around and didn't find anything.

QUOTE (Omar Mussa @ Oct 23 2008, 12:05 AM)

I'm confused why you are forced to make up words. I thought you had to be POTUS to do that

For example: "It takes an evilender to stop an evildoer."

Should this concept should be coupled to the term "source"? This problem is generally applicable to identifying members of any set that have an external dependency (which effectively causes the entire set to have said dependency).

What if we describe these things as "externally dependent" or "having external dependencies"?

Or, along the lines of your original idea, what about calling these things "internal-enders"?

QUOTE (ivan00 @ Oct 21 2008, 11:33 AM)

Hi !

just discovered the openG site. To opwn/use those vi's one needs the vi-manager. Does the new version of vi-manager work on my 7.1 LabVIEW ?

As I'am still looking for a appropiate filter for my 1D array ...

Thanks

Ivan

Hi Ivan,

In order to install VIPM 2.0, you will need to download and install the LabVIEW 8.2.1 Run-Time Engine. There are details on installing VIPM and obtaining the OpenG libraries, here. You'll find this video tutorial useful.

Also, for filtering the array, you'll want to make sure that you have the oglib_array package installed.

Thanks,

-Jim

QUOTE (Aristos Queue @ Oct 19 2008, 08:39 PM)

a. The behavior is not new for any of the three properties shown here.

b. There's a very simple principle at work here. The question "Is *" has three answers: true, false and not a valid question to ask. For example, before checking IsClone, you should have already passed an "Is VI of StandardVI type?" test. It makes code more robust in the long term. When we introduce a brand new VI type, it is much better for code to light up with errors that scream "this code has never been intended to handle this new VI type and you should visit it to explicitly handle it somehow" as opposed to silently doing something that may or may not be valid to do with that type. Here's an example: Suppose we introduce a new "recursion VI type" that explicitly allows recursion in some strange way. But there is some piece of code somewhere that does the following:

1. Traverse VIs looking for a cycle of references

2. When a cycle is found, check each VI and ask "Is 'share reentrant clones' enabled on this VI? If not, return error (recursion not allowed).

This new Recursion VI type does not have "share clones enabled". Indeed, it is never valid for this new type to even have clones. Your code is now wrong if one of these new types comes along, but if the property just says "false", you'll never know it.

For the record, there is no Recursive VI type in existence anywhere in development, but it was a hypothetical example that I came up with to illustrate this point.

If LabVIEW wants to enforce whether the question is valid, shouldn't it be enforced at edit-time through reference wire type? What I mean is: shouldn't there be VI Server subtypes of VI, just like there are control and lvlib subtypes? It sounds like the editor is being lazy and making life harder for me.

:2cents:

When reading the "Is *" properties of a VI, the Property Node will output Error 1035 with the explanation that "Operation is invalid for this type of VI."

This doesn't make sense to me. Shouldn't these properties simply output FALSE if you try to read them for VI subtypes (Poly VIs, Globals, CTLs, etc.) that don't have the property? Raising an error just makes code dysfunctional -- the worst thing is that this seems to be a new behavior and is breaking my existing code.

Download File:post-17-1224467548.vi

HChandler,

Chris and Joe pointed you in the right directions.

By far, using VIPM Professional to download and create a VI Package Configuration (*.vipc) file containing the required packages is the easiest approach. (I've just finished updating the page with instructions that Chris referenced.)

Regarding the installation of non-approved software, you'll definitely want to get VIPM and the OpenG packages approved by your organization I know that I couldn't live without the OpenG VIs.

If you have any questions or need help with VIPM, please feel free to post to the JKI Software forums or send us a message.

Thanks,

-Jim

QUOTE (Minh Pham @ Sep 30 2008, 10:56 PM)

Dont like the GUI of this site much, I'd better stick with this site as I am still a new member to this

awesome site. Go LAVA !

The point of the stackoverflow.com site is that users ask programming questions and people reply with answers to the programming questions. Answers get voted up and down, with the best answers floating to the top. LAVA is much more than this -- it's a discussion forum with a suite of other community features like a wiki, code repository, and more.

I've been follow stackoverflow, too -- it's a great concept. It will be interesting to see how it evolves.

QUOTE (gleichman @ Sep 28 2008, 07:41 PM)

Watch out for the following scam email. It was reported today in the New York Times.

http://lavag.org/old_files/monthly_09_2008/post-17-1222663677.jpg' target="_blank">

QUOTE (eaolson @ Sep 19 2008, 12:05 PM)

I think there's a lot to be said for (a) organization and (b) consistency. One of the advantages of style guides is that they push you to doing both. E. g., there's no particular reason for OpenG to use that particular shade of green for its VIs, but it's a lot nicer than if those palettes were a rainbow of different colors.

Since it was brought up, I should mention that OpenG Green is defined in our OpenG Coding Standards, another good place to look for coding style guidelines.

My thoughts are The LabVIEW Style Book are here.

Also, this is another good book (I think you know the author ).

QUOTE (Tomi Maila @ Sep 17 2008, 09:34 AM)

Toby, that is a good point. However you must also consider if your intellectual property is actually more safe on a managed third party server or on your own server where security issues are patched on a random basis.

I agree with this sentiment, Tomi.

Hosting companies (more so with highly reputable ones) have a huge incentive to ensure the security of their customers' data -- it's the life-blood of their business. So, it's s something that they must continuously consider, test, and build into their process. I'm sure that service providers can do a much better job of security than most small- and medium-sized companies. However, large companies (with large IT departments) can probably do a good job of security, too. But, they typically tend to do this by severely crippling the usefulness and adaptability of the IT environment. For example, they make sure that your subversion server is secure by not providing you with (or letting you manage your own) subversion server

The good news is that the corporate world is starting to get more comfortable with the idea of software and IT resources as a service. Large companies just move slow and have large IT teams that need to hold onto their jobs.

QUOTE (rkanders @ Sep 16 2008, 09:01 PM)

I decided to put LV installation folder under version control. Mainly so that it is easier to keep in synch different development machines and to be able to do externals with Subversion. Subversion stores info in .svn folders which are hidden, nevertheless LV seems to see them.

I think it slows down some of the labview ops (menus, new... dialog, etc.). :clock:

Has anyone else had any issuses with this approach?

Thanks,

Reinis

You've hit one of the common pain points of reusing LabVIEW VIs. My advice it to create a VI Package of your reuse library, which will install them into the User Libraries. You can create a VI Package Configuration file (a snapshot of which reuse libraries are installed in LabVIEW) for each of your LabVIEW projects and keep that file in your project source folder, under version control. You can see JKI's http://jkisoft.com/vipm/guide/' rel='nofollow' target="_blank">Package Building Guide for more info.

QUOTE (crelf @ Sep 10 2008, 09:10 PM)

That's going to be one hell of an options page...

How about having the ability to "teach" the block diagram cleanup tool what a good block diagram looks like? It could gather various metrics on your code to determine the optimal settings just for you.

QUOTE (Norm Kirchner @ Sep 10 2008, 05:48 PM)

Well in that case I'll just have to go the Price-is-Right cheapo way ($1) and toss some crap together just to make sure if it's a 1 horse race I'll win.

That's called strategy baby!!

Don't forget to run the diagram cleanup tool on it

I would use VIPM to create a package of your class. This way, you can easily get your class in the palettes and also achieve version control and configuration management in your projects.

QUOTE (Vincent Wong @ Mar 22 2008, 06:54 PM)

Thanks for the advice Yen. I also noticed all the VIs I uploaded earlier didnt link properly.

The code has been updated and made more robust.

-Attribute handling was fixed

-Selective clearing of Arrays has been fixed

-Code is cleaner and runs faster

-A new/better example is included showing a variety of features.

Still written for LabVIEW 8.5 and needs OpenG "oglib_*" toolkits

Hi Vincent,

Have you tried creating a VI Package for this library using VIPM 2.0? By default, VIPM will build all of the OpenG VIs into your VI Package, so that users won't need to download them. Or, you can choose to make this a dependency. We have a Package Building Guide that is helpful in getting started.

As a good "critic" of JKI software, I'm very curious about your opinion

Cheers,

-Jim