lvb

This looks like a very nice tool. It appears to have better integration into LabVIEW (Source Code Control menu, integration into the Project Explorer, VI Dashboard). A google search does not bring up many results, with only one mention on the NI site. A search on the NI site for TSVN Toolbar brings up no results! Odd for an application that was last released over a year ago. Even more odd is the google code project with an empty repository: http://code.google.com/p/vsi-tsvn-toolbar/

Just thought I would chime in on this topic. To my knowledge, LabVIEW does not provide a way to obtain the type descriptor of "OLE Variants" also known as "ActiveX Variants". Regardless of the OLE Variant type (VT_BSTR, VT_I4, ...). The type is returned as "External Data" from the LabVIEW Get Type Descriptor and "Reference" from the OpenG toolkit. This is due to the primitive flatten to string function provided from LabVIEW. There are a few related threads: http://lavag.org/topic/12182-database-toolkit-variants-vs-ordinary-labview-variants/ http://forums.ni.com/t5/LabVIEW/How-to-Get-OLE-Variant-Type/m-p/1334434 The only work-around I can think of is to pass this data to an external library (DLL) which can obtain this information. However, I have not done this and am not sure of the limitations or implications of passing by-reference OLE variants to external code... It would be great if someone that has created a work-around could provide advice...

FYI, this will break the class "Create Accessor" dialog. Right-click on a class -> New -> "VI for Data Member Access..."

It would be nice if LabVIEW had a way to force a constructor. Does anyone know why it is not an option to prevent a class object from being dropped on a block diagram? It would be excellent to have "callbacks" in classes such as OnCreate, but that would seem to break data flow. This may seem like a hack, but what about putting a boolean flag in the parent private data that is set only by constructor VIs? This way you could determine if the user called the constructor in the related methods...

Any tips on getting this Icon Editor to work in LabVIEW 2011? From NI's Website, it is not possible yet: To customize the Icon Editor dialog box for LabVIEW 2011, or if you have a custom Icon Editor from a previous version of LabVIEW, you can download the Icon Editor source files from the National Instruments Web site.

I am looking for some advice on class design and design pattern. I am designing a LabVIEW library that provides access to (and encapsulates ) a COM server. The COM interface has two variable types: System Variable Node Variable Common methods: Register/Unregister for Notifier Register/Unregister for Event Create Destroy Read Write Common data: Name Units Comment The variables differ in the refnum to the COM server and the possible data types that can be represented. System Variable Integer String FloatInteger ArrayFloat Array Node Variable Integer String I want to hide the existence of the System and Node variables from the user. They only need to know the variables that exist and the data types. I also want to restrict the user to only creating System Variables (within the COM interface). What are your design recommendations for: Where to store the "data" of the variable? How to provide the user with read and write of different data types? How to expose these functions to the user of this API?

Shameless bump for this thread... Does anyone on Lava know how to get a list of the Windows displayed within LabVIEW? It does not seem to be exposed through the Windows API.

I attempted to create some custom probes in my last LVOOP project and ran into a few stumbling blocks: 1. Default Probe is a Vertically Autosized Clustersorus The ideal situation would be for LabVIEW to utilize the layout of the class private data control, but this does not occur (in LabVIEW 2010 at least). For large classes with a few levels of inheritance, these probes get large, ugly, and difficult to manage quickly. 2. Each Child Needs to Duplicate the Parent Probe Unless I am missing something, I need to re-use the typedef and probe code of the parent for any child probe. This seems like a lot of busy work. Is there an easier way to create child probes containing the parent data? I am curious how LAVA developers manage probes within LabVIEW. Any tips or tricks? Regards, Brian

Ton, I am not sure why the forum insists on cropping the URL links below, so I apologize for the formatting. You will have to copy the URLs. My issues are on the JKI forum located at http://forums.jki.ne...curity-gateway/ Our company runs an Astaro Security Gateway which does not allow direct file downloads. This prevented VIPM from any operation related to the internet. Our solution was to whitelist sourceforge.net, jkisoft.com, and ni.com. VIPM acts a lot like a linux repository. Note: I used wireshark to packet sniff where the information is coming from. 1. Package Mirror List You can specify here a preferred package source. http://jkisoft.com/p...orgeMirrors.txt 2. Repository This downloads the available packages to obtain from the Package Mirrors. http://ftp.ni.com/ev.../index.vipr.zip 3. Packages These come from The following work-arounds exist: 1. IT Department Whitelist Extensions: .zip, .vip, .txt http://jkisoft.com/p...orgeMirrors.txt http://ftp.ni.com/ev.../index.vipr.zip http://www.ni.com selected sourceforge mirror 2. Download from home Install LabVIEW Run-Time Engine and VIPM. Download desired packages. Copy downloaded files from C:\ProgramData\JKI\VIPM\cache 3. Manual Package Download Subscribe to the RSS feed and manually download the files. Double click on each file to install with VIPM. http://sourceforge.n...gtoolkit/files/ RSS Feed: http://sourceforge.n...sc/limit/20/rss 4. VIPM Enterprise Repository This was suggested by Jim Kring. I am not sure how this would bypass the firewall: "Another option, altogether, would be for you to set up your own VIPM Enterprise Package Repository and, on your VIPM Clients located on your corporate network, disable (in the VIPM Options dialog) the connection to the VI Package Network. Then, have each of your VIPM Clients connect to your corporate package repository where you would make all the OpenG and other packages available to your corporate users." Hope this helps. -Brian

