brian175
-
Posts
64 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by brian175
-
-
Here's another approach, but it will not work on VIs inside of llbs. I have only done some very limited testing but it appears to work on LV 6.0 and above. I don't have a 5.1 file but 5.0 files have a different offset.
-
-
LAVA has to fix the RSS feeds! Sorry I didn't answer sooner but I never saw the post. Jim your solution seems a bit extreme, why not just use the application method "Get VI Version" thats what I use in LVC.
-
Hello everybody. I have an interesting problem. The company I work for requires that all programs released have a version number associated with them that can be read by the GetFileVersionInfo function. None of my LabView programs return a version number, they actually return 0.0.0.0. Is there a way to provide version information that will eventually be stored in the final executable?
I do not know of a way to add a version number so it can be read by the GetFileVersionInfo function, but I do have a way to store version information in any VI including those without a diagram and/or front panel. There are a set of VI properties exposed for scripting that allow reading and writing tag information to any LabVIEW file. I have found this so useful that I have created a toolkit called VI_Tag Toolkit. There is a beta release available on my website. I use VI tagging to add version information to all of my applications and toolkits. I recommend creating a string tag with the following naming structure "company.product.version" for version information. For example the dqGOOP Toolkit has the string tag "DA.dqGOOP.Version" which can be read to get the version.
Here are the links:
Brian
-
It depends on whether you are using the tree control to store the data or display it. For example the tree example that ships with LabVIEW takes directory and first reads every file and sub directory and then adds to a tree. Here they are storing the entire directory structure in a tree (which takes a very long time). I wrote a tree control utility that only fetches the items as they are needed. So in my tree I only get the files and directories of the top level directory and when the user expands on a directory, then I get its contents and add to the tree. So in this case I can browse C:\ which has well over 1933 items but the tree control only contains the items that are being viewed. The tree never contains all the data, just what needs to be displayed.
I don't have time right now, but hopefully I can post an example if it would help.
-
-
Jim describes the OpenG resource "Rename Folder of VIs..." as a workhorse and it is true, I use it all the time. However, I typically use it to use an existing GOOP class or project as a template for another. As a result, I always have to first copy the source in Explorer and then rename. I modified the original routine to incorporate this step. Just drop the library in the ../LabVIEW 7.0/wizard directory and restart LabVIEW. (I can save down to LV 6.1 if needed, but not lower since I switched to an event structure to handle the UI.
Brian
-
Yes dqGOOP uses the type cast, but LabVIEW doesn't allow a (reentrant?) VI refnum to be the input type to the type cast function. I remember reading that the flatten => unflatten was the "trick" needed to enable converting the Object refnun to the VI data store refnum.
-
Converting to 6.1 will not be a problem, but performance is worse. dqGOOP takes advantage of internal optimizations that NI made to the queue in LV 7.0 and later. Converting to 6.02 will cause some broken arrows since the structure of the queue changed from LV 6.0 to LV 6.1. For one, there isn't a "preview" function in the 6.02 queue which is used by the getData function. You could possibly work around by using status or just dequeue and enqueue in the getData function.
I need to rerun my 6.1 performance test, but I think that niGOOP was the overall winner, but OpenGOOP was faster for set and get operations.
-
This time I'll try a zip file
-
I finally managed to install OpenGOOP, manually into LV 6... (Some VI was missing, which I found in the OGLIB_String package.)
I know GOOP 1.0 only was a bunch of shift registers, build arrays and such, and was quite slow, but is OpenGOOP faster?
And how is it compaired to GOOP 2.0?
BTW, how is it with OpenGOOP and named objects. I have used that with GOOP, so how do I do that in OpenGOOP?
The attached spread sheet has some performance data on OpenGOOP, niGOOP (GOOP) and dqGOOP. I created dqGOOP for performance, but unfortunately it requires LabVIEW 7.0 or later (it sounds like you're using 6...). Mark Balla started a discussion on dqGOOP here:
http://forums.lavausergroup.org/index.php?...=1392#entry4739
The first post has a zip file GOOPTest.zip that has three test classes (LV 7.0) and a performance test VI for each (in the Testing folder). [Two weeks of discussion on dqGOOP was recently lost due to an attack on the LAVA discussion forums]
OpenGOOP doesn't support named objects, but since it is open you could add that functionality. dqGOOP uses LabVIEW native queues so it supports named objects, with the added advantage that unique references are created when you obtain a reference by name.
I have not been able to test GOOP 2.0 performance or the new GOOP developer posted by Kurt Friday at:
http://forums.lavausergroup.org/index.php?...=1355#entry4509
Brian
-
NI support has a download for the same "Show Buffers" utility that is available in LV 7.1 for LV 7.0 :thumbup: Here is the link
http://digital.ni.com/public.nsf/3efedde43...4a?OpenDocument
This is an excellent tool if you are trying to optimize your code.
The attached images show how something as simple as wiring the error cluster to a case input and reusing the same wire of the case input can cause a new buffer to be created.
-
I realize this setup creates a huge performance hit
Here's a modified version of Michael's VI that doesn't have a "huge" performance hit. The trick is to minimize the number of times that the VI calls itself (due to the Open VI reference call). On my computer the listing of the LabVIEW directory took the following times:
Michael"s VI 2399 (ms)
Rolf K's VI 478 (ms)
Michael's VI modified 552 (ms)
OpenG 6717 (ms)
The test VI as well as Michael's and Rolf's original VIs are included.
Brian
How do you get the terminals of a subVI
in VI Scripting
Posted
I've looked around a bit, but I haven't seen any examples of someone using scripting to add an existing subVI and connect the terminals. If I wire a subVI path to the "New VI Object" primative, I can add a subVI to a diagram. But I can not get a reference to the terminals to wire it. Can anyone help?
Thanks, Brian