cancel
Showing results for 
Search instead for 
Did you mean: 
Knowledge Base

Example Code

Top Contributors
Sort by:
Description Description-Separate-1 Overview Once installed, when you open a VI from a project window, the Diagram will open in the foreground instead of the Front Panel.   Description Most of the time, when I open a VI form a project, I want to modify the code more than modify the UI because most of the VIs are subVIs. Then that is a (tiny) waist of time to switch from the front panel to the diagram (almost) everytime. So I decided to create a project provider which "overrides" the action of opening a VI so that the diagram appears in the foreground instead of the front panel.   Requirements LabVIEW 2013 (or compatible).   Steps to Implement or Execute Code 1. Install the package using VIPM. or Download the .zip files, unzipped and read the readme files. 2. Restart LabVIEW.   Additional Information or References It is expected that the diagram appears in the foreground when opening an existing VI from a LabVIEW project It is expected that the front panel appears in the foreground when creating a new VI from a LabVIEW project It is not implemented so that it works when opening a VI from Windows Explorer (not doable from a project provider) It has been rapidely tested with LV13 and LV14 (32bits) on Windows 7 This piece of code is provide As Is. All comments/ideas are more than welcome !   **This document has been updated to meet the current required format for the NI Code Exchange.** Description-Separate-2
View full article
Python: Voltage - Continuous Input.py
View full article
Description Description-Separate-1 Overview These example files are to be used in conjunction with the LabVIEW Continuous Integration Tutorial (Jenkins/GitHub).   The tutorial uses these files to illustrate how to graphically diff the source code submission of a Pull request when using Git repositories. It also demonstrates using Jenkins to automate the submission and build process.   Description Using the LabVIEW Continuous Integration Tutorial, these files (which include LabVIEW VIs and scripts) are placed in separate repositories to automate Jenkins pipelines to: Build a LabVIEW Build Specification Perform Unit Tests Perform a graphical diff of a Pull Request submission on GitHub Hardware and Software Requirements LabVIEW Professional Development System 2018+ LabVIEW Unit Test Framework Toolkit UTF JUnit Report library (VI Package Manager) Python (Version 3.6.3 or later) For these examples to work, make sure Python is added to your System Path. Git Steps to Implement or Execute Code Place these files in the appropriate directories per the LabVIEW Continuous Integration Tutorial (Jenkins/GitHub).   Additional Information or References   Description-Separate-2
View full article
Description Description-Separate-1 Overview   This example shows how to use the deep learning API to perform numeric classification using the Python Keras library. The model is of sequential type and is compiled using the optimizer provided by Keras. Trained using the mnist dataset, this model recognizes and classifies numbers you draw on the front panel.   Description   This example compiles and trains the model defined in main.py. The model uses a mnist dataset of 28x28 size images provided by Keras and outputs the result by predicting the number drawn on the front panel.   Hardware and Software Requirements   LabVIEW 2018 64-bit and later Python 3.6 64-bit TensorFlow Python library. Keras Python library.   Steps to Implement or Execute Code   Make sure you have TensorFlow and Keras installed in your Python environment. Open mnist Keras.vi. Run the VI. After the model has been compiled and trained, the Status indicator changes to "Model_Predicting". Drag the mouse into the draw pane to draw a number and the model will output the prediction.   Additional Information or References   Keras Documentation. Front Panel:      Jinho Choi Staff Technical Support Engineer Description-Separate-2
View full article
Overview I've done a fair bit of work with XML and for a while it was frustratingly slow parsing large XML files no matter what method I tried. I know I'm not the only one, many have come across this issue and mostly we just learned to live with it. My users just had to wait 30+ seconds for their information to load.   Then I started to look deeper into it. LabXML / LibXML seemed to be much faster at the open stage and a little bit faster when using xpath expressions. Not enough to change everything over though. Then I realised all the CLF nodes were set to run in the UI thread. So I changed them all to run in 'any thread'. A few more tweaks later and it was running about 30 times faster than anything else.   Now here's the trade-off. It is a bit more tricky to use. Some of the other XML parsing methods do a fair bit of work to make them easy to use. I don't care about easy, I want FAST. Using the libXML functions gives you fine control over your XML operation. It isn't the simplest method, but it is fast.   If you want easy try EasyXML. If you want fast, try this. Description LabXML comes in two variants. One uses MSXML, one uses the LibXML toolkit compiled for Windows. All credit for this goes to the good people at xmlsoft.org and Thijs Bolhuis who made the LabXML LabVIEW wrappers. All I did was tweak the LabXML VIs and CLF calls. Attached is my version of the project library and the dlls needed to make it work. For help with how to use XML or XPATH you can Google it. For help with the specific libxml functions you can go to xmlsoft.org. There's also an example below to get you started.   Example I've taken the example from this thread here, where they discuss why XML parsing is so slow and did some benchmarking for how long it takes. I left the original VI intact except for covering the LabVIEW XML functions with a diagram disable structure and adding my libXML version over the top of it so you could switch between the two. The big example XML file (LabVIEW_Labs_RWWbig.xml) contains 40960 clusters and is a 24MB file (quite repetitive so it zips down nice and small). It takes the LabVIEW XML parser about 87 seconds to parse the 40960 clusters in it. It takes the libXML parser about 4 seconds to parse the 40960 clusters in it. (Win7 2core i5-2400)   More than 20 times faster in this example. I think it's worth it!   (v2.1 includes xmlParseDoc), xmlDocDumpFormatMemory and corrected xmlXPathFreeObject LibXML_FreeXPath.vi) LibXMLUpdate(2).zip contains additions and updated consistent naming conventions. - Thanks to GarryG VI Package manager file added. lXMLwrap64.dll.zip added thanks to EricH 2019-07-23 - Corrected incorrect return type for xmlXPathFreeObject() was int32, should have been void.
View full article
The Splash Screen Effect in LabVIEW code is being updated and will be available on the NI Tools Network soon.
View full article
Overview: A Routine to find a value without having to ramp up to find the desired value.   Description: This routine will quickly find a value that meets the requirements for a test condition, without ramping up through many values.   Hardware and Software Requirements LabVIEW 2017 Full Development System 2017 or compatible.   Steps to Implement or Execute Code Set values for Maximum Control Value, Minimum Control Value, Target, and Number of Passes. Inside of the Loop, output Test Value, then read the result.  Connect the result to the lower input of the Compare icon.   Additional Information or References The displays Iteration, Test Value, and Shifting Value are used for testing and debugging the routine.  
View full article
Overview  This program utilizes the WPF Writable Graph control to display two plots on the same graph with two vertical axes. Description  This program primarily illustrates creating and binding two plots to a WPF Graph in C#. The two plots are stored in a 2D array, which is used as the DataSource. This program also incorporates two vertical axes with independent scaling, bound to their respective plots using XAML. For more in-depth documentation, see the link below. Hardware and Software Requirements  Measurement Studio 2015 with Visual Studio 2013, 2015, or 2017 Steps to Implement or Execute Code Download and unzip the solution Open the solution in Visual Studio Run the project Additional Information or References How to: Plot and Chart with the Measurement Studio WPF Graph Control
View full article
Overview  This example demonstrates how to build a pattern in the Digital Pattern Editor for Source Synchronous Acquisition with a Digital Pattern Instrument.   Description By using the match opcode and a slightly faster Time Set, the Digital Pattern Instrument can be aligned with an external clock from the DUT. The first thing that must be done is flushing the compare pipeline. In this example the tset_search Time Set is 1/80 less then the normal timing period, this can be seen by looking at the SourceSyncAcq.digitiming sheet. Therefore, the pattern must repeat the first match 80 times to flush the buffer since there is an 80 cycle pipeline delay for the match opcode. Next the tset_search Time Set is used to sweep through the incoming clock to find the falling edge of the clock. This is done by calling jump_if(matched, FindFallingEdge), match and having the Clock pin set to L. This will cause the pattern to loop on this vector until the first falling edge of the clock signal is seen. After the falling edge is found the pattern sweeps through the clock signal to find the rising edge of the clock. The Time Set and Clock pin state is not changed for the next vector. However, jump_if(!matched, FindRisingEdge), match is used to loop on the vector until the first rising edge of the clock signal is seen. The pattern is now aligned with the input clock signal.    Next, the pattern flushes the compare pipeline before looking for DataRdy. Then jump_if(!matched, FindDataRdy), match is called to have the vector loop until the DataRdy pin goes high. The compare pipeline must be flushed to center the pattern on the incoming clock signal after the cycle that DataRdy asserts on is found. This is done by calling a repeat on the normal Time Set R times. Where R = ((Data Word Length*N)-82). After the pattern has been aligned and Data Rdy has been asserted, the data can be acquired using a flat pattern, SourceSyncAcq.digipat, or a capture waveform, SourceSyncAcq_wfms.digipat. Finally, a halt is called to end the pattern.    Hardware and Software Requirements PXIe-6570 (2x) PXIe Chassis (2x) VHDCI Cable (SHC68-C68-D4 or SH68-68-D1) NI-Digital Pattern Driver and Digital Pattern Editor 16.0 or newer LabVIEW 2014 SP1 (64 Bit) or newer   Steps to Implement or Execute Code 1. Install all of the above required software. 2. Download and unzip the attached SourceSyncAcq.zip folder.  3. Place one PXIe-6570 in each PXIe chassis and connect the two PXIe-6570s with the VHDCI cable. One PXIe-6570 will be used to acquire the data and the other PXIe-6570 will act as a source. The PXIe-6570s need to be in different chassis so they are running on different clocks. 4. Open the SourceSyncAcqSource DPE project in the SourceSim folder.  5. Open the OneSite.pinmap and match the instrument name with the name of the source PXIe-6570 in NI MAX. 6. Open the RunSource.VI in the SourceSim folder. 7. In the 6570 Resource Name control select the source PXIe-6570. 8. Select OneSite.pinmap for the Pin Map file, SourceSyncAcqSource.specs for the Specifications file, PinLevels.digilevels for the Levels file, SourceSyncAcqSource.digitiming for the Timings file, and SourceSyncAcqSource.digipat for the Pattern file. All of these files are located in the SourceSim folder. 9. Open the SourceSyncAcq DPE project and connect to the acquisition PXIe-6570. 10. Open the OneSite.pinmap and match the instrument name with the name of the acquisition PXIe-6570 in NI MAX.   11. Open the SourceSyncAcq pattern and burst the pattern. Then run the RunSource.VI. To compare the data using a capture waveform burst the SourceSyncAcq_wfms pattern.     Daniel Griffin Product Support Engineer: Digital Instruments/STS National Instruments
View full article
Overview Many applications need an autonomous surveillance which returns correspondent warnings if a value is not in the specified range. As there may be thousands of values, only relevant deviations should be shown, so warnings are best practice. This is performed in the following example.   -1 = Freeze, 0 = Normal, 1 = Overheat   Description This example performs automatic checks every e.g. 3 seconds. The raw values (which are TDM files) are located in a folder called "\Data". Those TDM files are continously written to by external laboratory appertures (which could be hundreds of machines). The script automatically loads all TDM files from the folder into the data portal, checks its channel values and returns warnings if applicable. The current time is also displayed for verification.   Hardware and Software Requirements DIAdem Base 2012 SP2 (or compatible)   Steps to Implement or Execute Code 1. Download and unzip Surveillance Warnings - DIA2012SP2.zip 2. Run Dialog Caller.VBS 3. Let the warnings wash over you   Additional Information or References ** The window does not accept any user inputs. Bug fixes from the community are highly appreciated. Also, adding comments in the code may be of advantage. **
View full article
I wanted to see if it was possible to have an implementation without classes or references.    The ideal type would be a cluster with two elements, a value, and a singly linked list but if you try and do that the IDE throws an error about not being able to have recursive data types. Instead, we can just use a variant for the "next" element And here's how you can link them. You can see from the indicator that all the data is in there:   We can also implement other functions like print, insert, append to other side, reverse list, sort etc: Here's what sort looks like:     Things that would be nice to have for future work: Recursive data structures Type Parameters and Parametrized Generic Types (to make "value" dynamic)    
View full article
Overview A real-time controllable simulator was created for the purpose of test-flying the aircraft and for testing various feedback control inputs. The following figure illustrates the graphical user interface (GUI) for the simulator.   Figure 1: graphical user interface for simulator     GUI display features 3-D render of aircraft Attitude gimbal display Ground track display Airspeed indicator Control surface input display Time plots of any state space variables or outputs Control inputs Elevator Aileron Rudder Throttle Control input options Joystick (Logitech Extreme 3D Pro) user-specified step function (no joystick needed) user-specified doublet function (no joystick needed) user-specified ramp function (no joystick needed) Simulator configuration parameters Specify aircraft Specify aileron proportional feedback gain Specify elevator proportional feedback gain Specify rudder proportional feedback gain   Joystick Control The simulation can be controlled in real-time through the use of a joystick.  While it's possible that any generic joystick might work with this code, I am only able to guarantee compatibility with the Logitech Extreme 3D Pro joystick.  The following figure illustrates the mapping of joystick axes to aircraft control surface input.             Where: Y = elevator control X = aileron control RZ = rudder control Throttle = motor power   Figure 2: Joystick configuration for simulator control     Theory of Operation The following is a summary of the process for simulating the aircraft response in real-time: FlatEarth v9.53 generates linearized state space for aircraft dynamics MATLAB script exports state space to text config files Labview 2015 reads config files on startup Labview 2015 Control Design and Simulation Module utilized for performing state space calculations Timing logic used to enforce real-time operation   The state space obtained from FlatEarth is illustrated in Figure 3:     Figure 3: FlatEarth state space output to Labview       The state space variables, inputs, and outputs are defined in Table 4.   Figure 4: State Space Variable Definitions     State Space Feedback Control   It is desirable to be able to apply proportional feedback control gains to the aileron, rudder, and elevator for aircraft testing.  The figure below illustrates how the open-loop state space is wrapped by a proportional controller.       Figure 5: proportional feedback controller applied to state space [10]     With the addition of the proportional controller, the state space equation can then be written as: [10]       User-Guide Installation You will need to install the following elements before being able to run this code: LabVIEW 2015 Development system LabVIEW Control Design and Simulation Module Simflight.zip (at bottom of this page)   Please note that LabVIEW 2015 and the Control Design and Simulation Module can be downloaded/installed for free for a 7-day trial.  You can extend this to a 45 day trial by creating a free National Instruments account.  You can extend this to a 6 month trial by verifying your status as a student to National Instruments.     Create & SIM a new Aircraft Step 1: Create FlatEarth constants input file This is where you specify all the properties of your aircraft.  FlatEarth will use these inputs to generate the state space that LabVIEW utilizes to run the simulation.  Simflight comes packaged with 3 example constant input files: "Basic_Constants_MPX5.m", "Basic_Constants_PA_28_161_Warrior.m", "Basic_Constants_Albatross.m"   Step 2: Run FlatEarth to Simflight script Locate the file: "FlatEarth_to_Simflight.m".  This script wraps and runs the FlatEarth module to generate a state space.  The resulting state space is exported into a set of text files that LabVIEW will parse at run-time.  You must edit this script to properly identify and run the constants input file that you just created.     Step 3: (Optional) Modify SIM_Controls.INI If the FlatEarth code ran successfully, you will have created a new folder in the config_files folder.  It should look like this: The newly created folder contains all of the text files (state space variables) required for the LabVIEW simulation.  One file that you may wish to modify is the SIM_Controls.INI file.  This files looks like this: These numbers affect the range of motion of the joystick in the simulator.  More specifically, if the max rudder is set at 25 degrees, then full rotation of the joystick yaw-axis will yield 25 degrees rudder deflection in the simulation.  If you find that you want a more/less sensitive joystick, you can increase/decrease this number as you please.  Simply edit the file and save.  LabVIEW loads this file at run-time.   The max_speed input in slightly different.  This simply affects the maximum number shown on the speedometer on the GUI.   Step 4: Run LabVIEW Simflight program Locate and run the file: "Simflight.vi".  Again, for this step, you will need both LabVIEW 2015 and the Control Design and Simulation Module installed.  (Click the run-arrow in the menu-bar of the VI to start the program.)   Step 5: Specify SIM Inputs When the program is started, the user is promted for the following information: aircraft selection.  Use the drop-down menu on this control to navigate the possible options.  You should see your aircraft here if you ran the FlatEarth_to_Simflight.m script properly proportional feedback gains Control Input Source.  (See below for more information about the various options here)   Step 5.1: joystick (autodetect) control option This option will attempt to autodetect a Logitech Extreme 3D Pro joystick plugged into the computer.  If successful, you'll be able to control the simulation in real-time with the joystick.   Step 5.2: joystick (select port) control option If the auto-detect option isn't working, you can use this option to manually specify the port that your joystick is plugged into.  This option might be useful for attempting to use the simulator with a different type of joystick.  (Again, I can only guarantee compatibility with the Logitech Extreme 3D Pro joystick.)  Use device manager to determine what port your joystick is plugged into. Step 5.3: step function control option This option will apply a step-function to the state space.  Note the following: duration of step = how long the step input persists rudder deflection = degrees of deflection from trim during step aileron deflection = degrees of aileron from trim during step elevator deflection = degrees of elevator from trim during step motor (BHP) from trip = throttle input from trim during step You do not need a joystick for this method     Step 5.4: doublet function control option This option will apply a doublet-function to the state space.  Note the following: duration of up step = how long the positive step input persists duration of down step = how long the negative step input persists rudder deflection = degrees of deflection from trim during step aileron deflection = degrees of aileron from trim during step elevator deflection = degrees of elevator from trim during step motor (BHP) from trip = throttle input from trim during step You do not need a joystick for this method Step 5.5: ramp function control option This option will apply a step-function to the state space.  Note the following: duration of ramp = how long the ramp input persists rudder ramp rate= degrees/s of deflection from trim during the ramp aileron ramp rate= degrees/s of aileron from trim during the ramp elevator ramp rate= degrees/s of elevator from trim during the ramp motor ramp rate = BHP/s of throttle input from trim during the ramp You do not need a joystick for this method   Data Analysis The results of the simulation are automatically saved to a MATLAB data file (.mat) at the conclusion of the simulation.  These data files can be found in the datalogs folder.  It should look something like this after having run a few sims: The filename is simply a timestamp of when the file was created at the end of the simulation.  These files can be loaded directly into the MATLAB workspace using the "load" command.  (These are simply Level-5 .mat variable files.)   GUI Interface Description The following images describe the GUI interface and the meaning/usefulness of various elements.   Simulation Validation Simulation Validation - Longitudinal Direction   The longitudinal model was tested by injecting a doublet input on the elevator.  More specifically, the elevator was deflected -1 degrees from trim for 1 second, then deflected +1 degrees from trim for 1 second, and then brought back to trim.  The following figures show the FlatEarth output and Labview simulation output.     Figure 6: FlatEarth - pitch rate response to doublet elevator input   Figure 7: Labview simulation – pitch rate response to doublet elevator input   We see that the nonlinear FlatEarth, linear FlatEarth and Labview simulation results are all in acceptable agreement for pitch rate response to elevator commands.  As such, the following can be concluded:   Linearized model acceptable for near-trim flight Labview simulation model acceptably operating at real-time We also see that with an elevator deflection, the pitch rate dampens out and approaches a steady state value of zero.  This corresponds to a dynamically stable aircraft in the longitudinal direction.  This observation is in agreement with the flight qualities analysis.   Simulation Validation - Lateral Direction The lateral model was tested by injecting a doublet input on the aileron control.  More specifically, the aileron was deflected +1 degrees from trim for 1 second, then deflected -1 degrees from trim for 1 second, and then brought back to trim.  The following figures show the FlatEarth output and Labview simulation output.     Figure 8: FlatEarth - roll and yaw angle response to doublet aileron input     Figure 9: Labview simulation – roll and yaw angle response to doublet aileron input We see that the nonlinear FlatEarth, linear FlatEarth and Labview simulation results are all in acceptable agreement for yaw angle and roll angle for approximately 7 seconds.  After this time, the linearized solution begins to diverge from the nonlinear solution.  This is to be expected as the linearized solution is only valid near trim conditions.  At t=7 seconds, the aircraft is in a deep spiral dive - far from steady-level flight.  We can conclude the following from these results: Linearized model acceptable for near-trim flight Labview simulation model acceptably operating at real-time   We also see from these figures that the aircraft is unstable in the lateral direction.  As the aircraft rolls and yaws in one direction, the angle grows over time.  This is in agreement with the flight quality analysis which found the aircraft to be unstable in the spiral mode.   Tutorial Video     Code Version Control: The most recent code version can always be found at my GITHUB page: GITHUB link   Acknowledgements 1) Aircraft indicators taken from project here 2) Aircraft gimbal taken from project here 3) FlatEarth written by Professor Andriasani    
View full article
Overview This software (written by student and faculty end users at Cal State Fullerton) allows automation of the basic functions of the InstruTech Hornet 402 Vacuum Gauge.   Description This document contains two example programs and dependencies.   The file Hornet_ASCII_communications_V4.vi is a ready to use controls VI using the ASCII communications protocol. This allows the user to view the vacuum pressure, using either the ion gauge or either of two convection gauges, over a user-specified time range (1 minute to 1 week). The "Additional commands" tab contains every communication command from the user manual, which can be used to further control the gauge. Note that any responses returned by these commands are displayed but not otherwise handled by the VI.    The file InstruTech 402 Comm example.vi is a minimal example of communication with the instrument for developers to incorporate into their own software. Figure 1: Hornet_ASCII_communications_V4.vi.   Figure 2: InstruTech 402 Comm example.vi.   Hardware and Software Requirements Hardware InstruTech Hornet 402 Vacuum Gauge (ion and convection gauges operating in tandem) USB to serial cable. PC. Software Tested on Labview 2016 with a Windows 10 PC. Might work on other systems.   Steps to Implement or Execute Code Check that the requirements below are satisfied. Download the .zip file below, unzip.  Open the Hornet_ASCII_communications_V4.vi and open the "IO Controls" tab. Check that the address in the program matches the address programmed in the menus of the 402 controller. In the same tab on the VI, choose the correct COM port from the list under the VISA resources name. If you get this wrong, the VI will return an error. Click on the LabVIEW "run" button. Let us know if that doesn't work so we can improve these directions.   Additional Information or References InstruTech IGM402 User Manual: http://www.instrutechinc.com/site/files/1082/124783/426747/756398/000861_Manual_IGM402_Hornet_w_dual_V115.pdf     Authors: Adrian Avila-Alvarez, Juan Rocha, Leigh Hargreaves, Josh Smith
View full article
Save LabView data in .mat file with MatFileVI  
View full article