For video cards, we recommend you use an external one. This distinction is important because the greatest overhead in RTXI is related to data visualization in the oscilloscope. For newer graphics cards, you may need to manually install the Linux drivers, usually available on the manufacturer's website.
Some systems may also include BIOS level or hardware interrupts that are not captured by Xenomai or advanced power management features. Sometimes these can be disabled by the user in the BIOS. The real-time Linux kernel has extremely low latencies and little software overhead. RTXI is also designed to minimize the number of dynamically loaded modules and keep overhead low. While the processor speed allows RTXI to complete more computations within a single real-time cycle, the amount of RAM and the amount of video memory have a significant impact on the stability and speed of the system.
Users should also consider high speed hard drives, large cache sizes, and high speed bus interfaces. If you are purchasing an off-the-shelf desktop computer system and plan to add a DAQ card, be sure that your power supply is powerful enough to handle the extra load. At least a W power supply is recommended. For closed loop experiments using RTXI, your computer must be equipped with an analog-to-digital converter ADC to acquire data and a digital-to-analog converter DAC to generate signals.
Of course, external hardware such as an oscilloscope or function waveform generator can be used in conjunction with RTXI. Furthermore, the USB interface can only achieve a maximum sampling rate of approximately 1 kHz, insufficient for some closed-loop real-time applications. If you want to use additional cards, you will need to edit the configuration file.
You will need to exit and restart RTXI for the new configuration to take effect. Settings files that you have already created should still work when you change rtxi. You will have to rebuild those settings files or edit them as above using your choice of text editor.
RTXI automatically detects the manufacturer and board names of available DAQ cards and the number and type of input and output channels. Xenomai provides several command line utilities for testing your real-time performance.
There are both user and kernel space versions of the available tools. When using these tests, keep in mind that they are most informative when the system is under processing loads, ideally loads similar to those added when you run RTXI. The most important test is the latency test. It measures the latency, or the difference in time between the expected switch time and the time a task is actually called by the scheduler. It is essentially a measure of the delay when a task is supposed to run and when it actually runs.
For a system to run in real-time, the latency values must be below the frequency at which a task must be run. For example, to run something in real-time at 20 kHz, the latencies must remain below 50 us. Failure to do so constitutes an overrun. The latency test will perform latency calculations repeatedly default 10 kHz until stopped.
The test prints one line every second and gives you the minimum, average, and maximum latencies for that period as well the minimum and maximum overall latencies that occurred over the entire test. Open up some other programs, copy some files from one location to another, and load the network connection to see how it affects the latency.
The system's real-time performance is limited by the maximum latency the 'lat worst' column. You should not any overruns, meaning that the latency completely exceeds the nominal period. Negative time values in the latency test is due to the fact that Xenomai performs a calibration at startup that tries to minimize the jitter in the real-time task and anticipates the call.
You can correct this behavior by running as root :. There are many factors that affect your real-time performance, which do not necessarily depend on your absolute processor speed. For simple applications such as a single ion channel, similar results can be obtained on MHz or 2 GHz processors. The limiting factors actually involve the design of the motherboard and chipset, the cost of reading and writing to a DAQ card, and the cost of accessing the hard disk when streaming data.
Multi-processor systems or multicore processors also operate differently than single processors. RTXI allows the system to distribute processes among individual cores and does not assign any operations to particular cores.
Generally, you'll get the best RT performance from your system if you disconnect from your network, especially if is a wireless network, and to plot only the minimum number of signals in the Oscilloscope module as possible.
If you periodically see an overrun perhaps every 64 seconds that results in a maximum latency of several hundred microseconds, you may have an SMI System Maintenance Interrupt issue.
This feature can be found on certain chipsets e. Intel Disabling SMI can cause some computers to overheat and may damage those computers. If you have disabled all of these in the kernel already, check your BIOS and see if you can disable them there. Although RTXI is dependent on Linux, it is a complete desktop application and configuration of system settings and interaction with most features are available through a graphical user interface.
The File Menu is used to save and load settings files that capture the entire working environment. This includes settings configured in the System Control Panel, such as channel gains, parameters set within modules, and connections between modules. Reloading a settings files will also restore the window sizes and positions at the time the file was created.
Recently used settings files are also available from this menu. The Modules Menu is used to load user modules. The Control Panel is used to configure channels and set the nominal system period or sampling rate. The Oscilloscope is the digital oscilloscope that can be used to plot any signal in real-time. The Connector is used to specify connections between modules and the DAQ card. There is also a Preferences panel for specifying commonly used directories, etc.
You can view the version number of your RTXI installation and the version of Qt used to build the user interface. Also included is a link to our documentation website and a link to our GitHub repository where you can report any issues you have with your system. All settings edited in each of these modules can be saved and reloaded via workspaces. The System Control Panel allows you to set important parameters on all the input and output channels of your DAQ card and set the nominal real-time period of your system.
To keep the number of RT events to a minimum, all changes made in the Control Panel are not set until the Apply button is pressed. You can use either the Frequency or Period entry boxes to set the real-time period. After you enter the value, hit Apply to set your changes.
The Channel submenu lists all avaiable analog input and output channels for the specified DAQ device. Picking a particular channel will allow you to activate the channel and also set the parameters of that channel via the Range , Scale , and Offset menus below. To activate a channel i. NOTE: If you do not hit the Apply button before changing channels, all changes made , such as the range, activation state, etc. The Range , Scale , and Offset submenus set the acquisition range and the reference mode.
You must set the correct options for each channel you are using to acquire and output the correct signal values. Remember to hit Apply to set your changes. Each signal may have a different vertical scale and line style and a legend is automatically generated in the Oscilloscope window.
Select signals to plot from the dropdown menu. You can plot any input or output from a loaded module or active channel on your DAQ. Be sure to check whether you have to set additional settings in the System Control panel to compensate from gains from any additional instrumentation. RTXI will automatically detect how many input and output channels your card has.
Signals from other modules will be identified by the module name and you can choose from any inputs, outputs, parameters, or states that are defined in those modules. Use the Scale and Offset options to modify the signals being plotted. To actually plot the signal, you must depress the Active toggle button and hit Apply.
Any modifications you make to the scaling, offset, or line style of the signal are not active until you hit Apply again.
Note that plotting too many signals in real-time may affect your system performance and cause your GUI to freeze during program execution. Use the RT Performance module to watch the load on your system while the Oscilloscope is running.
Use the dropdown menu to set the time scale for the x-axis. Each "div" refers to the demarcations on the plot window.
You can also set the refresh rate, or the number of times the plot window is refreshed per second, and you can set a downsampling rate for plotting. Use the Edge option to set a trigger to freeze the oscilloscope when certain criteria are met by a specified channel. The Channel can be set to any active signal that is currently plotted on the oscilloscope. Threshold sets the threshold for the trigger channel you specified, and Window sets the amount of time that lapses before the trigger is reset again.
The trigger threshold is indicated on the oscilloscope by a horizontal yellow dashed line. To start the trigger, set everything in the menu and then hit the Apply button.
To stop, select the Off radio button and hit Apply again. The Block menu is a list of your DAQ card s and any loaded user modules. Selecting a block device then populates the Type and Channel menus. Navigate the menus until you specify the channel you want to record. Then, hit Add to add the channel to the Currently Recording block.
To remove a channel from the list, double-click its name in the list and then press the Remove button. Before you can start recording, you must select a file by clicking the Choose File button. Navigate to the directory where you want to save you file. From the menu, you can either create a new HDF file select an existing one. If you choose the latter, you can either append new data to the file, preserving any existing data, or you can simply overwite it, erasing any existing data and only saving new trials.
Click Start Recording to begin recording and Stop Recording to stop recording. For each module connected to the Data Recorder, it also grabs all the parameter values and saves them as metadata. In addition, it logs when any of these parameter values change so that you have a complete record of your experiment. To check the actual output of the DAQ card, you will need to make a connection from that output to another input channel.
Each time you start and stop the data recorder counts as one 'trial'. By default, the Data Recorder displays the current trial number, the size of your data file, and the length of time from your last trial. More information on what that means is provided below. The Connector module allows you to create data streams between modules or between modules and the DAQ card. Note that the module does not check whether the channels are enabled via the Control Panel.
To connect one module from the other, select the desired Source and Destination channel. Then, click Connect. Now, every real-time period, the value of the Source channel is read in as input for the Destination channel. All active connections are listed in the Connections box. To remove an existing connection, double-click on its entry in the list and again click the Connect button.
For hard real-time performance, all operations must complete within the nominal system period. This module continuously keeps track of the time needed to complete these tasks, as well as the actual real-time period. In addition, the module reports the worst case total computation time and the worst case time step for however long the module was openor the statistics were last reset. The peak computation time measured over the time the RT Benchmarks module was running or was last reset.
The timestamp of the current RT period minus the timestamp from the last period. Basically, a measure of how long the previous period lasted. Ideally, this number is very close to the nominal RT period set in the Control Panel. The standard deviation of all the real-time periods measured over the time since the RT Benchmarks module was opened or last reset. Click the big, green button to the right and head to our Modules page. There, you'll find all the available user modules and instructions for how to download and install them.
RTXI comes with a set of core system modules but also enables users to install custom modules. This allows RTXI to have minimal overhead and user modules are loaded only as needed. This architecture also allows multiple instantiations of user modules so that elements such as filters and event detectors can be reused on a variety of signals. User modules must be recompiled if any changes are made to their sources after installation. This is an explanation for the code found in the plugin template module and a brief introduction to the DefaultGUI framework it abstracts.
The plugin template contains starter code for building new RTXI modules, though you can fork any other module , too. Below are the contents of plugin-template. Click on a code block to display an explanation of how its code works. If anything is unclear, let us know. DefaultGUI is on its own a mechanism by which users can create their own plugins. PluginTemplate simply obscures some of the more arcane functions and provides a more simplified programming experience. Signals and slots are how different QObjects communicate with one another.
One QObject sends a signal that is received by another QObject 's slot. The execute function is used to run code within the real-time loop. In other words, whatever get's put in here will be run in real-time. Whatever is run here should be as time and memory-efficient as possible.
By default, DefaultGUI creates widget display that shows all user-designated parameter and state variables. For an example of what this looks like, view the UI for the neuron module.
To do things like add buttons or extra windows, the customizeGUI function is needed. The update function is used to inject custom code around events triggered within the UI.
Definitions of what those states are are found in the source file. The initParameters function can also be used to initialize parameters. It is called within the module constructor, which is defined in the source files, too. They are used to connect some state change in a widget, like pushing a button, to some function. It's included here so that the module being created can reference the main window as it's parent.
That way, the modules will be displayed within the main window. In the base code, PluginTemplate doesn't write to output, but you can change that if you'd like.
Just remember to avoid writes within the execute function, or you'll crash RTXI. In other words, object names can be overloaded. Because this is a module, RTXI needs to load the dynamically-allocated module in memory.
Therefore, we use extern "C". Each is separately instantiated within vars[]. Note that the strings are of type std::string. Qt has its own string implementation, called QString , so take care to not confuse ordinary C strings with them. It is an unsigned long int used within RTXI for input and output processing.
Additional information about the type parameter can be added by using the operator. Note that here represents a bitwise OR operator. What this additional information does is apply an RTXI-specific data type to a variable within vars[]. The GUI is made by iterating through all the elements of vars[] and appending a widget to the GUI window for each one.
DefaultGUIModel 's constructor takes three arguments:. The functions called within the constructor are defined later.
The initParameters function is an optional function you can use to initialize variables. All rights reserved. Important Information Warranty The media on which you receive National Instruments software are warranted not to fail to execute programming instructions, due to defects in materials and workmanship, for a period of 90 days from date of shipment, as evidenced by receipts or other documentation.
National Instruments will, at its option, repair or replace software media that do not execute programming instructions if National Instruments receives notice of such defects during the warranty period.
National Instruments does not warrant that the operation of the software shall be uninterrupted or error free. A Return Material Authorization RMA number must be obtained from the factory and clearly marked on the outside of the package before any equipment will be accepted for warranty work.
National Instruments will pay the shipping costs of returning to the owner parts which are covered by warranty. National Instruments believes that the information in this document is accurate. The document has been carefully reviewed for technical accuracy. In the event that technical or typographical errors exist, National Instruments reserves the right to make changes to subsequent editions of this document without prior notice to holders of this edition. The reader should consult National Instruments if errors are suspected.
In no event shall National Instruments be liable for any damages arising out of or related to this document or the information contained in it. This limitation of the liability of National Instruments will apply regardless of the form of action, whether in contract or tort, including negligence.
Any action against National Instruments must be brought within one year after the cause of action accrues. National Instruments shall not be liable for any delay in performance due to causes beyond its reasonable control. Copyright Under the copyright laws, this publication may not be reproduced or transmitted in any form, electronic or mechanical, including photocopying, recording, storing in an information retrieval system, or translating, in whole or in part, without the prior written consent of National Instruments Corporation.
National Instruments respects the intellectual property of others, and we ask our users to do the same. NI software is protected by copyright and other intellectual property laws. Where NI software may be used to reproduce software or other materials belonging to others, you may use NI software only to reproduce materials that you may reproduce in accordance with the terms of any applicable license or other legal restriction. Refer to the Terms of Use section on ni.
The mark LabWindows is used under a license from Microsoft Corporation. Windows is a registered trademark of Microsoft Corporation in the United States and other countries. Other product and company names mentioned herein are trademarks or trade names of their respective companies. Members of the National Instruments Alliance Partner Program are business entities independent from National Instruments and have no agency, partnership, or joint-venture relationship with National Instruments.
Contents About This Manual Conventions Contents Read Trigger Time Stamp This manual describes the fundamentals of developing applications with NI-Sync. Conventions The following conventions appear in this manual: » The » symbol leads you through nested menu items and dialog box options to a final action. The sequence Options»Settings»General directs you to pull down the Options menu, select the Settings item, and select General from the last dialog box.
This icon denotes a note, which alerts you to important information. This icon denotes a caution, which advises you of precautions to take to avoid injury, data loss, or a system crash. Bold text also denotes parameter names. Italic text also denotes text that is a placeholder for a word or value that you must supply. This font is also used for the proper names of disk drives, paths, directories, programs, subprograms, subroutines, device names, functions, operations, variables, filenames, and extensions.
Introduction, Installation, 1 and Configuration This chapter provides an overview of the NI-Sync driver software and explains how to install and configure NI-Sync for use with National Instruments timing modules. You can use NI-Sync to configure the timing and synchronization of your system.
This can include signal-based synchronization such as sharing triggers and clocks to be used directly. Use NI-Sync in conjunction with other measurement software, such as NI-DAQmx, for advanced timing, high channel count, distributed or multiple-instrument applications. Also, refer to the appropriate hardware-specific chapter in this manual for specific examples of using NI-Sync with your application. If you are not using National Instruments application software, refer to Table Table Log in to the development computer as an administrator or as a user with administrative privileges.
Insert the NI-Sync installation media. NI-Sync User Manual ni. Chapter 1 Introduction, Installation, and Configuration 3. Run the Setup. Several examples are included to give you a starting point in using the NI timing and synchronization modules.
Additional examples for using NI timing modules with other devices are online at ni. Note Be sure to install the NI-Sync software before installing your device hardware. NI-Sync uses PXI configuration information to enable features such as chassis identification, slot identification, and trigger terminal reservation.
Refer to your PXI hardware user manual for more information. From this location, you can launch test panels, perform self tests, and view properties of your devices. Refer to Figure for an example of the type of device information available in MAX.
Refer to Chapter 2, Building and Programming Applications, for detailed information about device initialization. Figure This DLL should be linked using the appropriate import library for your application development environment. The following sections provide guidelines for creating applications that use the NI-Sync driver software. Note If you are not using one of the tools listed, refer to your development tool reference manual for details on creating applications that call C DLLs.
Select the VIs you want to use and drop them on the block diagram to build your application. Open an existing or new project file. Use the function panel to navigate the function hierarchy and generate function calls with the proper syntax and variable values. The examples are organized by measurement hardware. Functions and VIs that do not fall into the programming flow categories are considered Advanced or Utility functions that perform various tasks such as resetting timing devices and other functions.
Chapter 2 Building and Programming Applications Figure shows the basic programming flow of typical time-based NI-Sync applications. Functions and VIs that do not fall into the programming flow categories are considered Advanced or Utility functions. These functions perform various tasks such as resetting devices, returning the revision number of the NI-Sync instrument driver and instrument firmware, and other functions.
Chapter 2 Building and Programming Applications Initialize For any application you write, you must first open a session to establish communication with the NI timing and synchronization device using the Initialize VI or function.
The Initialize VI and function create a new instrument session. Any session returned from Initialize may be used in multiple program threads.
Configure Hardware Use Configuration VIs, LabVIEW property nodes, or functions to adjust settings of the timing and synchronization features of the timing module, including ADC input threshold voltage levels, DDS frequency, synchronization clock sources, specific time reference properties, and other settings and features.
To access these attributes, complete the following steps: 1. Open a VI. Make sure you are viewing the block diagram. Chapter 2 Building and Programming Applications 3. Left-click the property node and select the attribute you want to use.
To configure additional attributes, resize the property node. These functions correspond to a particular data type. Connect Terminals You can route signals between terminals using the Connect Terminals functions.
Connecting terminals forms the core of typical NI-Sync applications. Source and destination terminals can be connected using a variety of mechanisms. NI-Sync considers three types of terminals—clock terminals, trigger terminals, and software trigger terminals. Clock terminal connections are used to route clock signals between the backplane and front panel of the module. Refer to your hardware user manual for a complete discussion of clock terminals.
The following VI and function deal with clock terminal connections. Chapter 2 Building and Programming Applications Trigger Terminals Trigger terminals include terminals associated with hardware trigger lines. Trigger terminals can also carry clocks, but they are not associated with any specific clock signal.
Refer to your hardware user manual for a complete discussion of trigger terminals. Star and DStar triggers may not correlate to slots as expected. You should refer to your chassis manual for more information on routing star triggers. You can use trigger terminals to route single digital pulses between chassis.
In addition, trigger terminals can carry and distribute clock signals. This reservation software integrates with other NI measurements software. Trigger terminal connections are characterized by a source terminal, destination terminal, and route properties such as inversion and synchronization. Check your hardware user manual to see if your hardware supports these additional routing features. The following VI and function deal with trigger terminal connections.
Chapter 2 Building and Programming Applications Software Trigger Terminals Software trigger terminals include those terminals associated with software-initiated trigger pulses. Once connected to destinations, you can initiate a hardware pulse that is then routed to all destinations.
In addition, the software trigger signal can be inverted, synchronized to the rising or falling edge of the specified synchronization clock, or delayed by an integer multiple of the synchronization clock period. The following VIs and functions deal with software trigger terminal connections.
In general, you should start and ensure it has been synchronized before performing any other operations with the NI device. This is enabled by default. Note When an NI device is participating in PTP as a slave device, it may be required to perform a macro phase adjustment.
A macro phase adjustment is when the clock is adjusted by a significant amount and, therefore, the time no longer atomically increments. This should not occur on a well designed and stable network. If this occurs, future time events, clocks, and time stamps may be affected. If the time is set forward, future time events and clock transitions that were missed occur immediately.
If the time is set backward, future time events and clock transitions are delayed. Note If the clock participating in the PTP enters the faulty state, future time events, clocks, and time stamps will no longer be synchronized with other devices participating in the PTP. You can check for this condition by monitoring the clock state property. The following VI and function deal with getting the time. When the time on the time-based device reaches the specified time, the signal level is changed as the future time event specifies.
You can create multiple future time events that change the signal levels on different terminals or change the signal at the same terminal to create waveforms. The time stamp is the board time on the NI time-based device when the specified terminal changed state. The following VI and function deal with enabling time stamp triggers. You can start and stop the clock at a specific board time.
0コメント