LabVIEW Real-Time Idea Exchange

Community Browser
About LabVIEW Real-Time Idea Exchange

Have a LabVIEW Real-Time Idea?

  1. Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
  2. Browse by label or search in the LabVIEW Real-Time Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  3. If your idea has not been submitted click New Idea to submit a product idea to the LabVIEW Real-Time Idea Exchange. Be sure to submit a separate post for each idea.
  4. Watch as the community gives your idea kudos and adds their input.
  5. As NI R&D considers the idea, they will change the idea status.
  6. Give kudos to other ideas that you would like to see in a future version of LabVIEW Real-Time!
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

As explained in this post, the most recent version of SQLite library via opkg is 3.22.

 

This version is so old that it doesn't support all the features available via the SQLite Library publish by Dr Powell.

 

as explain in the post above, compiling a newer version from the source code available at sqlite.org is doable (I did it for v3.34).

Please support UEFI and newer processors such as i9 for deployment. If possible, changing from PharLap to Linux is also preferred.

Currently, non default map constants (like the one shown below) are detected as fatal insanities when deploying to Real-Time targets and crash the LabVIEW development environment.

tannells_0-1581614386711.png

There is a workaround, which is to build the map from other data structure constants. The map constant above was built from the code below. However, it takes longer to execute, and it takes more code. That is okay in some cases, but it would be better if there was an option to simply use the map constant above.

build map.png

 

Hello LabVIEW Enthusiast,

 

NI has introduced malleable VI function since LabVIEW 2017. It is a great function to have in advanced LabVIEW application development.

But "Stall Data Flow.vim" function is missing in Real-Time Target OS from timing function palette since 2017.

It is not like you can not use malleable VI in RT side, I have copied same VI from desktop VI to RT VI. It works fine without any error or broken arrow.

 

NI should include this types of VIs in RT package by default.

RT has Type Specification Structure too, which creates question for me on this missing VI.

 

If you have any reason(s) to share on this why it is not included on RT side, Please share your thoughts.

RT Side.JPG

Host Side.JPG

Thanks,
Vinal Gandhi

Download All

Could we have SSL on by default in the standard software sets for RT targets? It is not like there is much security in the default setup anyway, so having SSL active as well as the web interface with default passwords is just more practical (if that is the rationale for not having it on...(?)).

Background:
Whenever I have loaded a default software package onto an RT target using NI MAX, I run into this little snag; I try to log onto it using SFTP or PuttY - only to rediscover that this is disabled. So then I have to go to the web interface or NI MAX to enable it. Most of the time we use RAD to replicate PACs anyway, but this is still another little thing we have to remember every time when dealing with the very first setup.

cRIO with embedded UI enabled allows us RTEXE front panel interactivity, with the ability of front panel objects' properties being changed programmatically. However, when connected with PC via Remote Panel, only object values are updated, but not the objects property (for example: table headers string arrays). This could lead to miscommunication of information as the Front Panel from embedded UI differed from the Remote Panel. 

 

I was informed though, if we looped the write property node continuously, the property can be updated from the Remote Panel end. This, however is counter-intuitive as we usually initialize the GUI objects programmatically once at the beginning (or if necessary due to change) and not continuously. Nevertheless, if Remote Panel can update the front panel objects during first launch and property change, similar to "Is Value Changed.vim", that would be great feature to have.

Softmotion 2018 disabled the function "write position setpoint" for a NI 9514 module axis.

This was a useful function and will always be useful. ex.: Application like a tracking system need those functions.

 

Please put it back. Stuck with LabVIEW 2016 and windows 7 now.

Hello Fellow developers and engineers.

 

Based on the discussion in this thread I would like to propose the following:

 

My suggestion is to open support for execution of python nodes on Labview Real-Time targets. This is currently not supported by LabVIEW 2018 Current Gen, even though this version supports executing a python node using the new "Connectivity -> Python"-support. 

This should be possible to do on the targets using NI Linux Realtime as the operating system, since Linux treats python as a native application language.

 

I understand that the execution of Python scripts are not deterministic, which will prevent an implementation in time critical code. That I can follow, but it should be possible to use the python node in lower priority threads or non real-time code, for communication with a REST-API, downloading/uploading files, connectivity to online services and so on. 

It has been shown that python can be compiled and executed on real-time targets, here on the forums by Sev_k in this thread: Getting the Most Out of your NI Linux Real-Time Target

 

Therefore I propose to simplify this implementation and open the support for Python3.

 

Some additional implementations are essential for the success: 

  • Selection of Python runtime should be fixed to python3, since python 2 will be without further support or active development from 2020-01-01 going forward. 
  • It would gain the best momentum if it was possible to deploy python from the Device Software installation as part of the build specification of the real-time application.
  • Python developers can specify their external requirements for additional code by defining a "requirements.txt" or "pipfile.lock" depending on the virtualization method and choice of development style. If the project manager or build specification could read/parse this for the starting point of the application to prevent manual labour and possible errors.

 

Backwards Compatibility:

Support for this should be from LabVIEW 2018 and forward, since these have support for the python nodes.

 

Best Regards

Jesper

LabVIEW Real-Time 2018 on a PXI target with PharLap does recognize a NI USB-232 adapter as a USB-RAW device.That's bad. (e.g. you can't set Baud rate etc.)

 

It should be recognized as an additional RS232 port like VISA "ASRL3::INSTR".

(like same way, when I connect the USB-232 adapter to a Windows-PC)

Hello,

It would be nice to add a filename Check in the Crio executable process generation, in order to detect accentuated characters !Smiley Happy

When you use accentuated file names, the generated Crio Linux executable does not work ... it crashes without any message !!! Smiley Mad => NI Linux does not support accentuated file names !!!

=> The problem is that the Debug mode works fine, and doesn't work like the executable !

 

