LabVIEW Idea Exchange

Community Browser
About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW 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!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Authors
cancel
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!

Post an idea

NXG needs an Idea Exchange.  The feedback button is a lame excuse for a replacement.  Why?

 

  • I can't tell if my idea has been suggested before.  (And maybe someone else's suggestion is BETTER and I want to sign onto it, instead.)
  • NI has to slog through bunches of similar feedback submissions to determine whether or not they are the same thing.
  • Many ideas start out as unfocused concepts that are honed razor sharp by the community.
  • This is an open loop feedback system.

Let's make an Idea Exchange for NXG!

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.

 

PrimaryKey_0-1573820513072.png

For community solution and examples of these features please go to -> https://forums.ni.com/t5/LabVIEW-APIs-Discussions/Tree-Map/td-p/3972244

 

This could include also Pretty JSON since XML and JSON are interchangeable -> http://www.utilities-online.info/xmltojson/#.Xc6XjVdKiUk

 

Additionally the XML parsing should be implemented without requiring Windows .NET platform components, so it can be done on a real-time system. Current XML parsing functions cannot be called on RT.

 

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! Smiley LOL

Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data. Like XML or JSON but smaller, faster, and simpler.

LabVIEW already has XML & JSON functions, why not ProtoBuf?  It is the default mechanism for serializing structured data used by gRPC.

If LabVIEW users want to create gRPC microservices, then LabVIEW needs to support ProtoBufs.

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!)

LabVIEW needs native SSH and SFTP connection support. 

 

In the past, LabVIEW users have had to rely on third party applications like PuTTY or ExtraPuTTY to do very basic Linux/Unix secure shell operationsNot only does it add an extra layer of complexity to the code but it is also quite inflexibleIncreasing interoperability requirements of present day (and future) computer systems rely heavily on terminal services with a vast percentage of those being SSH basedIn the past 5 years I have needed to use SSH type connections more and more inside of LabVIEW, I do not see it ending anytime soon and I know I am not alone.

 

An SSH connection could be managed in much the same manor as the current VISA and TelNet connection are managedAn example of some of the tools could look something like the below image and could come standard or part of the Internet Connectivity Toolkit.

 

2010-06-03_LVIE_SSH.png

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. 

 

New javascript/ecmascript engines that are much faster, and make use of multicore environments have arrived and work well.  The addiition of WebSockets means your browser can now open a tcp/ip socket.  I have done this, as I am sure others have, as well.  Drop an old-fashioned tcp/ip listener into your diagram, return the WebSocket handshake, and presto: you can now stream data directly to/from your browser.  WebSockets provides an "onmessage" event handler function which you can define.  Combine this with the SVG DOM, and you can transform SVG elements until your heart is content.  Two-way streaming of data between your browser and plain-old tcp/ip?  Goodbye web services, we knew you well. Good riddance, plugins.

 

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. 

 

Screenshot_5.png

 

 

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:

 

 

Screenshot_7.png

 

 

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

 

With the IPv4 address pool quickly getting used up I think we need to have native support for IPv6 connections in LabVIEW.

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.

 

A cross origin request is any request where an application running on one domain needs to make a request to another domain. For example, if there was a javascript application running on the domain www.labview.com and it needed to make a AJAX request to api.labview.com, the browser considers this a cross origin request. This is a common setup when the thin client is being hosted by one server, and the webservice is being hosted by another server. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

 

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.

 

1. Windows PC. This is the central server for the application. There will be a normal LabVIEW application running on this computer. There will also be a web service run on this computer. The web service will mainly host a web application written using HTML/CSS/Javascript (although it could be written using HTML vis from NXG).

 

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.

 

Now a user uses their web browser to access to the windows PC. The Javascript Application (which is hosted on the Windows web service) provides the user with a list of all commissioned CRIOs. They then click on one and the javascript application starts to make requests directly to the CRIO's web service. Since these CRIO's are on a separate IP address, the browser flags this as a CORS request. This means that an OPTIONS request can be sent. Since I can't handle an OPTIONS request in a LabVIEW web service, I can't implement this.

 

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.

The current implementation for remote debugging needs two ports to be opened on a stand-alone firewall in between.

  • Port 3580 to connect to the NI service locator on the target machine
  • A random port for the application on the target to connect to
    This port is dynamically assigned to the application by asking the OS for a free one

 

This dynamic port cannot be pre-configured on the stand-alone firewall except by opening up the whole port rang above 1024.

The latter is something no IT person with any sense of security will do !

 

So we need to be able to pre-configure a certain port for the target application, so that we can open a dedicated port for this connection on the firewall as well.

Otherwise this whole remote debugging feature is useless to many companies.

 

There have been multiple cases in the last few years where customers (huge ones) have come across this issue. 

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

Please add to AF:

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."

3. Improved debugging features like MGI Monitored Actor being inbuilt. https://www.mooregoodideas.com/actor-framework/monitored-actor/monitored-actor-2-0/

4. Included Subscriber Publisher communication scheme as a standard way for communicating outside the tree hierarchy. https://forums.ni.com/t5/Actor-Framework-Documents/Event-Source-Actor-Package/ta-p/3538542?profile.language=en&fbclid=IwAR3ajPR1lvFDyPFP_aRqFZzxR4FCQXh2nB2z0LYmPRQlnvXnsC_GQaWuZQk

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.

According to the increasing number of questions about this communication protocol, it would be time to rewrite the MODBUS library. I also suggest to add it to the NI device drivers installer.

 

This could be the place to list the expected modifications. Some comments and bugs are already listed in above linked page.