Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
Do you have an idea for LabVIEW NXG?
Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!
If you are using TCP to communicate to a different code environment, you may want to set some of the socket options. For example, for responsive control, you will want to disable Nagle's algorithm. There is currently no obvious or easy way to do this. TCP Get Raw Net Object.vi in <vi.lib>\utility\tcp.llb will provide the raw socket ID, but you then need to call setsockopt() on your particular platform using the call library node. You can do this with the code provide here. A much better way would be adding a property node to the TCP reference that allowed you to set and query the options directly.
To support modern web thin clients, the LabVIEW webservice needs to support the OPTIONS request. When a web browser makes a cross origin request there are a few rules that the response must comply with before the browser will provide with the result to the web application. The OPTIONS request is needed to respond to these requests.
Depending on the request, the browser may issue a "preflight" request. "Standard" requests are GET and POST requests without custom header fields only require the response has an additional headers. Other requests (PUT, DELETE, GET w/ headers, POST w/ headers) require a preflight request. A preflight request is an OPTIONS request. If the OPTIONS request doesn't get an appropriate response, the browser will not even make the actual request. https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request
For example, I'm starting an application and here's how I'd like it setup.
2. A bunch of CRIOs. These CRIOs will also host their own web service to get system information, measurements, and diagnostics. As new CRIOs are commissioned, they'll report to the Windows PC.
This is just one example. Another case would be an Apache hosted web application hosted on an Amazon EC2 needs to make requests to a LabVIEW web service running in a different domain. Basically any time a web application (AKA something running in the browser) needs to communicate with a LabVIEW web service you'll run into this problem.
LabVIEW's HTTP Request client currently does not support the PATCH method. This method is becoming increasingly more popular within RESTful API's and has been an officially recognized verb since 2010 (RFC 5789). It should be fairly simple to integrate, since LabVIEW runs cURL under the hood and cURL implements it with curl --request PATCH
LabVIEW needs native SSL/TLS support for the TCP primitives. The HTTP functions support it (see \vi.lib\httpClient\ConfigSSL.vi). There are several great LabVIEW native MQTT libraries that could be commercially usable if there was native SSL/TLS support. Not having this functionality for the TCP primitives makes LabVIEW a poor choice for an IoT platform.
The web format wars are over, and the plug-ins have lost. Microsoft has relented and will support HTML5 and SVG in IE9, and has admitted that Silverlight's role will change to that of a Windows phone development platform. Silverlight support on iPhone/iPad/Andoid/Chrome OS will likely never be fully formed, and will wither on the vine.
I have built my own SVG UI objects using Inkscape (free), and wrote a script (notepad/Inkscape script editor, also free) to handle WebSockets communication without a gateway. I have a simple LV class built on the TCP/IP functions that will stream data to/from a browser which is pointing to an SVG "webpanel" that I also built using Inkscape. So far I have a simple waveform graph, buttons, LED's, progress bars, etc. I have tested my Inkscape webpanels in Firefox 4.0 Beta and Google Chrome 9 and it works like a champ, and is very fast. The old-fashioned LV webserver will serve up SVG files with the addition of a mime type.
An alternative to SVG is the HTML5 <canvas> tag, which allows the rendering of graphics drawn using java/ecma script. There is a free-for-personal-use script library called RGraph Library that you can download with lots of example code. Here is RGraph/LabVIEW in action in Chrome 9:
So what is my idea?
0. Ditch Silverlight.
1. Convert all of the nice-looking UI panel objects in the Web UI Builder from Microsoft XAML to SVG and distribute them with the LabVIEW professional development license. I am programmer first, and I admit my web panel objects don't look too good.
2. Design a script library for handling WebSockets communcation (or add native support for WebSockets to the Shared Variable Engine) and manipulating/updating the SVG UI objects from streamed WebSockets data. Make this library open source.
3. Create a standard open protocol for streaming LabVIEW data that sits on top of WebSockets and is free and open.
4. Publish documentation for the SVG UI elements so users and thrid parties can create new UI objects. Make use of the creativity of the community at large!
5. Modernize the Web Publishing Tool so that it will optionally output an HTML5 and/or SVG document that accepts streaming I/O from WebSockets. The user could choose from compatible SVG elements to use in place of front panel elements on the VI being published.
6. Create a Web UI SVG element exchange for registered NI users to upload/download elements for free.
7. Work toward the long term goal of adding SVG Import/Export to the control editor (with better editing tools), or make the CTL format of custom controls SVG/XML.
The current low level implementation of TCP functions only accesses a data stream, but not the raw data of the tcp telegram. It would be nice to have a low level TCP "Read/Write Telegram" function to get additional information from header or footer, like time stamps. Maybe as a buffered stream, like the current functions.
The resulting cluster could look something like this:
The request is mostly in the title. Right now it seems as though changing an alarm limit requires stopping the OPC UA server. It seems reasonable to expect that users may wish to adjust alarm limits on the fly -- for my use case, tuning the system during a long commissioning process. It might be many months before a system is fully ready to go, and during that time alarm limits change regularly and we still want to report alarms to operators during this period.
There are a plethora of timestamp formats used by various operating systems and applications. The 1588 internet time protocol itself lists several. Windows is different from various flavors of Linux, and Excel is very different from about all of them. Then there are the details of daylight savings time, leap years, etc. LabVIEW contains all the tools to convert from one of these formats to another, but getting it right can be difficult. I propose a simple primitive to do this conversion. It would need to be polymorphic to handle the different data types that timestamps can take. This should only handle numeric data types, such as the numeric Excel timestamp (a double) or a Linux timestamp (an integer). Text-based timestamps are already handled fairly well. Inputs would be timestamp, input format type, output format type, and error. Outputs would be resultant format and error.
I have been recently asked by NI to answer a poll about what feature I would like to see as far as data management and access and at that time, I didn't really think about mentioning something which is dearly missing in LabVIEW: cloud storage access.
The reason for this request is that increasingly, files used by collaborations cannot always be copied locally (for instance due to their size or because of frequent updates), or managing local copies and updating the central cloud repository is getting prohibitively time consuming and cumbersome.
There exist a few attempts in this direction (e.g. GDrive for LabVIEW, a third party skeleton of a toolkit to access Google Drive, or LabVIEW Interface for Amazon S3), but there are some glaring absent ones such as Dropbox, OneDrive, Box or iCloud to name the most popular ones.
As I mentioned before, GDrive is a starting point but is missing some basic features such as folder list, comments, etc.
I cannot comment on Amazon S3, as I don't use it.
Obviously, there is no way to predict which cloud storage solution will disappear in a few years from now or which one will pop-up tomorrow and become popular, but most of the work has been done by those vendors, who provide .NET API for their cloud solutions (maybe not Apple) or at the very least a RESTful API. These APIs could of course be made community projects (like GDrive is to some extent), but their importance would seem to justify a minimal investment from NI.
Connecting to remote panels using LabVIEW is difficult if private networks, local private and external public IPs (under NAT), and firewalls, etc. are involved. It requires significant knowledge as well as external networking configurations (port forwarding, etc.), and possibly admin privileges to modify those.
There are plenty of companies that have found a way around all this. The prime example is chrome remote desktop, which seamlessly works even if target computers are in hidden locations on private networks, as long as each machine can access the internet with an outgoing UDP connection. The way I understand it, each computer registers with the Google server, which in turn patches the two outgoing connections together in a way that both will communicate directly afterwards. All traffic tunnels inside the plain Google chat protocol (udp based). Similar mechanisms have been developed for security systems (example) and many more.
Since the bulk of the traffic is directly between the endpoints, the traffic load on the external connection management server is very minimal. It simply keeps an updated list of active nodes and handles the patching if requested.
I envision a very similar mechanism where LabVIEW users can associate all their applications and distributed computers with a given user ID (e.g. ni profile), and, at all times be able to get a list of all currently running remote systems published under that user ID. If we want to connect to one of them, the connection server would patch things together without the need of any networking configuration. Optionally, users could publish any given panel under a public key, that can be distributed to allow public connections by any other LabVIEW user.
This is a very general idea. Details of the best implementation would need to be worked out. Thanks for voting!
I would like to see more native support for compression and encryption/hash algorithms.
When it comes to compression and encryption. We are very much the poor relations to other languages that have a plethora of source and examples for SHA1, DES, 3DES, Blowfish, HMAC, Ryjindel, AES (encryption) and LZO, LZMA, LZW, GZip, JPEG2000 (compression) to name but a few.
Apart from "Zip" (which can only be used on files) and "twofish" (which is hardly an industry standard because of security concerns) we have very little choice but to use DLLs and SOs meaning our applications violate one of the biggest reasons for using LabView........cross-platform. We have very little in our tool-kit to make efficient and secure network applications for example. Especially if we are required to interface to existing systems that ave used these technologies for many years.
We cannot even write applications to access Twitter any more!
With the introduction of "Stream" prototypes in the new LV2010, it is essential to have these tools in our palettes.
In the current LabVIEW XML Schema, the flatten to XML string supports variants, but not variant attributes (and by extension waveform attributes as well). This is unfortunate as variant attributes remain one of the best ways of implementing a dictionary type data structure and they are also a useful way of adding additional metadata to waveform signals. In both cases, serializing the attributes to XML strings properly would greatly facilitate data exchange with non LabVIEW code.