The recent direction of NI to push VI Package Manager leads me to believe OpenG will never be integrated into LabVIEW. It seems that NI is attempting to leverage the community for extra value added toolkits and re-use code while giving credit to the toolkit developers. Many of these toolkits have "NI part numbers" but are 100% supported by partners. I concur with the above reasons for keeping OpenG as a third party package. I believe the reason why some want OpenG integrated into LabVIEW is due to issues with the process of getting the library into LabVIEW. For instance, my organization had to tweak the firewall for VIPM to properly download the OpenG packages. I can see how this may be a hurdle to install "additional" software with IT among large organizations. And to follow-up on the original thread: thank you for the information. My hunch was backwards compatibility. It would be nice to have OpenG libraries excluded from the VI Hierarchy window which is not an option for user.lib.

NI is now suggesting that reusable libraries should be located in the vi.lib. I was curious why the OpenG Toolkit 4.0 is installed to the user.lib. File and Folder Names for Integrating into LabVIEW Thanks for all the hard work!

The "All Windows" dialog displays information on all child windows of LabVIEW. This dialog includes Project Explorer, Front Panel, Block Diagram, Class Hierarchy, .... All Windows Dialog Box Is it possible to access the same information through VI server or scripting? I would like to obtain all information listed in the "All Windows" dialog in my application.

I am very pleased to see that NI is integrating large application tools into the Developer Suite: What's New in NI Developer Suite"All Developer Suite customers will now receive the latest versions of LabVIEW VI Analyzer Toolkit, LabVIEW Desktop Execution Trace Toolkit and the LabVIEW Unit Test Framework. These professional development toolkits will make it easier to design high-quality and reliable systems with LabVIEW and NI products through the application of standard software engineering and validation practices." More features have been enabled from a LabVIEW base package: Viewing and Controlling Front Panels Remotely without a LicenseIn previous versions of LabVIEW, you need a license to view and control front panels from remote computers, and the license grants only a limited number of remote connections to front panels. In LabVIEW 2011, you can view and control front panels remotely without a license, and you can connect to remote front panels an unlimited number of times. My only wish at this point is for a Developer Suite DS2 ISO image to be posted. It is a pain to install the individual packages compared to the DevSuite installer. Is there any rhyme or reason when and if NI publishes this ISO?

I will be there also. I don't think I have met anyone from the LAVA forums in person yet so this will be a new experience. Norm - Are proceeds of our ticket going to you as the BBQ entertainer?

Currently the "Open NI Icon Editor" button launches the old NI Icon Editor. Is there a way to launch the new NI Icon Editor instead?

Just to make sure I understand this correctly, in which context is this true? When a .lvclass is opened in the IDE When a member of a .lvclass is opened My current understanding is that #1 will trigger all VIs and child classes and your statement only applies to #2. Templates are required to load the same VI into more than one subpanel on the same front panel. See "How Do I Load the Same VI into More than One Subpanel of the Same Front Panel?". Does a reentrant template load differently when launched through VI server? If so, I have not seen any difference in load time. Thanks for the suggestions to improve load time. It seems that a combination of #2 and #3 may help. Packed Project Libraries - If I understand #3 correctly, it seems appropriate to implement the low-level driver code for each signal type as a packed library that would be included in and called from the respective "Signal" class? For example, within the Digital Input Signal class, I would call functions from the PXI_Digital_Input.lvlib for communicating with the cards." My seperate PXI cards (packed libraries for each type) are used by the Signal Class Objects to read and write hardware channels Thanks for all the advice!

When I say there are hundreds of "unused" VIs being loaded, the majority are "Accessor VIs". All "Signals" inherit from a Signal base class. There are 12 classes that inherit directly from the Signal Class (Digital Input, Analog Input, Digital Output, Serial, CAN, ...) and another 10 which inherit from these (Relay Digital Output, Transistor Digital Output). It takes the same amount of time to launch a new VI from template that it does to load the class upon opening LabVIEW. Opening the Signal.lvclass takes about 45-60 seconds from which there are 419 files associated with the "Signal" class. Most of these are "Accessor" VIs that were created to provide access to class data through property nodes. That is an average of about 18 VI's per class which does not seem unreasonable. The Signal objects have a Get/Set ValNumeric and Get/Set ValString for access to the hardware. What would be the problem with this class design?

