Plink/PuTTY works 30% of the time using System Exec.vi

[Viper]

---

@Viper wrote:

I think this SSH toolkit is the reason NI has failed to develop a native solution. They don't want to pull the rug out from under one of their developers. But $1552 when LV is 3K? Really? At $500 I'd pull the trigger.

---

They must have heard me current pricing is $499 or less. I had a need for ssh that plink just wasn't doing for me. So I took a second look at the toolkit. It's very well done. Well documented example and a help file. Most example code I see is some C coder slopping together an example that is hard to follow. Not these guys. They use best practice methods. I had what I needed following their example in less than 15 min. Even though they use a license the help file is great at showing what you need to do to build an application. Great integration of their license through their web site and email.

I highly reccomend them. Labwerx.net  And you can try it for free.

Norm

[carlos_camargo]

Since this is such a well developed package (I'm taking Viper's word for it, I haven't looked), NI should just buy it and be done with this problem.  It has been 11-15 years since SSH has been a widespread protocol, the idea has been on the NI suggestion board since 2006.  This is a truly garish and absurd oversight.  NI needs to quit adding corner functionality and get the solid/necessary stuff put in place.  Or open-source the  whole thing if they can't be bothered anymore.

[Hooovahh]

I also mentioned in that Idea Exchange that there is a free alternative from Labvolution that does SSH and SFTP.  I've only used the SFTP stuff but it seems well done enough.

[carlos_camargo]

Hooovahh, I had seen your link there, I for several reasons cannot stray outside the LabVIEW proper VIs.  So Labvolution is a non-starter for me.  The more I dwell on this, the less pleased I am at NI's dilettantism on this protocol.  It is amazing (and weird) too that they aren't even commenting on the topic.  Its like they just threw in the towel.  Lots of NI apologists though (no offense meant, just my observation) attempting to defend NI's indefensible lack of coverage of such a crucial protocol.

Is it really believable that both Labwerx and Labvolution arrived at a viable solution but a giant company like NI can't solve it, or can't be bothered to solve it?  Meantime they sink tons of resources into their nextgen product...

[Hooovahh]

I don't work for NI, I never have, and they don't need someone like me defending decisions that I don't have inside knowledge about...

That being said I can see a few reasons why NI might have less priority on this type of thing, but as I mentioned already I needed these tools and if there were 1st party tools I would be using them over the two already mentioned.

NI might not want to step on the toes of tools network partners like the two we mentioned already.  In the past NI has done things like release competing products to 3rd party things (like Unit Test Framework, Raspberry Pi, etc.) to which I've criticized them.  This criticism were directed more to the fact that future product plans aren't available, so 3rd party developers can't know if NI is working in parallel with a tool they are.  And less on the fact that NI saw a need for a tool and developed it in house, then released it.  The best case situation right now, is NI is talking with these two partners and communicating their plans for SSH/SFTP tools which may or may not involve acquiring IP.  These future plans, are things that NI might not want to share publicly yet.

Which brings me to point number two.  Some at NI have gotten into trouble for mentioning or showing future plans for things that didn't pan out, or didn't work the way it was intended.  Those at NI that show or talk about these new things might cause problems later on when features they promised (sometimes in specific versions of LabVIEW) don't happen.  As a result I think some at NI who know the answer to these questions, are holding back and wait for an official statement they can give, leaving us waiting...

One major counter point in my mind is that NI historically is about selling hardware.  That is where they make their money and their decisions on LabVIEW are some times focused on facilitating hardware sales.  When NI started selling cRIOs with Linux RT, they needed a better, more secure way to transfer files.  Which is why I think WebDav tools were available when they were in preparation for Linux RT.  What is surprising about this is these same cRIOs can be SSH'ed into, and that feature is mentioned quite often in sales/marketing and NI presentations on Linux RT.  Yet this feature doesn't exist natively...

We can speculate, but all that will do us any good is to complain to NI that these feature gaps are important to us, and to vote on the idea exchange.

[SimonAG]

---

Hooovahh wrote:

One major counter point in my mind is that NI historically is about selling hardware.  That is where they make their money and their decisions on LabVIEW are some times focused on facilitating hardware sales.

We can speculate, but all that will do us any good is to complain to NI that these feature gaps are important to us, and to vote on the idea exchange.

---

I think that NI using LabVIEW only as a HW sales tool is short sighted (if true, because I don't work there either.) I use their HW to test developing products. Just because most test HW doesn't need SSH doesn't mean that developers don't need to tie test HW with development products to automate testing. NI needs to support industry standard communication protocols.

Simon

[rolfk]

NI has only bought about two LabVIEW Toolkits so far and commercialized them themselves in over 30 years of LabVIEW history. The first was the Database Toolkit, which they completely redesigned after a few years and the other is the Vision library. They are certainly not going to bother about a package like SSH.

You may feel that it is the most important package in the world to have for LabVIEW programming, but reality is that I have in over 25 years of LabVIEW programming only once come across a project that potentially could have benefitted from a ready made SSH library. For NI something like SSH is a true niche project, that they wouldn't be able to make a paid toolkit from, so it would have to be an unsupported library or an integrated library in standard LabVIEW. However SSH and SFTP being cryptographic protocols there are many ramifications to be considered including export restrictions that any US company has to be worried about. But also the technical knowledge needed to not just create an interface that seems to work but something which also truly delivers on the secure aspect these protocols promis. And this is possibly even of more concern, because very few people really know enough to make such a product truly deliver, but it is terribly easy to make bad choices that completely dwarf the security aspect these protocols are supposed to have.

The most safe approach for NI is definitely to not consider such a Toolkit at all, and commercially it also makes sense as there is nothing to be earned by this. And it being security sensitive you only can fall short of expectations in this too, unless security related products are your core business.

If you blame NI for not supporting SSH in LabVIEW out of the box you should be screaming at Microsoft for not having a standard .Net Core library that supports this. And then you could simply access it through the LabVIEW built in .Net functionality. NI can't support everything themselves, even if they wanted, no matter what some might consider an absolutely unmissable functionality. That is also why they have Alliance Members which can deliver such solutions for customers who need it. And if that is to expensive you can always clap in your hands and start getting your hands greasy yourself. Complaining about missing functionality is easy. There will be always something to complain about.

[SimonAG]

I certainly didn't say it was the most important thing in the world; I'm fairly sure it isn't. My point was that NI needs to support industry standard interfaces of many stripes and varieties, not just those that are routinely used to control test equipment. This is because automated test software must connect to both the measurement devices and the test units to provide test results. One is useful, but connecting to both is truly a powerful automation package.

I understand you may not have had much use for SSH, but I and many of my colleagues use it every day. In any case, both of our experiences are anecdotal and don't constitute data.

Simon

[rolfk]

And if I had the need to use SSH I simply would have written my own LabVIEW library to do so, with a DLL taken from some open source project to do the nitty gritty low level stuff. If I would be complaining everytime I need some functionality that is not available in LabVIEW out of the box, my post count here would have easily reached the Knight level by now! 

[SimonAG]

From your replies I'm guessing your a software engineer so adding functionality by wrapping some .dlls is right in your bailiwick. I'm not. I pull LV out once or twice a year to enable testing that I have to perform on HW. 15 years or so ago, LV was about enabling engineers to perform testing and adding value to NI products. Over time it has become a much more capable software development tool, which is good, but its lack of support for industry standard communication protocols has degraded its value as a quick test development tool for me and many of the people I work with. If anything I'm whining about it moving away from being a tool I can easily use.

Which is my problem, but if I have to retrain myself every time I pull it out it may be of more use to me to use a competitor like python. How many of me are out there? Probably on NI knows.

Simon