Jim Kring

QUOTE (Tomi Maila @ Nov 1 2008, 09:33 AM) 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) 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) 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 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) 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) 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) http://lavag.org/old_files/monthly_09_2008/post-17-1222663677.jpg' target="_blank">

QUOTE (eaolson @ Sep 19 2008, 12:05 PM) 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) 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) 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) 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) 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) 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

QUOTE (Aristos Queue @ Aug 30 2008, 01:27 PM) I didn't say that being able to see the scope while looking at a subVI is a bad thing -- I think it would be great and I support that feature. My take home point is that (and, maybe I'm just an old-timer, but) I think that most LabVIEW users interact with VI's, primarily, and with projects (.lvproj) and libraries (.lvlib), secondarily (especially in the context of debugging). As such, having ways to identify and modify VI settings (and, yes, I realize that this is an lvlib setting associated with a VI) easily from the VI, itself, is important -- especially, when the setting impacts the way that the application, as a whole, will run (or not run). If LabVIEW is going to limit feature visibility and access to the project/library environment, then it needs to do a much better job of allowing LabVIEW users to quickly get to the project/library from the context where they are programming their applications. For example, how come it is so hard to locate a VI inside of the project/library/class from a VI's front panel or block diagram? How come there is no way to open a class from the class hierarchy window? I think that there are several usability roadblocks with respect to libraries/classes and PJM's suggestion stems from trying to bridge them. That's why I don't think Philippe's request is "strange" (as you suggest). While it might not make sense, theoretically, it does make sense in practice. And, those of us who echoed support for PJM's request spend a lot of time practicing LabVIEW. That reminds me of a great quote I read today in http://www.codinghorror.com/blog/archives/001166.html' rel='nofollow' target="_blank">Jeff Atwood's blog article on deadlock: QUOTE ("Jeff Atwood") In theory there is no difference between theory and practice. In practice there is. Cheers, -Jim

QUOTE (Aristos Queue @ Aug 30 2008, 11:01 AM) True, but whether the VI is private or public makes a huge difference to how a caller (calling VI) will behave when you try to run that calling VI. For example, if the caller is not a member of the same lvlib as the callee, then the scope of the callee (e.g., if it's private) can cause the caller to be broken. When one is trying to debug and resolve this problem by opening up the VIs in question, there is neither a graphical indicator of the problem nor an easy way to resolve it, without going through the (relatively painful*) process of locating the callee in it's lvlib and changing it's scope. * Note that the http://wiki.openg.org/Ogedit_file_locate_in_project' rel='nofollow' target="_blank">OpenG Locate File in Project tool makes this somewhat less painful.

QUOTE (Aristos Queue @ Aug 29 2008, 08:21 AM) AQ, I don't find PJM's request (making the access scope visible somewhere on a VI's FP window) strange at all. LabVIEW isn't like other programming languages/IDEs. When one interactively develops and run a LabVIEW application, they often have their VI front panels and block diagrams open. Knowing the access scope of VIs is very important, in this respect. Based the argument you provided, it would follow that LabVIEW users shouldn't care which Application Context a VI is in (when they're writing it), either, so why doe LabVIEW show the context name in the lower left corner of each VI? The answer is that this information is useful during and after development, when one presses the run button and needs to know (beforehand) in which context the VI will run. Similar utility would come from knowing the access scope of a VI when looking at a VI's FP or BD. Other programming languages don't give developers a tangible way of interacting with functions, the way that LabVIEW does. LabVIEW is different and special. Things that don't make sense for text-based environments, might make great sense in LabVIEW. Thanks, -Jim

QUOTE (HChandler @ Aug 29 2008, 03:03 PM) If you need a break from your relinking troubles, check out the video we just posted of our NIWeek 2008 presentation, http://jkisoft.com/niweek/2008/effective-labview-code-reuse-strategies-and-tools/' rel='nofollow' target="_blank">Effective LabVIEW Code Reuse Strategies and Tools. Cheers, -Jim

QUOTE (HChandler @ Aug 28 2008, 03:24 PM) AQ's advice about splitting out your reusable VIs into a separate project is a good one -- when you create something that's reusable, you need to start treating it like a separate software product (with versions, customers, etc.). Putting your reuse VIs into an lvlib can certainly help avoid cross-linking, but it won't help you manage your reuse library's software life cycle or aid in managing projects that use the reuse library. As others have mentioned, VIPM exists to help you take control of your reusable VIs. And, you asked the question at the right time -- you haven't yet lost control. I recommend that you download VIPM and try to make a VI Package, by following our Package Building Guide. Oh, another great benefit of using VI Packages for your reusable VIs, is that you can add them to the LabVIEW palettes (and customize the layout). Thanks, -Jim