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!
With the advent of the IoT and the growing need to synchronize automation applications and other TSN (Time Sensitive Networking) use cases UTC (Coordinated Universal Time) is becoming more and more problematic. Currently, there are 37 seconds not accounted for in the TimeStamp Which is stored in UTC. The current I64 portion of the timestamp datatype that holds number of seconds elapsed since 0:00:00 Dec 31, 1900 GMT is simply ignoring Leap Seconds. This is consistent with most modern programming languages and is not a flaw of LabVIEW per se but isn't quite good enough for where the future is heading In fact, there is a joint IERS/IEEE working group on TSN
Enter TAI or International Atomic Time: TAI has the advantage of being contiguous and is based on the SI second making it ideal for IA applications. Unfortunately, a LabVIEW Timestamp cannot be formated in TAI. Entering a time of 23:59:60 31 Dec 2016, a real second that did ocurr, is not allowed. Currently IERS Bulletin C is published to Give the current UTC-TAI offset but, required extensive code to implement the lookup and well, the text.text just won't display properly in a %<>T or %^<>T (local abs time container and UTC Abs time container) We need a %#<>T TAI time container format specifier. (Or soon will!)
The NI SMTP library is good at making e-mailing simple. But now and then I will get error 363513 (an error occurred on the network).
There are multiple known causes for this error that one can prevent, but also some unknown. The error does not specify them. I am therefore still struggling to get my e-mailing routines impervious to this error. The library should return more specific errors.
There are multiple other known issues with this library, making it quite unreliable for automation purposes. A shame, as there are few alternatives available.
A few suggested VIs for beefing up this library could be:
check if server is online
set popular SMTP header values (I don't know them, like most of us I assume)
check if e-mail was successfully sent to recipients
meta data returned: unknown recipient, attachment size exceeds limit of xMB etc
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
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.
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:
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.
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.
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.