NI can't get pLink (puTTY) data

[jamesS]

What I'm trying to do is read another computer's temperature sensors and using that information with the NI software on my laptop.

Sending/Receiving information via a plink (puTTY) client seemed like a reasonable approach to take.  From a puTTY VISTA cmd window I can login into the remote computer and read CPU sensor information and write fan speeds using CLI commands.

 

When I launch puTTY from NI, I get mixed results due to my lack of understanding of the SystemExec VI. With Guillermo's help and playing around with the example, I can exactly duplicate the operation of a cmd window. The problem lies in not being able to capture the data from the puTTY client because it opens it's own TTY window instead of using STDIN/STDOUT.  The LabView 8.6 examples all assume STDIN/STDOUT to use for data communication and parsing.  Sooo, I'm stuck with the ability to launch the puTTY client and connect to the remote host and not being able to programatically communicate with the remote host via LabView.

 

The local support guy and I played around with the TCP VI's (active.vi and passive.vi) but didn't know how to get that working.

 

What I REALLY need is some way to communicate over the network to a computer's interface via something like puTTY.  I've tried RAW, Telnet and SSH is the only one that worked, but still it doesn't use STDIN/STDOUT.  

 

Any help would greatly be appreciated.

james

[tbd]

Hi james,

      Are you are able to run a LabVIEW application on the machine with the temperature sensors(?) - do you have the "Application Builder"?  if so, then you could write a "server" application for that machine (without having to install LabVIEW there.)  Does the connection need to be secure?

If you're restricted to using the Putty interface, then please explain better "The problem lies in not being able to capture the data from the puTTY client because it opens it's own TTY window instead of using STDIN/STDOUT" - you're connecting using calls to System EXEC (?) - when/where is this new window opened?  Also, you may want to research ProComm or similar utility (some free)  - they can help automate the interactive parts.  I wrote some "drivers" for automating an "interactive" serial or telnet session, but nothing for Putty (though it sounds very similar.)

Cheers!

[jamesS]

As a last resort, I can install Labview on the machine with the temperature sensor if I can't accomplish my task over the network. I eventually will need it to work over the network, though not a hard requirement initially.  I am not restricted to using just puTTY either.  I can use any ssh or telnet client available.  Anything that uses STDIN/STDOUT.  To clarify my statement below, LabView calls puTTY just fine, there are no problems logging into the host.  The problem occurs b/c puTTY does not use STDOUT.  puTTY spawns it's own terminal window.  A window that Labview does not have access to. I will give Procomm a try.  btw, I've tried pLink to no avail also.  Thanks for your help TBD.

james 

[MaxCrunch]

Have you tried setting up a tunnel with Putty? In this way you can forward a port on your local machine to the ssh port on the remote machine.

If you can do that, then all you have to do in your Labview program is use TCP Open to open a connection to the port on the local machine and send commands / receive responses via that connection. No need for a terminal window.

Instructions for using tunnels in Putty can be found at http://the.earth.li/~sgtatham/putty/0.58/htmldoc/Chapter4.html#config-ssh-portfwd

Good luck!

[jamesS]

I have tried tunneling and I've gotten that to work, but I don't know how to use TCP Open from LV.  Let me poke around a few TCP examples.   Any pointers would be greatly appreciated.

[MaxCrunch]

You might want to try the example "TCP Communicator - Active.vi", this implements a simple tcp terminal. Set  "Machine" to 127.0.0.1 and "Port" to the port on your local machine that you are forwarding.

[LV_Pro]

I don't wish to hijack this thread, but it is similar to what I am trying, figure it has caught the attention of those using plink. I am connecting to a unit under test running QNX (a flavor of the UNIX community of O/S). Connecting requires sending a username and password. Then I have to launch UUT's internal test software which will respond to my commands, sent over a ethernet port address. At least once in the test I have to copy a file created on the test system back to my program to evaluate its data, which is where I'm running into questions. I haven't had a UUT to play with until this week, so haven't had much time to try various options. I can log on using command line entries of username and password, but I haven't figured out how to launch the UUT's test program or, later in the operation, copy the required file(s). So far I have been logging in using puTTY and manually launching the other code, and ftp'ing the required files using "FileZilla" ftp program, but need to automate the process.

Thanks, as usual.

[Jeremy_B]

Hi,

If your utilities can get the data you need to pass them from the command line, you can call them using System Exec, but you may still have the same limitations on the standard output.  It isn't that these programs don't use standard output (they do) it is that they are interactive programs and don't terminate without some kind of user interaction.  System Exec can handle two different scenarios: 1) you are calling a command which runs and then terminates, in which case you can retrieve the output, or 2) you are calling a program which requires user input to terminate, in which case you can either have LabVIEW wait for the program to complete (and then retrieve the standard output) or you can spawn it in a new process (LabVIEW won't have to wait but won't have the standard output).

It might be more flexible to run LabVIEW programs on both machines, since you can then set them up to communicate however you want.

[tbd]

Hi All,

      In case it might be of some use, the attached code was specifically designed to manage a telnet session - including user/pwd exchange - then perform a "scripted" interaction with the telnet host.  It was developed to eliminate the need for ProComm (a licensed product.)

In order to support control of multiple telnet devices simultaneously, a thread is spawned to support each telnet session.  These sessions implement a "Network Virtual Terminal" - a Telnet concept that I used to be able to describe.

The telnet stuff was debugged to work with the few (Linux) devices in the test environment at time of development - in other words, it may not work for you!

Having an aversion towards "adopting" other-peoples code - especially complex code - I certainly understand if this is greeted with skepticism!  On the other hand, if anyone's interested in using/modifying this I'd be happy to help..

Cheers!

Message Edited by tbd on 10-17-2008 10:14 PM

[jamesS]

tbd, very impressive.  I looked through your LV_comm.llb file and got immediately lost.  Tell me how I would execute the following command: putty login@<IP Address> -pw <password> using your LV_comm .vi files?