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!
The current implementation of flattening and unflattening from XML is quite noisy and includes information unnecessary for the users. Rewriting it or including Pretty Print functionality to LabVIEW would greatly simplify loading settings, exchange of data with other languages, dynamic configurations, visualizations of complex systems, network communication etc.
Traditionally LabVIEW has treated Strings and Unsigned Byte Arrays as being the same. This is nowadays a little unfortunate as all UI systems use some kind of encoding so Strings are not generally interchangeable with Byte Arrays anymore.
In trying to stay for binary data as much as possible with Byte Arrays instead of Strings, since that would be the sensible thing to do, the Unflatten from String (which should rather be called Unflatten from Stream) puts a totally unnecessary wrench into this.
I always had hoped that LabVIEW would change the default binary data stream format to a Byte Array at some point but this while it would be possible, is a fairly pervasive change that would require many backwards compatibility decisions that I unfortunately don't see NI going to spend time on anymore. This change however would be a very small change that has zero backwards compatibility concerns and almost no work to add to the existing LabVIEW software.
This same change has been for instance made to the TCP Write node some versions back already and could be also applied to the VISA Write!
It would be nice if the LabVIEW primitives for TCP allowed for the creation of a socket without actually connecting it to an endpoint. My thoughts are that there would be two new commands added to the TCP palette:
TCP Create Connection (Advanced)
TCP Open Connection (Advanced)
TCP Create Connection (Advanced) would create the socket but not perform the connect() method on that socket. I would imagine that it would otherwise look and feel quite like the current TCP Open Connection, except that the user would need to manually run TCP Open Connection (Advanced) afterwards that would perform the connect() method on that socket.
I have a need to access the raw socket object before it is connected, using the TCP Get Raw Net Object.vi in the vi.lib\Utility\tcp.llb library. This VI works to get the handle that can be used by winsock and other Windows DLLs, however, it only allows for setting properties for a socket that is already connected.
Specifically I have a need to enable Windows FastPath for TCP to optimize the rate at which I can stream data between two applications. Per the specification, this option must be enabled BEFORE the socket is connected. Right now I can set this for the listener on the server side (TCP Create Listener creates a socket but does not connect), but I cannot set it for the TCP connection on the client side as the first method it calls is TCP Open Connection which returns a socket that is already connected.
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!)
Please add to AF: Ability to seamlessly communicate over the network and create your own queue specifications. For example actors should be able to talk between physical systems. Using the Network Actor is not a good solution, because it is simply to verbose and difficult to understand. The philosophy of AKKA should be embraced here "This effort has been undertaken to ensure that all functions are available equally when running within a single process or on a cluster of hundreds of machines. The key for enabling this is to go from remote to local by way of optimization instead of trying to go from local to remote by way of generalization. See this classic paper for a detailed discussion on why the second approach is bound to fail."
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.
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
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.
This is more of an object orientation thing rather than actor thing but would have huge implications for actor core VI, or Receive Message VI. Please add pattern matching into OO LV. It could look like a case structure adapting to a class hierarchy on case selector and doing the type casting to the specific class inside the case structure. You could have dynamic, class based behavior without creating dynamic dispatch VIs, and you would still keep everything type safe. https://docs.scala-lang.org/tour/pattern-matching.html
Interface based messaging. The need to create messages for all communication is a major decrease in productivity and speed of actor programming. It also decreases readability. It is a better with the BD Preview in Choose Implementation Dialog in LV19, but still.
Please include into AF: Certain templates, standard actors, HALs, MALs should be part of the framework e.g. TDMS Logger Actor, DAQmx Actor. Right now the framework feels naked when you start with it, and substantial effort is required to prepare it for real application development. The fact that standard solutions would not be perfect for everyone should not prevent us from providing them, because still 80% of programmers will benefit.
LabVIEW AF is a fantastic tool to create multi-threaded messaging applications the right way. It promotes best practices and help write big yet scalable applications.
I feel however that there is not enough included in the box 🙂 When looking at many other industry implementation of the actor model e.g. Scala Akka, Erlang, Elixir, microservices in many languages etc. you find that the frameworks usually include many more features. https://getakka.net/
I understand the decisions behind the design for AF yet would like to start a discussion about some of these.
I would like to see the following features being included into AF: 1. Ability to Get Actor Enqueuer by Path through hierarchy of actors e.g. /root/pactor/chactor could be used to get the enqueuer to chactor. This would probably require actors to have unique paths pointing to them. Having a system manager keeping all enqueuers on local system is not a bad thing. It is a good thing.
2. Ability to seamlessly communicate over the network and create your own queue specifications. For example actors should be able to talk between physical systems. Using the Network Actor is not a good solution, because it is simply to verbose and difficult to understand. The philosophy of AKKA should be embraced here "This effort has been undertaken to ensure that all functions are available equally when running within a single process or on a cluster of hundreds of machines. The key for enabling this is to go from remote to local by way of optimization instead of trying to go from local to remote by way of generalization. See this classic paper for a detailed discussion on why the second approach is bound to fail."
5. Certain templates, standard actors, HALs, MALs should be part of the framework e.g. TDMS Logger Actor, DAQmx Actor. Right now the framework feels naked when you start with it, and substantial effort is required to prepare it for real application development. The fact that standard solutions would not be perfect for everyone should not prevent us from providing them, because still 80% of programmers will benefit.
6. Interface based messaging. The need to create messages for all communication is a major decrease in productivity and speed of actor programming. It also decreases readability. It is a better with the BD Preview in Choose Implementation Dialog in LV19, but still 🙂
7. This is more of an object orientation thing rather than actor thing but would have huge implications for actor core VI, or Receive Message VI. Please add pattern matching into OO LV. It could look like a case structure adapting to a class hierarchy on case selector and doing the type casting to the specific class inside the case structure. You could have dynamic, class based behavior without creating dynamic dispatch VIs, and you would still keep everything type safe. https://docs.scala-lang.org/tour/pattern-matching.html
The natural way for programming languages to evolve is to take ideas from the community and build them into the language. This needs to also become the LabVIEW way. I saw a demo of features of LV20 and I am really happy to see that many new features were inspired by the community. Lets take some ideas about actor and add them in.
I wanted to share my view on the direction I think AF should go. I see in it the potential to become the standard way to do big applications, but for that we need to minimize the barrier to entry.