LabVIEW Idea Exchange

I really like the option to use indicators (connected to the connector pane) as the output for webservice methods. By default, Labview will serialize it to JSON, but text and xml are also options. It works quite well and it saves a lot of coding writing your own serialisation.
I have some suggestions for the serialize functionality:

1. order the JSON output by tabbing order when there are multiple output indicators. This prevents that you end up always clustering all controls into one, just to enforce order.

2. it would be nice if an enum could be represented by its string instead of its index.

3. support for maps

Aren't you tired or seeing Labview, or LABview or LabView online?

NI Certifications (CLA, CLD, etc) should be stripped off people engage in miss-spelling LabVIEW.

And those who aren't certified should handwrite "LabVIEW stands for Laboratory Virtual Instrumentation Engineering Workbench" 10 thousand times!

Currently the only way to set/modify Tcp socket options is by directly calling some system library, as done for example in this post.

This not only causes code difficult to understand ("what does that library call do again?") but also poses problems when you want to use your code on different operating systems: Currently the only way to do this is using "conditional disable structures", and then Labview still tries to load the code used for a different operating system...

Labview should have a standard way to set socket options within Labview code, at least for the most important options (Nagle algorithm leaps to mind...). This could either be done as additional inputs to the "Tcp open connection"-VI, or (much better) using property nodes for Tcp connections.

By default, VI Server uses TCP to communicate between applications.  This stream of data is not encrypted and open to hacking and snooping.  

My suggestion is allow VI Server traffic to be encrypted, perhaps using SSL/TLS  or an AES algorithm.

The reasons are obvious.  There is an increasing number of cyber attacks in industrial control systems.  Many cyber attacks are perpetrated internally, so a firewall or air gap is only so helpful.  And in certain environments (ie military, medical) you can't even consider transmitting data without encryption.  This means VI Server is not an option for many users.

I see that LV2020 now supports SSL/TLS in its TCP functions (see here), so the logical next step would be to make use of this in VI Server also.

Report Writer BEFORE WIndows 10 was SUPER ROBUST! Now that Windows 10 came along there exist many "turds" left in the Registry when folks UPGRADE from Office 7 to Office 10.

What happens is the Registry NEVER NEEDED to be kept clean of extra junk because NOBODY EVER UPDATED Office.

Now every Joe on the planet updates their Windows 10 with the latest Office 10..

What happens if they do NOT FIRST UNINSTALL, is the Registry is left with "turds"

When Report Writer uses ActiveX to make calls to use Word, in the old days, there was a SINGLE key in the registry to allow the calling program to gracefully start Word or Excel, or whatever.

NOW< with Windows 10 there are FREQUENTLY multiple "keys" in a Registry that causxe the LabVIEW Report Writer to "Gag" and "Hang up" doing nothing.

The SOLUTION is for the Report Writer to PARSE the Registry for valid keys and allow the request to be passed to the propper called process.

If this is not clear, please look up the SR below. There are a TON of examples and videos explaining how to fix it.

I have been working with LV since Dr. G was roaming the halls on LV 3...

This is the FIRST TIME Report Writer has gotten "sick".

This is an EASY FIX for the devs and since Report Writer is a purchased plugin they sould be able to update it so it works well.

Currently, they have us fiddling with the Registry or telling customers to uninstall and reinstall Office. That is a BIG FAT NO-NO to big companies because Office WORKS COMPLETELY for them and even programs like SolidWorks and DXP that use Word and Excel for stuff.

My number 831-455-0418

DEVS:

Please see: Request #: 00994109] Can not get EXE BUilder to run on WIn 10

Working with XML is fairly common and an addition to the palette to replace a specific node value would be helpful. Besides, there's lots of space there yet.

This link saved time. Thank you to juliodia

for posting this.

https://forums.ni.com/t5/LabVIEW/XML-Update-Element-Text/td-p/1239026?profile.language=en&lang=en

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!

I know this was asked three years ago, but TRDP was fairly new back in 2017 and is becoming more in use in the rail industry.

As we are going to be moving away from Multifunction Vehicle Bus (MVB) networks over to TRDP, we need a solution to continue lab testing our software using LabView to simulate a vehicle interacting with a control unit using TRDP.

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.

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.

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.

The current way to bind many shared variables to an OPC client, is through browsing a tree and selecting.

This is very time consuming when you have hundrends or thousands of tags to bind. Specialy if the all the tags are not in the same path.

A better way, is to bind the variables, by simple text.

Example: We will insert the following text

A1M01Z1:value

A2M01Z1:value

A3M01Z1:value

and LabVIEW will automatically create 3 variables, bounding to those addresses (with the same name, prefered). Many OPC Servers supports this type of address.

Note that the true path of A1M01Z1 could be something very big, like:

My Computer\OPC ABB.lvlib\_OPC1\[Control Structure]\Root\NETWORK 1\Nodecm3\Extended Process Objects\MB300 AI\A1M01Z1\VALUE

This way you can add thousands of items in minutes. It is quite easy for the R&D team to implement and will help many professional engineers.

Most probably, this idea will not accept many kudos, but i think R&D must consider to implement this.

(this was discussed with NI technical suport, Reference#3279019)

Thank you all, for reading

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