The RAD tool is not a perfect fit for all cRIO deployments. If you are unable to use the RAD utility to deploy a new version of drivers to the cRIO the process to get the Network Variable Engine onto the cRIO goes something like this: Install LabVIEW and LabVIEW Real-Time, install NI CompactRIO drivers, install NVE and other driver software to the cRIO and then uninstall the LabVIEW components from the host PC. This assumes that an executable will be installed to the host computer as the UI to the cRIO. Seems like a lot of work for something most people would be using on the majority of cRIO deployments and might assume is a part of the CompactRIO drivers.
At the very least it would be great if the documentation found on the website were explicit as to what software needs to be installed for each of the install options available to install on to the cRIO.
When using the "Open FPGA VI Reference" function you can configure it to reference the FPGA build/bitfile in three different ways:
- Build specification
In development mode I often use "Build spec", for deployment I switch to "Bitfile". When using this function it behaves different, depending in which mode it is configured! This makes for a bad "User eXperience"…
In "Build spec" mode:
- when double clicking the pink border of the function it opens the referenced FPGA VI
- you need to right-click the "Open FPGA VI reference" and select "Configure…" to open the configuration dialog
- when selecting the "Build Spec" radio button it opens a selection dialog (probably a listbox) but you can't double click the build spec you want to use, you need to select the build spec and then click on "OK" button
In "Bitfile" mode:
- when double clicking the pink border of the function it opens the configuration dialog, (you don't need to right-click the "Open FPGA VI reference" and select "Configure…" to open the configuration dialog)
- when selecting the "Bitfile" radio button it opens a file dialog and but you can double click the bitfile you want to use
(All this relates to LabVIEW2014SP1. Haven't tested this with LabVIEW2015 so far.)
I propose the idea to make this behaviour consistent, independent of the selected mode in the configuration dialog!
I wish this behaviour:
- double click on pink border of the functions opens the configuration dialog
- double click on the FPGA VI icon shown inside the "Open FPGA VI reference" function opens the FPGA VI
- double click on an item in the "Build spec" selection dialog selects the build spec
Hola que tal
Propongo se actualice el vi "RT Ping Controllers" para las últimas versiones de Labview, funciona muy bien en aplicaciones HOST que comunican a CRIO por ejemplo, he utilizado este vi de la versión 8.6, sin embargo no sé hasta que versión pueda ser soportada.
Has anyone ported a real-time VI originally targetted to cFP to install on cRIO?
I have an older control program, main VI and subVIs built in LV 8.6 and run on a compact FieldPoint controller.
I would like to be able to use much of it on a cRIO-9036 or something similar.
I am wondering whether LabVIEW (2015 or so) will do the work for me.
Thanks in advance.
Hi everyone , thanks for your time .
I have a text file with a table of data (text file example attached) , this file will be increasing with time , perhaps 500 lines per year , i want to read this file from labview and to be able to search a name (first field of the text file) and the data in the same line belongs to that name , the idea is to read line by line and if the first field matches the name searched , then get all the data in that line as a string , the data types don't matter .
As well i have to be able to delete a complete line of the same text file if the name matches the one searched .
Any idea will be agreat , Thank you very much for your help and time !
The cRIO9031 with Linux Real Time did not support SDXC cards. Only SDGC with a maximum of 32GB supported by cRIO.
For logging application their is a need for more than 32GB => use of SDXC cards with 128/256 GB
Hello LabVIEW Users.
My name is Eisuke Ono, An Application Engineer at NI Japan.
One of our customer is requesting a function.
The function is to retrieve information of module fault from C Series I/O variable Node (Scan Interface).
I know that we can get the information of module fault through FPGA I/O node, but not through Scan Inteface mode.
The customer's application is embedded condition monitoring system. It runs 24/7.
So it is very convenient if he get information of module fault C Series I/O variable Node Error Output.
I agree his opinion.
What do you think?
For the use of a variator that generates his own clock and distributes it on EtherCAT, I need to make the RT loop synchronous with clock posted on EtherCAT by the variator.
So would require the scan engine parameter is in receipt of the EtherCAT clock.
This function is imperative on Labview-RT to be compatible with ability to manage EtherCAT variators ( Beckhoff).
At my company for all of our real time work, we are starting to use Veristand a lot. It is great that there are so many already available primitives on the Veristand palette within labview which are very useful. However, there is currently no Veristand primitive in Labview, that actually starts the Veristand.exe program itself. You have to use the System Exec to do it. I think adding a Veristand primitive that performs this function would be great.
For the NI 6008 card sampling frequency equal to 10 kS / s and it has 8 analog inputs, but if I will use the 8 analog inputs simultaneously, what is the value of the new échantionnage frequency for each input analog obtained during an acquisition in labview?
To allow expansion of DAQ capabilities from a real time PXI Rack it would be nice to be able to add a Compact DAQ chassis to the ethernet port and address it like you can on a desktop. I understand this is possible for USB connected chassis but not ethernet.
This would allow an existing RT DAQ system to be easily expanded, or to acquire data from remote points without the necessity of wiring every channel back to the main rack.
Many of the features that are not supported on LinuxRT are things that one would expect not to work (due to the underlying technologies), but why no menu and cursor functions?
The lack of menu support in particular means that most GUIs have to be customized to run on the target....even though Xfce should be perfectly capable of handling them in their original design... I was really hoping we could port some of our GUIs straight to the embedded GUI and replace our industrial computers immediately with cRIOs...(the differences in appearances are easier to handle, after all we use system controls and take cross-platform variations into consideration already).
Now we'll have to (decide if we want to) spend time on customizing the GUIs.
The new embedded GUI option on the new LinuxRT based cRIOs is great. It would
a) be nice to be able to access it remotely, and
b) with remote access *all* LinuxRT targets could support it, even the ones without a display port...I would love to use that on our new sbRIO-9651 instead of going back typing in the Bash shell...
c) Perhaps the GUI could even be embedded into the web interface as well :-O
It would be good to enhance access security to also include program-control of cRIO's. As it is now you can set user access for a cRIO in a project by opening the Real-Time CompactRIO properties and set Allow/Deny access by IP. However, this only limits access to deploying settings and eventual RT applications on the cRIO. You can still control the cRIO (e.g. set outputs and, as in my case, control servo motor drives connected to the cRIO) from a LabVIEW application on any PC on the LAN.
This added access control could eventually be set up in MAX.
Many measurement and process control application run at relatively slow rates (<100Hz). Using SCAN Engine on the CompacRIO for data acquisition is ideal for these applications because you don't need to program the FPGA and all the measurement and control logic can be implemented on the Real-Time controller.
In many cases you want to process your data before you analize it. Currently you only have the ability to get the raw measurement data from the AI modules, so you need to add the data processing code to your existing LabVIEW program. It would be helpful if the SCAN engine could offload some of the data processing (ex. lowpass filter or sample average) to the FPGA and provide the user with already processed data. For example, this functionality can be added to the module configuration page:
With the linux-based cRIOs the console ("Write To Monitor" ; as intended before working with VxWorks/PharLaps OS) disappeared.
It's only possible to have strings pushed to the RS ports or in a (not managed) file.
As many cRIOs are connected to the network, it would be nice to have the "Write To Monitor" console access through Ethernet port.
The idea would be also to keep the global functionnalities of this console : see the strings in the cRIO webpage (of course), but also keep strings in a managed file (max number of logs in a file, ...) to have a 'buffered' access to strings sent to the console...
In brief, bring us back the 'Console' !!
If you have an RT target set up with a startup application (ready to be deployed in the field), running a VI on it from the IDE should not change anything permanently.
Today (LabVIEW RT 2013), doing this will not just temporrarily stop the VIs running on the target (from the executable) - as you get warned about, but also cause the RTTarget.LaunchAppAtBoot=True line to be removed from the ni-rt.ini. So the startup application will not be launched the next time the device is started up, rendering your device useless in the field. Why?
- We had an incident where we narrowly escaped such a scenario. The RT target was embedded into a cannister that was about to be sealed, but an unforseen issue made it necessary to run a special test on it, with a VI from the IDE. The startup application in this case provides the only way into the system once the cannister is sealed (no Ethernet access, just RS485), so having it no longer start would be a catastrophy. No one expected running the VI would actually change anything permanently. We tested it of course, and saw that it stopped the startup application (and so we loaded an image of the correct setup afterwards to be sure all changes were removed), but it would be much better and more intuitive if no such permanent and fundamental changes occured (if actually possible to implement in a such a way).
It seems making plugins to Visual Studio has been abandon but it wouldnt matter if we were able to use a modern and full featured IDE. Use eclipse as a base IDE and develop features on top of it including the ability to downlod and execute code to real time targets. Developing an IDE based on eclipse isnt unhead of this is vxworks does with wind river workbench.
It would be nice to had the ability to create more than one RT target in a project with the same IP address.
For the moment, if you try to use 2 same IP address, The LabVIEW IDE don't let you save your modifications !
You may say WTF !!!! The manu has so curious ideas !!!!
My need is for example to had 2 configurations for 1 only RT CRio.
Or an other way to use multiples targets ...
Yopu may say this can be done by using different build specifications.
I will say yes ... But my need is to separate the two versions of LabVIEW sources !
=> 1 project/target linked to an autopopulating folder in version a
=> 1 project/target linked to an autopopulating folder in version b
=> So my need is to be abble to use RT Targets as "Target versions"
=> To be abble to do this ... i need to create multiple targets with identical IP addresses.
Thanks for reading.