I am designing a large application which utilizes LVOOP to read and write "signal" objects which translate to physical hardware commands. A requirement of the application is to provide an interface panel that can load different types of signals (Integer, Boolean, Enumerated, ...). Multiple interface panels can be created (re-entrant), and each interface panel may contain one or more signal objects. These requirements have led me down the path of creating a re-entrant interface panel that contains SubPanels for signal display and control. I created a VI for each signal type to display in the SubPanel. Since multiple signals of the same type can be simultaneously displayed, I was required to create a new VI from a "template" in order to load within the SubPanels. The problem is that each SubPanel Signal (template) has an extremely long load time (45-60 seconds) due to the use of LVOOP classes. Since LVOOP requires the entire class to be loaded into memory and this is a large project, hundreds and hundreds of unused VIs are loaded into memory and the application is not responsive. To reduce the load time, I concluded that LVOOP classes cannot be used within the SubPanel VI's. I am in the process of completing a "re-entrant Daemon w/LVOOP" and "Template UI w/no LVOOP" architecture to separate the UI from LVOOP. However, I wanted to poll the community to see if anyone else has run into this issue with large application design. Any advice or suggestions to improve the performance of this framework would be greatly appreciated!

Jim, I am curious how you became aware of this service pack? The date on NI LabVIEW 2010 Service Pack 1 Development System says 2/17 was the release date and your post was on 2/15. I have been using the NI Update Service, but it does not seem to catch all of the possible updates listed on ni.com/support. Checking for updates again this morning, I am not prompted for any software updates. Is there a way to get notified from NI when there are updated drivers/service packs? Thanks, Brian

It seems we were posting at the same time! After reading your most recent post, I attempted to create a typedef and use that as the Cluster of class private data, but LabVIEW was giving errors. Any reason a typedef cannot be used as it would simplify this deep copy process.. I also noticed that a class VI snippet will have broken wires after opening... -Brian

Thanks for the example. I completely understand that creating a manual "constructor" to "deep copy" the parent to child is possible. I see two issues with this approach: 1. For objects of large size and multiple inheritance, a lot of manual work will be required to create the CopyParentToChild method. 2. There is no error checking if new private data is added to any objects in the inheritance chain. My main concern would be issue #2 stated above. It would be great if there was some method of "flagging" that I want to make sure ALL data from ancestors is copied. Any ideas on how this could be done?

I have an application that contains the following objects: Database.lvclass Signal.lvclass Diagnostic Signal.lvclass Input Signal.lvclass Output Signal.lvclass A "Signal" object array is initially created, but it is possible for an attribute to be added at run-time to these signals which makes the object a more "specific" class (diagnostic/input/output). The class type is specified by an attribute that is set AFTER a signal object is created. The creation of the Signal Object contains a lot of accessors (around 20). Initially I was thinking I could "cast" the Signal Object to a more specific class that would copy the Signal Object data to the appropriate descendant Diganostic/Input/Output Object. However, this will return error: Error 1448 occurred at To More Specific Class in CAN Signal.lvclass:Cast Signal To Type.vi Possible reason(s): LabVIEW: Bad type cast. LabVIEW cannot treat the run-time value of this LabVIEW class as an instance of the given LabVIEW class. According to the information from here, this is not possible and the current procedure for creating a descendant from an ancestor is to use accessors for every possible data item up the chain. However, a LAVA thread posted here seems to state otherwise, except it is an "old" lava post and the example cannot be downloaded! 1. What best procedure for creating a descendant from an ancestor? If more data items are added to the ancestor, is there a technique that will warn/errror if the descendant creator does not include? I have attached my initial attempt that has caused the Error 1448. Any help would be appreciated!

Jon, Thanks for your prompt response. Unfortunately, I have been tied up and not able to review the post until now. I am not clear on your previous response. Could you attach the modified project shown in your response? Also, I would be interested to hear the advantages of a SEQ. Thanks for sharing your knowledge!

Please elaborate!

I am running into a roadblock with implementing a design within LVOOP. I have a base class from which I would like to create multiple child classes. Each of these children should be singleton objects and I would like to override and implement one public function Command and Response "wireless" aka a LV2 style global. Basically, I am looking to re-use all of the functionality of the base class, but just have a wireless implementation for each "module" of the system. The structure of the base class is shown below: Remote Interface.lvclass Private Methods Create Destroy Interface VIG Public Methods Command and Response The Create method stores the class object in a VIG (LV2 style global). The Command and Response method calls the Interface VIG to get the current object. My first attempt was to simply create an override for the Interface VIG, but LabVIEW will not allow this with the following error: However, creating a dynamic dispatch input terminal would not allow for the Command and Response VI to call the Interface of each child. What is the proper architecture for this implementation? I have attached a sample project in LabVIEW 2009. Any help would be appreciated! Thanks Interface.zip