It should be nice to add a file name verification to the generation processus in order to highlight the problem .   Smiley Wink

 

Thank for your help.

 

Manu.

I use "Set System Image" to set an image on freshly manufactured units. Every now and then, the imaging process fails for one reason or another (possibly a hardware/networking failure). I know that the image process in my case usually takes about 4 minutes. Unfortunately when the imaging process fails, there's no way for the application to gracefully stop "Set System Image". The only option is to wait a really long time or use the task manager to force-quit the application. The abort button on the VI doesn't work

 

So, I'd like one of two things. Either, an input so I can adjust the timeout based on my application or some way to let "Set System Image" know that the application would like to stop if possible (maybe nothing had been written yet). For example, it could take in a DVR and the application could feed it a "true".

System Image Escape.png

64bit has been the dominant architecture for a decade; any computer with more than ~2.5GB of RAM must use it after all. It is inevitable that 32-bit machines will cease to be made - maybe not tomorrow, but let's be realistic. Let's get ahead of the times and convert modules to support 64 bit support. Please!

 

 

It is really useful to be able to edit text files through the web based file explorer.

 

As it stands only certain file extensions are editable. (.conf, .txt, .ini). It would be great if all files were editable by default to handle custom extensions used on our applications.

We have the ability to get memory usage and cpu use. I'd also like to also monitor network usage to see if my application is getting close to the point where it would have to either buffer or drop messages.

The Set System Image VI (and by extension, the Replication and Deployment Tool) have a deployment blacklist. Currently, files on that list are never deployed. It would be helpful if instead, those files, if they exist in the image, were deployed only if they do not already exist on the target. That would make it easier to create a single image that could be used for both an upgrade, where you do not want to overwrite existing configuration files, and for initial setup, where you want to install a default configuration file.

 

Did I misunderstand something about the way the deployment blacklist works? The documentation says "Files on the blacklist will not be copied from the image to the target" which makes me wonder why you would ever want to include those files in the image at all.

Currently, on the cRIO-903x series controllers, the Chassis Temperature and the USER1 push button are only available on the FPGA http://digital.ni.com/public.nsf/allkb/75E039282A8B691886257E450049C7B6 and require the chassis to operate in a Hybrid Mode in order to use both the Scan interface and those chassis I/O options.

 

The cRIO-902x series allowed for both of these I/O options to be accessed in the real-time OS directly. This small feature would add convenience on the cRIO-903x series controllers.

I think it would be a solid improvement in LabVIEW if the real-time development module and other modules available to the Windows OS are available to the Mac OS.

 

Some of these modules that are needed are the real time development module, vision development module and CVI.

 

Thanks 

The SVE on a windows based platform acts as a OPC-DA server. Due to the requirements for DCOM, this is not possible on real-time target. However, as OPC-UA is gaining traction, I would find it very useful to have the SVE act as an OPC-UA server for integration with 3rd party systems (SCADA, IIoT).

 

I know that there is the OPC-UA API palette, however, this takes more time to setup than creating a shared variable (i.e. a tag) and moving on with the application development. If update rates are slow enough (500-1000ms), I have found the shared variable to be more than adequate for my applications (500-800 NSVs), so I'm not looking for granular control over how I send data out of the cRIO system. Ease of use is my primary concern.

Currently viewing, testing or configuring NI-9862 Modules in a cRIO using NI-MAX needs a lot of effort. It requires:

- Installation of the complete Labview Realtime and FPGA development suite on the connected PC

- Setting up a Labview project including the NI-9862 Modules and an empty FPGA VI

- Compiling the emty FPGA VI to a FPGA bitmap file

- Starting the FPGA VI

Without these steps the NI-9862 Modules are invisible in NI-MAX

 

Proposed improvement:

- NI-MAX should include a default FPGA bitmap file that includes the communication with NI-9862 modules

- When the user connects to the cRIO with NI-MAX, the current cRIO configuation should be automatically saved to a backup and the default bitmap file should be activated

- When the user disconnects, the backup should be restored

 

Advantage:

- viewing, testing or configuring NI-9862 Modules in a cRIO could be possible just by starting the NI-MAX and connecting to the cRIO, as simple as with any standard I/O modules.

Currently a VI running in a Real Time environment does not support run time menus.  I understand the restriction, but what I find odd is VIs that have the menu reference wire cannot compile for RT targets.  This may seem like no big deal, because why would you have a menu reference wire, but not use it?  But I have come to find two examples that make RT code a bit more difficult due to this issue.

 

If I have a polymorphic VI, and one of the polymorphic types has a menu reference terminal, then I can't use that polymorphic VI in an RT VI, even if the instance that is being used doesn't use the menu reference.  One work around for this is to wrap the entire VI that does use the menu reference (terminals and all) in a conditional disable structure so that it does nothing on RT.

 

Another issue comes in the form of templates.  I have various temples to get code started, and most of it can run on RT or other targets without any need to change the code, just place conditional disable structures where needed.  But I found one issue where I can't have an event structure on RT, that has the Shortcut Menu Activation? event, because it generates a menu reference wire. Ideally this event just can't be generated on RT, so the compiler would know to not include it, and it would allow the VI to run on RT.  Same for polymorphic VIs that have a menu reference in one of its instances.

 

A better solution might be to lift all restrictions of using the menu reference wire on RT, and just assume that using the menu reference on RT does nothing, like a No-Op.  Optionally an error could be generated if one of the menu reference functions are used, but for the sake of simplicity I'm not sure that is needed.  What I'm really looking for, is a way to allow VIs to run on RT, that have menu reference wires types, but aren't used.  Note the VI below which can't run on RT and the reason given is that the menu reference can't be used on RT, but it isn't being used, it is just wired to a disabled case.