Community: UI Interest Group: LabVIEW UI Tips and Tricks - PartI:
'via Blog this'
Tuesday, 4 December 2012
Thursday, 29 November 2012
Monday, 19 November 2012
Community: LabVIEW Development Best Practices: When Should You Use LabVIEW Classes?
Community: LabVIEW Development Best Practices: When Should You Use LabVIEW Classes?:
'via Blog this'
Now, you might be thinking to yourself, "Can't I just use a cluster?" The answer is generally 'yes.' In fact, if you've recently begun developing an application that relies upon a large, complex cluster that you're passing around your application, it may be an excellent candidate for replacing with a class. This is especially true if you're passing around an array of clusters that are used to represent items that your program needs to be able to communicate and interact with. Making the switch from a cluster to a class offers several benefits - I want to highlight the following (although there are many more):
- Inheritance - so far, I've described explained that you can define a class of objects and give it properties and methods. What makes this even more powerful is the ability to define children of that class, which have the same properties and methods, as well as some of their own. They may also want to override the methods or properties of their parent class. In my list of examples, I mentioned 'vehicles.' As you can imagine, there are many different types of vehicles, some of which have very unique properties and things that they can do. If you consider 'pickup truck,' as an example, one of it's properties might be 'bed size,' which wouldn't make any sense when applied to a car or a motorcycle.
- Dynamic dispatching - If we have an array of similar objects, they likely share methods and properties. In LabVIEW, we create wrappers using VIs to access and modify these values. If we want the wrapper VI for a specific child class to do something different, we can create a VI to override the parent VI automatically. LabVIEW will automatically run the version of the VI that is appropriate for the current class. To put it simply, LabVIEW dynamically runs the VI based upon the class of the object supplied to it - this assumes that the object is a child of the generic class.
As a software engineer, it's important to be able to recognize the potential benefits and when the use of classes may make more sense. LabVIEW is almost always used to interface with hardware, so the I/O in your application may be the perfect place to start. Consider these examples:
- Hardware Abstraction Layers - This white paper on hardware abstraction layers illustrates some excellent examples of the benefits of classes and how they can be used to mitigate the risk of hardware obsolescence. Classes have been defined for certain subsets of functionality (ie: a generic Scope). When a specific instrument is connected or added, it inherits the properties and methods of the parent class, but may add additional functionality (ie: an Agilent Scope could be replaced with an NI Scope, or visa versa).
- Devices Under Test - Consider the task of testing a large number of very similar, yet slightly different devices such as cell phones. One production line may be responsible for testing a variety of different types of phones, but they almost certainly all have similar properties. The code can be written using a generic cell-phone class, but the method to execute a specific operation may require slightly different commands be sent to the test executive. This can easily be added later on without major modifications to the code through the creation of a child-class.
'via Blog this'
Saturday, 17 November 2012
Interactive DaqMx simulation interface ... (Popup panels for simulated hardware) ... Or better, DaqMx Simulation API for process simulation ... - NI Discussion Forums
Interactive DaqMx simulation interface ... (Popup panels for simulated hardware) ... Or better, DaqMx Simulation API for process simulation ... - NI Discussion Forums:
'via Blog this'
Hello,
How often you have build Labview applications using simulated DaqMx boards ...
And how often you were limited by the default behaviour of simulated boards ... ( Sinewave for analogic inputs, Counter square signal for digital inputs ... )
It would be nice to integrate in DaqMx simulated boards, the abilty to modify the default behaviour of simulated inputs ... thru dedicated popups
It would be nice, for each task linked to a simulated daqMx board, to launch a popup window ...
- For digital input, give the abilty to modify for each configured channel , the current binary value.
- For analog input, give the ability to choose between a fixed value, a sine wave, a square signal ... white noise ...
- For digital output, give the ability to view the current setted values
- For analog output, give the ability to view the current simulated output value on a waveform chart ...
A more powerfull tool could also integrate a simulated channels switching mechanism ... A simulated output could be linked to a simulated input
This feature could be a good way to create an application which could simulate a complete process ... this application could be used to validate a complete system
(such a kind of SIL architecture)
Other idea .... A complete daqMx simulation API ...
- Creation of an API which could instanciate a simulated daqMx board (Wich could be seen via MAX)
- Takes place of the actual limited daqMx simulated board
- This device could then be accessed by other application thru daqMx
- This API could have access to all channels of this simulated device.
- This API could force, programmatically, the value of the simulated input channels according to a realistic process model
'via Blog this'
Subscribe to:
Posts (Atom)