LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Currently, the Deploy Library Invoke Node and DSC Deploy Libraries vi will only work with bound libraries that have a PSP based URL. (\\192.168.0.2\process\variable) But there are some use cases where you need to have logical URL's (\\cRIO1\process\variable) that will adapt to changes in the .alias file which maps target names to IP addresses. If this is your use case then it is tedious to do the same thing programmatically since you will have to create your bound libraries with an initial default PSP URL and then programatically modify all URL's based on a 'designated' target IP. Since the project can do this I assume that it should be relatively easy to provide this functionality.

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.

View All (2)

The Labview Web Services should support digest access authentication (RFC 2617) in stead of NI's own inventions NI Auth and NI API Key (the latter is broken in 10.0f2). Digest access authentication is becoming a standard and is intended to replace basic access authentication since it doesn't send passwords in plain text over the web. It is very useful for cases where HTTPS cannot be used, for example for performance or legal reasons.

Digest access authentication does not require Silverlight at the client side like NI Auth does - it requires only a recent browser. In this way the choice of HTTP clients is much less restricted and for example a cell phone can be used too.

It shouldn't be that difficult for NI to get this done, the webserver behind it already supports it. Of course the Labview HTTP Client should also support digest authentication.

Shared Variable - Round to...

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

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.

View All (6)

Currently, if you want to programmatically bind HMI controls and indicators to network URL's you need to first set, at edit time, a fake

URL (example: \\192.168.0.3\cRIO-HPU\'PU.Accumulator_Dump_Valve') since the actual IP address may not be known at edit time.

If you leave the HMI 'unbinded' then the attempt to set the BindingPath properties will result in an error.

It would be nice if you had a generic option called 'late binding' that you could select with the expectation that the exact URL will be set

at runtime. This would provide an additional benefit where the PSP driver could wait for a BindingPath to be set before attempting

the first transaction.

The Vision Acquisition Software seems to send all GigE attributes to the camera that have been set in the camera file. There should be an option to select which attributes are sent to the camera when connecting. This would allow the settings configured through vendor specific third party tools to persist when acquiring in MAX or LabVIEW.

This could possibly also alleviate the "Attribute value is out of range" error if MAX is only sending the attributes you specify.

View All (11)

Almost all LabVIEW data types can currently be sent through a shared variable without any hassle. The notable exceptions are native LabVIEW classes, which cannot be selected as the data type for a shared variable. This causes a problem for anyone who wishes to send objects across a network. They are forced to rethink their use of LabVIEW classes, use a communication method other than shared variables, or flatten and unflatten the object on either side of the shared variable communication. The use of classes is growing more common with every version of LabVIEW, so I think it is time for these two prominent LabVIEW features to work together seamlessly.

View All (2)

Possible scenarios:

A) You right-click in your project and instead of adding a new target e.g...you can add a data source. This data source could be a web service, an XML file (eithe local or at a http address...), an ODBC database, a modbus TCP/IP register etc. etc. You can now access the data from this by dragging the source icon in the projects list onto your block diagram. This would give you a reference and polymorph accessor VIs.

B) You drop a data source express VI onto the diagram and it pops up with a dialog that allows you to select the type of source.

C) Perhaps we could even integrate this even more; if I right click on a table e.g. I can choose to link it to a data source - and have a wide variety of sources to choose from. Yes, we already have the shared variable or data socket based data binding option, but we should be able to bind it to lots of different, open and industry standard sources.

Mads

Full XML support

In Visual Studio you have XML Schema tools etc. It is a breeze to e.g. populate a drop down menu based on XML from a web service, and my first thought when I see it in action is - why do we not have this at our fingertips in LabVIEW already? LabVIEW could have made it simple to create schemas, generate flexible XML etc. You could have wizards that helped you, and cluster to xml conversion like in EasyXML from JKI - and it should all feel fully integrated (toolkits are OK, but this really needs to have native support).

I am currently developing a web service in LabVIEW and the first thing I had to do was to abandon the few in-built XML functions and write my own serialization code (using terminal mode for the web service gave you XML without proper headers, and the in-built flatten to XML outputs XML is impractical in use). Once I have serialized a text table e.g. and published it - using that table feels incredibly easy in Visual Studio (add data source-> input web address etc.) , it would be much more difficult to do the same in LV.

I think NI should make a big leap in the use of web technology. The RESTful web service functionality was a great addition, but the doumentation is non-existing, and we should have come much further by now. I know there are some cool experiments going on with web based GUI editors, but LabVIEW 2010 was just released with very little news on this front so forgive me if I rant a bit...

Most people know that Network Published Shared variables are pretty slow. If you write to a SV and then immediately read from it, you probably will not see the new updated value. One way to get around this is to write the value and then continuously read and compare the SV until the value is updated:

Pretty straightforward to do, but takes time to set up, as well as some Block Diagram real estate.

I think it would be pretty convenient (and easy for NI to implement) if there was an option for a SV to wait until updated.

