Jump to content


  • Posts

  • Joined

  • Days Won


Everything posted by lvb

  1. 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...
  2. FYI, this will break the class "Create Accessor" dialog. Right-click on a class -> New -> "VI for Data Member Access..."
  3. 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...
  4. 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.
  5. 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?
  6. 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.
  7. 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
  8. 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.
  9. 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?
  10. 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?
  11. 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?
  12. 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!
  13. 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?
  14. 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!
  15. 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
  16. 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
  17. 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?
  18. 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!
  19. 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!
  20. 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
  21. After browsing some more, I stumbled on this thread on the other side: NI Background Services
  22. After installing a bit of NI software and going through a few upgrades, I feel that there is too much un-necessary NI software continuously running in the background and at startup. This thread is to discuss what software and services can be set to launch in manual mode when necessary along with what is absolutely required. The ideal situation would be to create a batch file that can launch and kill the necessary applications and services. For instance, a batch file for using MAX, LabVIEW, TestStand, and so on. I have attached my current task list and startup service list for reference. A few things to note: 1. There are 101,632KB of programs running after I start my PC! 2. There are 14 services that are launching during startup (automatic mode) 3. The following services are under the nipalsm.exe process: NI-488.2 Enumeration Service [ni488enumsvc] - 3,312KB NI Device Loader [nidevldu] - 15,772KB NI-Motion Device Manager [nimcdldu] - 6,208KB NI PXI Resource Manager [nipxirmu] - 6,012KB 4. I am using sysinternals process explorer (http://download.sysinternals.com/Files/ProcessExplorer.zip) Let's discuss how to reduce the footprint of the NI software and how we can selectively launch the required applications when we want to use NI products. Thanks!
  23. QUOTE The use case is a simple example that I created, not a real-world implementation. The main design question is how to obtain an accurate sub-msec timing in a sequencer where events may be scheduled at varying times without an extremely resource-intensive polling loop. QUOTE The other question is whether a stopwatch-like app should use relative time or absolute time. I would vote for absolute time because your timing code may have bugs (which you will eventually fix, of course) whereas the OS time is generally correct already. As far as the relative vs absolute time, I was attempting to implement a "pause" condition which meant the alarms could be delayed. This would mean the alarm times could be delayed while the sequencer is active.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.