LabVIEW Idea Exchange

Hello all, 

I have a suggestion about Automotive Diagnostic Command Set. It is currently designed for CAN-based diagnostics only and diagnostics on serial lines (K-line and L-line) are not in the scope of the Automotive Diagnostic Command Set.

I would like the Automotive Diagnostic Command Set to support diagnostics on serial lines (K-line and L-line) too. 

Automotive Diagnostic Command Set User Manual
http://www.ni.com/pdf/manuals/372139a.pdf

Best regards

Rutsu Kenmoku 

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.

We were thrilled to see that NI developed an OPC UA API. We develop software for both VxWorks and Windows, so having OPC UA available on RT is great. But having to shell out for the entire DSC suite, run-time licenses and all, just to be able to use the same API on Windows is unreasonably costly and forces us to use a different API on Windows. If we could buy the API as an isolated component at a more reasonable price (and with easier licensing) we would jump for it immediately.

A generalized version of the idea:

The DSC can still function as a nice bundle, where the price for the bundle is lower than the total for each individual item, but when NI makes such packages please make it possible to pick-and choose amongst those components as well, so that in cases where you actually have a need for just one of them, you can get it at a price that is reasonable for that individual component.

Hello,

I'd like to humbly and respectfully suggest that "Internecine Avoider.vi" be rewritten or at the very least, refactored extensively.  (again)

This VI is found in "TCP Listen.vi", which is on the TCP palette.  It maintains a registry of existing listener connections and attempts to reuse them.

What's the big deal, you ask?  Well, when I'm having problems with listeners and need to figure out what's going on, sometimes I need to look into this VI.  Like a lot of NI code that I generally trust, I would ordinarily skip over this and disregard it as a possible source of problems.  The trouble is, every time I look at it I can't easily decipher the nuances of what it does, given its messiness.  Thus, though it may be perfectly functional, I don't trust it.

I realize the code could be a whole lot worse.  I also realize that someone has been in there since LabVIEW 2011 was released and has made some improvements.    Kudos to that individual for all the new free label comments.

Nonetheless, here are some factors that obfuscate this VI:

1. There is no documentation under "VI Properties".  What does it do, at a glance?  (I know the answer because I've stared at it over a few versions of LabVIEW)
2. "TCP Listen Internal List.vi" also has no documentation under "VI Properties"
3. Without nitpicking, there are some sloppy practices employed in here that don't make a lot of functional sense.
4. Deprecated "Retrieve Element" case in the internal list VI.  "Item Requested" is no longer a requested item, but the result of a search on elements.
5. "net address" is confusing and ambiguous  Couldn't this be named, "Address of Listening NIC?" (Yes, I know it's documented under LabVIEW help for the TCP listener VI)
6. "Conflict" is ambiguous.  This should be renamed to something more intuitive like, "Conflict: Multiple NICs Using Port" or something similar.
7. Un-typedef'ed clusters in the internal list VI, with deceptive ordering of elements, combined with unnamed unbundler functions.

... etc.

I got to thinking... I know it works, or at least I think it does, but couldn't this be done more simply and elegantly?

I know, I know, "If it ain't broke, don't fix it."  ... but I think it could still use some work to make it more intelligible.

Respectfully,

Mr. Jim

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. 

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 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 operations.  Not only does it add an extra layer of complexity to the code but it is also quite inflexible.  Increasing interoperability requirements of present day (and future) computer systems rely heavily on terminal services with a vast percentage of those being SSH based.  In 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 managed.  An example of some of the tools could look something like the below image and could come standard or part of the Internet Connectivity Toolkit.

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

LabView has email capability but if you do not have a mail (POP or Exchange) server on your network, or like in my case use of the company exchange server is restricted to users with logins, but automated test machines and ATE system users are not granted logins, you can not send email using the LabView vi's.

Sure it can be done by getting a G-mail account and using the POP servers on G-mail through active-X but that is a lot of hoops to jump through just to send an email, and who knows how long G-mail is going to allow use of the POP servers.

It would be a lot simpler if LabView had a basic POP server vi that could directly send email with settable outgoing port just in case port 110 is blocked for some reason.

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.

When you are generating data from a source and sending it across a TCP connection, it would be useful to be able to get information about when packets are being dropped and resent in the connection. If lots of drops are being detected, a program might be able to slow down the data acquisition or take other action to reduce the amount of information being transmitted to account for the lower bandwidth connection. Currently there is no way to get this information from the TCP primitives.

This idea comes out of the Certified LabVIEW Architect Summit held yesterday and today at NI headquarters in Austin, TX.

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.

It would be nice if we had the option to terminate a TCP Read on a single character rather than only a CR/LF. There are many times where you would terminate a read on some end character such as a 0x03 (ETX). In order to accomplish this now we need to have a tight loop which reads from the connection a single byte at a time. Even better would be if we could specify a string as the termination sequence. However, I would be happy with a single character option.

When using the Sahred variable (SV) with "Bind to source", the SV uses the datatype of its source.

If you are using the datatype "double" you can see all fractional digits.

That doesn't make sense all the time - e.g. if you want to display temperature values.

Our idea is to give the user the opportunity of controlling the number of digit of precision.

Thanks

The Run Method is pretty much the only option we have in LabVIEW to scale an application dynamically by instantiating new VIs - but there is one big catch - for some reason it requires the unser interface to be idle(!).

Related methods like setting control values e.g. do not have this requirement so they do not pose a problem - but the main method for dynamic instantiation does - and can be blocked by something as simple as a user that opens the calendar view of a date and time control (which of course never should do this either, but that's another issue/idea).

Personally I use the run method to create new trend windows (you never know how many trends a user wants to see at the same time), create session handlers for remote clients etc. The times it is used to actually create user interfaces it is not a big problem that the run method is in the user interface thread, but for session handlers and other things that needs to be created in the background based on requests from the outside? A HUGE issue.

I am communicating to parker motor controllers through the Ethernet (parker sample code). Apparently since it is Ethernet based, the code uses socket, where the sockets require admin rights (another discussion about ethernet based and admin rights). In order for my VI to connect to the controller I need to run LabView as an administrator. The problem is I am making this program into an executable for production work.

When I create the executable it will not connect to the controller unless I am running the application as an administrator. As this program will be used in production I want it to be as simple as possible to perform. I don't think there is a simple way to change the environment to run without the need to run application as an admin. Are there any ideas to either change the executable to run as an administrator through the application builder? My plan is to create an installer through the application builder.

Some ideas that I had is to create an installer file and create the executable. Change the privilege level of the executable (properties>compatibility>privilege level>run this program as an administrator). Use a batch file to install drivers and application, then replace application with the one with the elevated privilege level. Another idea I had is use a batch file to do a runas command to run application as an admin. I cannot get either method to work. Does anyone have ideas?

I would like to see a tool in which you can actively see outgoing SQL queries as they are generated by the program.

While attempting to troubleshoot one of my programs in which I was pulling and updating data from a database, I had no way to confirm that the queries I was sending out had the correct syntax.  The error message I was receiving indicated there was a syntax error, but it was a little difficult to confirm where the issue was, or if really was a syntax issue at all.  Being able to see a string of the actual query would help a lot for troubleshooting programs that generate queries dynamically.