lvb

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...

I'm also a fan of this editor (though I wish its text abilities were used in the default editor). It is possible to get this working in LV 2011 -- you just need to delete/rename the lv_icon.lvlibp file in the resource\plugins directory, which now contains the lv_icon.vi file.

It would certainly be nice if there was an easy way to swap between editors while editing an icon.

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

Brian, could you specify how you tweaked the firewall. I don't know where the OpenG packages are hosted (and I don't think IT is willing to open the firewall for sourceforge.net), so if you have any info on that please add.

Ton

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

Because it's not (yet????) an officially supported re-use library -- not officially supported by NI that is. But at another level you ARE right -- it should be there because it should be "adopted" by NI. Well at least that's my perspective on it.

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.

Wouldn't really be Open Source if NI owned it and distributed it with LabVIEW!

FWIW I hope this day never comes. What I would love to see on the other hand is that if an OpenG VI was so awesome (e.g. covering a functionality gap) NI decided to include such functionality in a future version of LabVIEW (this is my personal opinion only).

I.e. OpenG influenced LabVIEW positively then that would be great, but I don't want to see them manage the entire OpenG organization!!

And it is available for everyone - simply download VIPM and away you go (Note: I appreciate that some companies cannot or do not wish to leverage such resources for internal reasons, and I have no issues with that).

The LVTN is a way for any organization to plug into LabVIEW and OpenG views certification as very important.

Anyways, I am just trying to understand your reasoning - are u able to go into details on why you would want the above?

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 License
  • In 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.

I'm taking recommendations for clean and dirty LV limericks.

Somewhere there is a video from last year and that list.

I doubt i'll be able to outdo that list so I'm counting on you guys to, if not give full limericks, then at least give me a few boiler plate ideas. PM me so we all don't see them ahead of time.

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?

Loading a parent class doesn't trigger automatic loading for the child classes unless:

• The parent class has source code dependencies on the child classes or,
• The parent and child classes are contained in the same lvlib.

Why are all the children being loaded when the opening the Signal class? That's the first place I would look to improve performance.

1. When a .lvclass is opened in the IDE
2. 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.

Also, if your "templates" are in fact vit files, you might consider changing them to reentrant vis. Jarrod comments on the benefits of reentrancy over templates on this thread.

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.

I'm not going to comment on any design aspects. I assume you're design is good and this is what it takes. So let's focus on load time.

1) Put all your VIs and classes into a .llb file. The .llb optimizes the contents of the file and significantly improves load speed when a block of VIs must load as one.

2) Try loading in a runtime engine and compare to the load time in a development environment. Are they significantly different (there will be some difference, but it should be a second or two, at most) If so, you're probably doing something in the dev environment that is causing the block diagrams and panels of all those VIs to load needlessly. There are various things that can cause this -- scripting tools running in the background, VIs that are saved broken and become good after they load because something else loaded their missing subVIs, etc.

3) If you have LV 2010, you can build packed libraries. DO NOT UNDERTAKE THIS WITHOUT READING DOCUMENTATION. The packed libraries can give you BLAZING FAST LOAD SPEEDS. But they are a power that comes with consequences. Notably, the classes in the packed library have a different qualified name than classes not in the packed library, so any caller VIs need to be written in terms of one or the other. The packed libraries are designed to be "I build this separate component, and then I go develop something that uses that built component", not "I build this monolith of source code and then I turn it into two different components." There are tools to make the latter approach work, but the former approach is what I'd recommend.

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!

Why are hundreds and hundreds of unused VIs being loaded? Does your class have that many member vis? If so, I would guess the problem isn't with LVOOP or SubPanels, but with your class design. It likely needs to be refactored and broken out into many individual classes rather than one gigantic class.

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!

You can find it here:

https://lumen.ni.com...t/content.xhtml

Cheers,

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

First, LabVIEW does not support multiple inheritance (thank God!)- you can have an ancestor tree for a given subclass, but multiple inheritance implies that a subclass inherits from more than one distinct superclass. Secondly, you can minimize the work done making a deep copy by wrapping the parent class (and subclass) data members in a cluster and then accessing that cluster in the unbundle/bundle nodes. Typedef that cluster and include it in your class (subclass) library. Then, if you add/remove data to the cluster everything updates and the copy is still valid because the bundel/unbundle operates on the cluster. You will need one specific method for each subclass that looks a lot like my screenshot above that unbundles the data from the direct parent of that class and copies it into a new instance of the child class.

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

I can't say this is the best procedure, but it's how I've solved the problem in the past. Create a child class with the attributes you want. The parent data in the child class will all be set to the default values. Then copy the parent data from the existing parent object into the new child object's parent data. I've attached an example using 2010.

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!

There are probably better design patterns for your implementation anyway

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:

This VI attempts to override a static VI in an ancestor class. An ancestor class has a VI by the same name that does not have a dynamic dispatch input terminal. Only dynamic member VIs can be overridden in child classes. To correct this, change the name of this VI so that it does not match any ancestor VI names or edit the ancestor to include a dynamic dispatch input terminal.

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

Anyone interested in discussing this topic?