Labview 2015 Real Time Module Download
Sara Ruballos
Does it mean that I can build and run real-time (deterministic) applications even on standard PC only if I use Real-Time module in a proper way during coding?
So I don't need to run app on NI hardware with NI Linux Real-Time OS?
But around 2008 Interval Zero, the new owner of Pharlap ETS eventually announced that they were going to discontinue Pharlap ETS in favor of their own RT OS platform RTX (nowadays RTX64). So NI had to search for a new platform for their x86/x64 based PXI controllers. And they ended up with Linux with some specific real-time enabled patches.
It does not apply to installing NI Linux RT on your own hardware. And as explained, you can download the sources of NI Linux RT and compile it to whatever platform you like and install it on there. It is after all simply Linux with some custom patches and build configurations. But that is simply a Linux kernel and does not contain any NI specific software. Accordingly you can not use it for LabVIEW Realtime. For that you need the real-time capable LabVIEW runtime engine and quite a bit of other NI software, which is not GNU licensed, but with an NI proprietary license.
Thank you for explanation.
Now practical question:
My company produces modular HW platform with ARM processors, FPGAs, various communication modules incl. Ethernet, CAN, RS-485, AI/O, DI/O,...
HW runs on our own distribution of Linux RTOS. (I'm not involved in development of this core product too much, but much more in development of applications that uses this HW platform in the industry).
It would be nice to somehow use this HW platform e.g. for HiL testing of our final products, at the best case in real-time mode with using apps made in LabVIEW.
I guess that running Runtime Engine on our Linux OS would be possible and maybe good starting point. (I didn't try it yet)
But as this discussion is focused on Real-Time, I would ask you what approach you would use to reach sufficient compatibility of 3rd party HW with apps compiled for LabVIEW Real-Time OS? (nice-to-have would be possibility of use of FPGA Module). E.g.:
1) Throw away 3rd party Linux RTOS, and start with customization of NI Linux RTOS kernel?
2) Keep 3rd party Linux RTOS, and somehow modify anything else?
3) Write own compiler?
4) All the ways are limited with crucial proprietary parts of whole system. So it's not possible.
Another technical point. Your device may be using an ARM Cortex M CPU. LabVIEW realtime for their ARM platform (Zync 7010/7020) specifically requires a Cortex A architecture. This is because the Cortex M and others are optimized for low power embedded devices and lacks certain features such a memory. virtualization and floating point support that LabVIEW relies on.
The LabVIEW Real-Time Module is a software add-on for LabVIEW that you can use to create and deploy real-time, distributed system applications for test, monitoring, and control. Take advantage of a Real-Time OS to ensure reliability and precise timing in your stand-alone system. Save valuable development time by selecting from hundreds of prewritten LabVIEW libraries and hardware APIs, which enable deterministic data acquisition.
My issue is that when I get the stage in Max to install software, the LabVIEW real-time module does not appear in the list of software that I can install, and everything depends on the LabVIEW real-time module so I can't install anything.
NI installers define a single or a list of top-level products (packages) to install. The LabVIEW RT Module installer lists a single package to install (ni-labview-2022-rt-module-en). The installer includes LabVIEW as well as a dependency, so LabVIEW will be installed if not already installed.
The PXI systems leverage commercial processors so they are not necessarily any more powerful than a desktop. From a hardware perspective you just have to consider quality. Your average desktop PC is designed to run < 8 hrs a day for a few years but the PXI systems are designed for 24/7 running. They may also feature additional real time elements such as hardware watchdogs and lower jitter setups. Not to say there aren't also PCs that can do that but not your standard consumer grade PC. If that is not required for your application I expect you will be fine.
A "timed loop" is a while-loop structure that executes at a precise user-specified rate. Timed loop are particularly useful for process control loops that demand a reliable update rate. SummaryTimed loops operate with a precisely-defined iteration time, and are the primary purpose of a real-time operating system (RTOS) such as the NI Linux Real-Time operating system.
For real time plots I find the Real/Imaginary Complex Number Function handy even when I'm not doing any complex value calculations. This is because the complex data type holds two floating point values which allows you to update a single plot of an XY Graph with a single complex value because it holds both the X and the Y components of the new data point. Extending this to multiple plots is done just as Lior explained above (using plots instead of the complex data type) because the XY Graph also accepts an array of complex values where the size of the array corresponds to the number of plots in the XY Graph. See the function labeled "Re/Im To Complex" in the image/snippet below. This particular snippet starts overwriting data previously plotted after the first 250 lines have been drawn. In other words, the line from point 0 to point 1 disappears and is replaced by a new line from point 249 to point 250 and so on.
This blog gives a very brief introduction to setting up a real-time cRIO project in LabVIEW. This is often the first step required for any control project in LabVIEW, and we will refer to this blog from some of our other blogs.
First things first: you will need a LabVIEW real time license to run real time projects! This includes the LabVIEW real-time module, and we generally also recommend the LabVIEW FPGA module to go along with this. The real time environment enables control loop rates of order 1ms, while the FPGA environment enables control loop rates of order microseconds. Once you have all modules installed, LabVIEW should start up as shown below
You can now add VIs under both the real time target (right click at the NI-CRIO level and select New > VI) and the FPGA target (right click at the FPGA target level and select New > VI). Once these VIs are added, your project should look like this.
To obtain real-time operation, the software obtains calculations from the model and then waits for the clock to catch up. (A 30-second simulated test must take exactly 30 seconds to run when there is HIL.) The precise timing needed to communicate with electronic controllers is provided by RT software running on a special RT operating system.
In all cases, the same models are used, with the same equations, solution methods, inputs, outputs, and post-processing tools. You can run datasets in real-time on different systems based on HIL needs, and exchange data sets with other users running on different systems, and users running off-line on ordinary Windows machines.
Digital outputs (DOs) were used to control various aspects of the test, such as door open/close and defrost on/off cycles. For flexibility, the user can specify the sequencing of these DO channels, in the Excel file used for the test, with various parameters that define the duty cycle, period, number of cycles, and start delay. The timing of these DO state changes was synchronized to the data acquisition by the real-time loop in the cRIO.
Viewpoint leveraged another application, developed for the client a few years prior, to harmonize the user interface and to reduce development effort. Most of the development time focused on support and configuration of the multiple module types and ensuring that the data synchronization functioned as required. The result was an ultra-flexible, portable, high-speed data acquisition software/hardware combination that can be used to acquire time-sensitive, synchronized data across multiple modules in a PXI chassis running a real-time operating system.
The engineers at Quantum recognized that they had an opportunity to improve the bottle formation process by adding position sensing to their plunger mechanisms. The ability to sense and record plunger positions would enable machine operators to monitor the travel of the Quantum plunger into the molten glass gob within the blank side mold, identify and diagnose potential hardware problems, and provide real-time feedback that could be used to better control the process.
As with most validation test systems, we needed to monitor conditions for safety. New product designs are often operated near the edges of safe operation in order for the designer to understand how the product performs in extreme conditions. For this fuel cell application, destructive over-heating and over-pressure could occur. Both digital and analog signals were watched in real-time to assure operation within reasonable bounds and allow a safe shutdown if the fuel cell ran into out-of-bound conditions.
Additionally, the pulsing amperage levels needed to be tightly controlled in order to know that the tests have been performed properly. Thus, a real-time amperage control scheme had to be implemented to maintain the level requested for the pulse. We chose to accomplish this control via an analog control circuit developed using a custom Viewpoint-developed circuit board. This board was controlled via a Microchip PIC microprocessor. The LabVIEW RT application communicated with the microcontroller to setup the pulsing sequence and coordinate the start and stop of the pulsing and the NI acquisition hardware.
In the case of the tip timing, the data rates were high enough that the detection of the tip location for each signal needed to be performed in the FPGA so that the real-time (RT) layer received a much-reduced data rate of tip locations. The RT processor was able to perform higher level analyses on these timings. Occasionally, a snapshot of a raw tip timing waveform could be passed to the RT processor for archiving and presentation to an engineer. However, due to the data bandwidth and processor loading of the CompactRIO, such snapshots must be infrequent.
df19127ead