LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

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 have been recently asked by NI to answer a poll about what feature I would like to see as far as data management and access and at that time, I didn't really think about mentioning something which is dearly missing in LabVIEW: cloud storage access.

The reason for this request is that increasingly, files used by collaborations cannot always be copied locally (for instance due to their size or because of frequent updates), or managing local copies and updating the central cloud repository is getting prohibitively time consuming and cumbersome.

There exist a few attempts in this direction (e.g. GDrive for LabVIEW, a third party skeleton of a toolkit to access Google Drive, or LabVIEW Interface for Amazon S3), but there are some glaring absent ones such as Dropbox, OneDrive, Box or iCloud to name the most popular ones.

As I mentioned before, GDrive is a starting point but is missing some basic features such as folder list, comments, etc.

I cannot comment on Amazon S3, as I don't use it.

Obviously, there is no way to predict which cloud storage solution will disappear in a few years from now or which one will pop-up tomorrow and become popular, but most of the work has been done by those vendors, who provide .NET API for their cloud solutions (maybe not Apple) or at the very least a RESTful API. These APIs could of course be made community projects (like GDrive is to some extent), but their importance would seem to justify a minimal investment from NI.

View All (1)

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

More robust & powerful SMTP library

The NI SMTP library is good at making e-mailing simple. But now and then I will get error 363513 (an error occurred on the network).

There are multiple known causes for this error that one can prevent, but also some unknown. The error does not specify them. I am therefore still struggling to get my e-mailing routines impervious to this error. The library should return more specific errors.

There are multiple other known issues with this library, making it quite unreliable for automation purposes. A shame, as there are few alternatives available.

A few suggested VIs for beefing up this library could be:

check if server is online
set popular SMTP header values (I don't know them, like most of us I assume)
check if e-mail was successfully sent to recipients
meta data returned: unknown recipient, attachment size exceeds limit of xMB etc

View All (3)

FTP Improvement

I would like to suggest that NI add some needed functionality to the FTP VI's that it ships with. As you can see in this thread: http://forums.ni.com/t5/LabVIEW/Access-FTP-with-whitespaces-in-dir-names/m-p/3097215#M886371 the FTP LIST command does not work well for some FTP servers when the directory being listed has spaces in its name. The FTP MLSD command does work in this case, but there are other servers which don't support MLSD. My post on the above thread implements a fairly crude mechanism for using whichever command does work. But more importantly, the MLSD isn't even included in the NI FTP library. It would be great if the NI FTP VIs worked over a broader range of FTP servers.

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

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

Currently the native (by which I mean noncustom) numeric data types for shared variables are pure numbers (i.e., without units). It is simple enough to add units to, say, a DBL numeric control and define this as a custom type, but the DSC module does not support value-based alarming for custom types.

Since

1) we would like to support value-based alarming AND units

and

2) I suggest this is (or should be) a very common use case

I propose that LabVIEW have numeric types with units as native shared variable data types.

I suggest that using units for engineering applications would be both more convenient and safer.

I also think this would be quite simple to implement. The only question is on which unit to do the value-based alarming. (Likely this would be on the SI unit on the wire.)

I have attached a very simple example that shows the current state of things.

View All (8)

View All (1)

If you develop an application using functionality from the OPC UA Toolkit on a machine with a developer license covering the OPC UA toolkit you cannot run the built application to test if it works without having to buy a deployment license for that machine.

Having a developer licens on a machine should allow us to run built applications as well the same machine to verify the functionality after build (alternatively the developer seat should always be accompanied by a deployment license).

View All (4)

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.

View All (1)

View All (2)

From:

https://forums.ni.com/t5/LabVIEW/possible-to-change-opc-ua-alarm-limits-at-runtime/m-p/3688481

The request is mostly in the title. Right now it seems as though changing an alarm limit requires stopping the OPC UA server. It seems reasonable to expect that users may wish to adjust alarm limits on the fly -- for my use case, tuning the system during a long commissioning process. It might be many months before a system is fully ready to go, and during that time alarm limits change regularly and we still want to report alarms to operators during this period.

Telnet Support

Keep supporting NI-CAN

Today I discovered NI has discontinued support for NI-CAN hardware (not XNET) beyond LabVIEW 2015SP1. If you want to use your code with NI-CAN hardware and LabVIEW 2016 and beyond, you are out of luck unless you have the cash to buy XNET replacements and want to rewrite your code for the XNET API.

I have a very large J1939 simulation/monitor application I wrote and have supported for the past 8 years that is used on several lab benches and by numerous software developers across the country. Now, we stuck with LV2015SP1 forever unless we can find a large amount of cash to replace all the NI-CAN hardware, which isn't going to happen anytime soon.

So, my idea is for NI to keep supporting NI-CAN in current and future versions of LabVIEW

View All (1)

HTTP Client Examples

Having sold applications that use functionality from the OPC UA Toolkit we run into an issue if we upgrade our LabVIEW version and continue to develop those applications beceause the OPC UA deployment license will then stop working if we upgrade the software we have delivered to them to one developed in a newer version. So, even though the customer has an OPC UA deployment license and we have an updated developer license it is not enough because the deployment licenses have to be updated as well (and it does not help that deployment licenses are not something we can bunde with the upgrade of the software either). From what I understand new deployment licenses will not actually cost anything, they are provided by NI as long as you already had a deplyment license for the previous version - but the logistics of this is a nightmare for us. Instead of just delivering a new installer with an updated version of our software we have to get involved in upgrading the dpeloyment license for all of their systems each time we have gone to a new version of LabVIEW.

View All (4)

Allow Custom Properties for VISA

So one can set many of the standard properties for VISA connections. However the serial port latency setting is not one of these. It can easily be set by a standard POSIX ioctl call for both linux and MacOS (who the heck knows how Windows does it). Many character based devices can be manipulated through these ioctl calls.

To be specific, the FTDI USB-Serial port driver chips used in MANY devices as a USB interface or just as a serial port have a slow default latency that is fine for preserving CPU cycles but not great for modern high speed custom communication.

1. Just add a a property that sets the serial port latency using an ioctl IOSSDATALAT property configuration.

2. More generally allow an interface that will call ioctl with a supplied property and the LV programmer can pass the correct property configuration.

3. Less satisfying but possibly easier to implement is to have the VISA property be the file descriptor number. This simplifies the programming where one has to now get the "Name" property and then search the process information table for that "Name" (or really path) and then extract the file descriptor. Only then can one set the latency for that device.

Add pattern matching to LV OOP

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

LabVIEW Idea Exchange

Change CRLF Mode on TCP/IP Read

Google Drive, Box, Dropbox, OneCloud, etc. Cloud Storage APIs

Improved debugging features like MGI Monitored Actor

Ability to seamlessly communicate over the network and create your own queue specifications.

More robust & powerful SMTP library

FTP Improvement

Support diagnostics on serial lines for Automotive Diagnostic Command Set.

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

Add numeric types with units as natively supported shared variable data types

Allow VISA to have a separate read and write timeout

OPC UA Toolkit deployment license should be included with developer license

Add better support for Tcp socket options

Add Train Real-time Data Protocol (TRDP)

allow editing of opc ua alarm limits without restarting the server

Telnet Support

Keep supporting NI-CAN

HTTP Client Examples

OPC UA deployment licenses should be version agnostic

Allow Custom Properties for VISA

Add pattern matching to LV OOP