It could either be an option from the right click menu, (that of course would update the icon to signify that it's now a blocking call) or use an input to the variable, or maybe a combination of both:

This is a bit esoteric but for those who use the DSC toolkit to read trace data from a Citadel DB you will find that you cannot always obtain the most current value

of a trace. Here is the text describing what a ghost point is:

Citadel uses ghost points to maintain real-time awareness of traces that do not change frequently.

For example, suppose you configure a thermocouple measurement for logging with a deadband of 1°F. The thermocouple is in an environment that remains at a constant temperature most of the time, but you need to know when any major changes occur. If the temperature remains within 1°F for one hour, Citadel does not log redundant points, even if the temperature is sampled once every five seconds. However, if the logging system experiences a failure at some point during the sampling, you want to know the temperature at the time of the system failure. You also want to know the approximate time of the failure. Citadel handles this situation by logging a single ghost point for each trace. The ghost point in each trace updates constantly at a rate based on the time group specified for the trace. The ghost point always reflects the most recent time and value of a trace.

Citadel stores ghost points in a .tgpffile that updates once every ten seconds. This file ensures that Citadel has an accurate record of the value for every trace at the time of a system failure.

It would be very useful to be able to specify in the trace read vi that you would like it to return the ghost data points. Otherwise, it is very cumbersome to try to detect if you are missing this data point and then have to programmatically read it yourself from the originating data system.

dsc

View All (2)

Native SSH and SFTP Support

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.

View All (9)

View All (2)

Change CRLF Mode on TCP/IP Read

It would be nice to see a string terminal added to the TCP/IP function so that you could choose which character set you would like the TCP/IP read to look for before ending its read. Then instead of having the CRLF mode it would be called Character Search or something that would appropriately fit. I have run into this being an issue when I have used a serial to TCP/IP converter because not all serial equipment sends a CRLF character such as Alicat Scientific Flow Meters and Controllers. This came about because the converter does not buffer the data once a TCP/IP command is sent making it hard to build a loop that builds up a string of data one character at a time by setting the read byte count to one then looking for the control character and ending the loop when it is found. This is because once a single byte read command is issued the device releases it's entire buffer and every thing after the first byte of data is lost. Perhaps I have overlooked something. If I have please do not hesitate to let me know.

I suggest that the LabVIEW application builder should include an option to rename shared variable libraries (i.e., add an index to the existing name) when building an application. This is necessary for replicating an application.

For instance, for a component we developed we host shared variables on MyComputer (so that we can use DSC functionalities). Applications on MyComputer (the view) and on a cRIO (the controller) read and write the shared variable values.

Now we want to clone these applications so that we can run multiple instances of them. In particular, there will now be six instances of the cRIO application, each deployed on a separate cRIO; there will be six instances of the MyComputer application as well, but these will all run on the same PC. Currently we anticipate (we have not done this yet) that we will be able to create six build files, each pointing to a separate aliases files, in order to handle the fact that the cRIOs will have unique IP addresses. On the other hand, there is no way to handle building unique shared variable libraries in the application builder. At the moment we can edit the project manually by changing the library name (e.g., add ‘A’ to the prototype name), then building the application, and repeating the process six times. This is not especially difficult, but it is not a good long-term solution, since any change will require someone to repeat this process (and more importantly, know that they must do this!). I suggest this functionality should be part of the build specification itself.

View All (11)

Enhanced EPICS Support

Epics Support in LabVIEW 2009 DSC Module has increased usability of LabVIEW in EPICS environment very much! But:

1. Import of database file is not really working!

When creating Epics client IO Server there is this nice feature to <Import> records from database file.

But when doing this there is only on field "VAL" per record created. All the other fields must be added manually though they are defined in the db file.

So please let the import routine pay attention to all the fields that are defined for each record by default and perhaps make it selectable.

This little change shouldn't be a big issue I guess. And it would increase the usability a lot!

2. With DSC it is possible to create on runtime only server types Modbus/Modbus Slave/OPC Client.

Please add Epics Server & Client here.

The goal is to be able DURING RUNTIME to first create sets of Env.Vaiables dynamically (already working with DSC) and then create the network publishing EPICS server.

And of course the other way round: Please let me be able to create an EPICS client by importing a db (dbd) file dynamically and then bind it to dynamically created set of env. variables.

From what I heard from many of our synchrotron customers LabVIEW still has not arrived in this (huge!) EPICS community.

I think it is on a good way with LV 2009 DSC Module. Please let it keep on going!

View All (1)

When using the LabVIEW Internet Toolkit FTP library to transfer large files, there is no way to determine the progress.

I propose a notifier be added to the FTP Registry object data. This notifier would be updated by the low level TCP Read Stream and TCP Write Stream vis and monitored by a UI to display progress of the transfer.

See this NI Forum post...

FTP transfer progress bar

http://forums.ni.com/ni/board/message?board.id=170&message.id=470946

LabVIEW Idea Exchange

Allow Deploy Libraries Invoke node to work with project based bound libraries

Run Method should not run in the user interface thread

Digest access authentication support in Application Web Server and HTTP Client

Shared Variable - Round to...

Better Support for Encryption/compression.

Implement More than 14 User Ideas in the Next Version of Labview

Allow Selection of 'Late' Network binding for HMI controls and indicators

Specify Attributes to send to GigE Vision Camera from MAX

Shared Variables should support LVOOP as a data type

"Data Source" as addable item in projects, or as an Express VI

Full XML support

Shared Variables: Wait until updated for write

Provide LabVIEW or DSC access to citadel ghost points

dsc

Native SSH and SFTP Support

Installer for Labview Web server browser ... light Labview Web client installer

Change CRLF Mode on TCP/IP Read

Include ability to rename shared variable libraries as part of build specification

Enhanced EPICS Support

Add progress functionality to Internet Toolkit FTP library