LabVIEW Idea Exchange

Community Browser
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

For topics outside or perhaps off-topic from technical sessions, summits, keynotes. A way to enable "flash crowds" on topics of mutual interest. For those passionate about particular topic areas, but requiring dialogue, not just presentation.

 

Requirements:

(1) Mechanism for identifying BOFs

(2) Provision or selection of moderator

(3) Allocation of meeting space, time

(4) Place for posting schedule visibly for conference attendees

 

(Perhaps just me, but gathering at a topic table over lunch didn't work so well. Time already slotted for coordinating with my colleagues. Topics limited to number of tables allocated.)

 

Perhaps take a moment of keynote time while everyone's in the room to vet hot-topics.

Or arrange for selected BOFs beforehand based on hot topic areas of the forums.

Otherwise enable write-ins on physical bulletin boards or electronic social network nodes.

 

Saw the idea work very well at Colorado Software Summit Java conference convoked by Wayne Kovsky. He would be the ideal consultant for mechanics suggestions: http://www.linkedin.com/groups?viewMemberFeed=&gid=1083347&memberID=4008329&goback=%2Eanb_1083347_*2%2Egmp_1083347.

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.

Hi all,

 

wouldn't it be great if LV would be capable of VPN (Virtual Private Network). This would make tunneling connections into internal company networks much easier, without the need of a further software program establishing the IP tunnel.

If you think this is a great idea, please give Kudos.

 

Regards,

Torben

Currently, the NI real time devices use FTP for programming and configuration. Services such as telent and FTP are not encrypted and can pose a potential security risk, and are not approved by some IT departments.

 

I suggest a feature for the real-time operating system to have an administrator selectable option to use SSH/sFTP for programming and configuration instead of FTP.

Hello,

We all have mobile phones that can communicate with PC easily and also almost all have embedded Bluetooth.

So if a PC don't have Bluetooth, can we utilize Bluetooth of a mobile phone to communicate through LabVIEW to another point.

At present, we can add users and permissions to NI auth in the system web server, but we cannot add groups.

groups.png

There is no particular reason for this, as the help clearly implies that there should be a way to add groups:

feedback.png

If you ever want to add users that have more than four sets of permissions, you will start having to manually adjust those settings, which shouldn't be the case. We should be able to add groups, to prevent just this issue.

 

Right now, we can use the mass front panel binding tool to bind front panel items to shared variables--but we must have the shared variables in place already:

1.png

We can make a mass of variables using the batch variable creator, but they must be of the same type, and the name is not descriptive (Variable 0, 1, 2, 3...). You can also convert single controls or indicators into shared variables...

2.png

But every time you create one, it also creates an entirely new library, and you cant create multiple shared variables at once.

 

My suggestion is to let you create shared variables from the binding pages (both individual and mass):

3.png

 

I would also like to be able to drag controls from the front panel into your project to automatically create a shared variable to which they are bound (just as you can now drag shared variables onto your front panel to make a bound control).

Hello,

 

I have a current need to be able to SSH to a "black box" Labview doesnt seem to have any support or any precanned vi's to be able to do this in a reasonably simple fashion. Maybe create a open, read, write, close for those of us who need to ssh. Thanks for your help and time.

Currently the "Bytes at port" property only applies to serial ports. If you are trying to write a generic driver or communications package that supports multiple connection types you cannot use the "bytes at port" since it will not work for anything but a serial connection. There is a related idea here which proposes the "Bytes at port" can be added to the event structure. It also suggests that this be expanded to other connection types. My idea suggests that at a minimum the VISA property node can be expanded.

LabVIEW will always use the primary NIC if more than one NIC is present. It would be nice if the user could select which NIC to use programmatically and not need to worry about defining routes on the computer.

I would like to be able to obtain the IP Address of an application instance.

AppRef-returnIPaddress.PNG

 

 

Here is one scenario:

 

Plug in architecture.

Host machine loads plugin VIs that monitor several targets via VI Server.

The main VI opens the connection to one of the targets' application and sends the application reference to the plugin so this VI knows what target is communicating with.  

 

It would be nice to be able to obtain the IP address from the Application Reference via a VI or a property node. 

 

Now, I know I could be sending the IP Address instead of the application reference, but if I know I am going to be calling several VIs in the same target, why do I need to open an application reference for each VI, when all could share the same application reference.

 

Another scnerario for this was posted here: http://lavag.org/topic/6861-address-of-an-application-instance/

 

 

I would like to see new Read and Write VIs for TCP and UDP connections that worked the same way the Read From Binary File and Write To Binary File work. These file VIs are polymorphic and allow you to specify the format of the data being written or read. With only the current Read and Write VIs available for the TCP and UDP connections we must always include typecasts or other data parsing. LabVIEW obviously has the means to do this since it exists for files. Extend that capability to the newtrok connections as well.

It would be helpful if we could create raw IP sockets in order to have access to protocols other than TCP and UDP. This would open the door for LabVIEW to be used for general network testing. I would be fine if this extension meant the programmer was responsible for implementing the protocols. Simply having access to a raw IP socket would be a benefit.

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

I would like to see the functionality of the TCP and UDP primitives expanded to include more state information, better control of the connections and the capability to receive events for the connection.

 

Items that I can see which would be helpful would include the following:

  1. Ability to enable/disable the Nagling algorithm.
  2. Ability to abort a TCP connection with a TCP-RST. (The wire is there on the TCP-Close primitive but it doesn't do anything)
  3. Ability to receive an event when data is present.
  4. Ability to receive an event when the data has actually be put on the wire. (Currently the write VIs return as soon as the data is buffered. There is no ability to have the application wait until the data is actually delivered.)
  5. More access to the IOCTLs that are available on a socket connection that a programmer has access to via Linux or Windows socket libraries.

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.

 

Give LabVIEW full parity with the CVI 'Network Variables' API.

CVI has many useful API functions such as adding a NSV to a existing deployed process

or registering for SV change events that are impossible in LabVIEW.

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.

 

Can we please have some official examples for the HTTP Client VIs under Data Communication > Protocols?  There are currently none available.  Thanks.

My idea is to enable access logging for the Application Web Server.

 

In this way access to a web service can be analyzed which is also useful in debugging timing or performance problems of your application. To facilitate easy analysis, industry standards like the "common log format" or "combined log format" (link) should be used, then analyzer tools like AWStats can be used. The Appweb Embedded Web Server, which is the core of the Application web server, does already support logging so getting this running should be easy.