Benchtop Measurement and Test
Distributed Measurement and Control
Systems Engineering Software
You can request repair, RMA, schedule calibration, or get technical support. A valid service agreement may be required.
Provides support for NI data acquisition and signal conditioning devices.
Provides support for Ethernet, GPIB, serial, USB, and other types of instruments.
Provides support for NI GPIB controllers and NI embedded controllers with GPIB ports.
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.
A C# library (SSH.NET) was developed and improved over the past few years, and this guy (GregPayne) recently took that .Net library and from it created a limited functionality LabVIEW library that wraps the .Net assemblies.
SSH with LabVIEW
I didn't get it working with Putty so now we have rebuilt the SW in C# and Visual basic that have some kind of support.
This comment thread is six years old, and still no native SSH, SCP, or SFTP support! There's some third party app that costs $500 bucks, and I hate to be cynical, but how much do they kick back to NI on each sale?
SSH is extremely useful for automated testing; not only do we need to control the test equipment, but we need to communicate with and control the DUT, which very often is an embedded system of some sort, and SSH/SCP/SFTP is the only manner of I/O to it. Please, please implement this! LabVIEW costs $5k for the professional system, I don't want to have to pay someone else an extra $500 bucks just to use something that I can do on the Mac terminal with one line of input.
If you need it, then be sure to click the star at the top of the message to give the idea a Kudo.
Oh, I did. I think the only way this gets done is if a big corporate buyer says they need it, and they won't buy dozens of licenses unless it's included.
And, after all this time....
Not a peep from NI regarding the status of this request; declined, under consideration, in development, etc. When a third party has developed a tool, inferior at best, and NI doesn't want to ruffle feathers they just ignore the idea/request from users.
This SSH/SFTP toolkit should be developed by NI from the ground up to include support for Linux RT targets.
I find it amazing that there is still no native support for SSH/SSL. I'm about to have to use PLink because there is no other choice. Even users in large corporations suffer the pain of this absurd gap in what has been evolving steadily to a "real" programming language. Lacking native SSL support is truly deplorable and provincial.
The real problem here is that SSH/SSL require encryption algorithms. To get your encryption code certified is EXPENSIVE. You expect NI to just eat that cost? I have heard that NI has no interest in investing in encryption for reasons like this. The only way I could see a chance of this happening is if they open up the Linux cRIO platform more to use the SSH command line (you can already do a lot with it, just not publicized much) and it somehow leads for more hardware sales.
I personally have ideas for making an SSH library using the .NET encryption libraries. That would only be useful for Windows systems, but that would not hurt my situation. Now I just need to find some free time to write that library. My current solution is using the SSH.NET linked to earlier, which is poorly documented and will crash LabVIEW if errors are not handled correctly.
crossrulz: Yes, I do expect NI to eat the cost of developing their SSL/SSH code. NI is not some tiny non-profit operation, they are a very profitable company and LabVIEW is their flagship product. "EXPENSIVE" to you and I is really peanuts to a company like NI, I am honestly very put off by their continuing to ignore developing this incredibly relevant interface code. So, yeah, they'll have to pay for developing that code, that is part of the cost of wanting to provide a closed-source language. Not providing it is truly negligent and I've not heard a good reason for them not doing so.
Single platform solutions (such as relying on the .NET libraries) are not good answers.
Me Too!! What Carlos said.
Yes, I still expect and expect years ago that NI would have invested in and developed a platform independent solution for this issue long ago. This is a huge gap in the platform that is not currently completely filled by any 3rd party solution.
And, after more than 7 years since the original post for the status to still be "new" and absolutely no official response from NI is what's really shameful. The status should be changed to "declined" since NI has apparently made that decision. NI should be honest; change the status and provide the details behind the decision.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
What do you need our team of experts to assist you with?
We'll be in touch soon!