SSH with LabVIEW

I was asked last week if there was a way to interactively communicate with a remote Linux client. The only way that I knew of was to create a temporary file with the commands and then use Plink (a part of PuTTY) to execute the file of commands on the remote machine.

LabVIEW SSH plink PuTTY

This works well when you want to execute a list of commands and are not interested in the response from each command. If you want the response from each command, then you will need to call this method for each command. This is not very efficient as each time this method runs, it will log in to a different session before executing the command.

This method will also not work if you need to run custom applications on the remote client where the session needs to stay in memory.

I did a bit of searching and didn’t come across any LabVIEW solutions that suited my needs. I did find a really good C# library that looked like it would work. It is still actively supported and the latest version is only a few months old. (All good so far)

As the library is massive, my plan of action was to use the library to write my own C# dll that would do what I wanted it to do. All that I needed my library to do was connect to a remote client, execute commands and return the response and then disconnect when finished.

C# class

I decided to put everything into a class so that I can add to it in the future. There are still a few features that I want to add but will leave them for another time.

connect()

You need to create the following objects that will be used by the various parts of the application.

  • SshClient – used to connect and disconnect from the client
  • StreamReader – this will be used to read what is returned from the client
  • StreamWriter – use this object to write to the remote client

public void connect()
{
sshClient = new SshClient(remote, user, password);
sshClient.Connect(); //connect to the client
stream = sshClient.CreateShellStream("dumb", 80, 24, 800, 600, 1024);
reader = new StreamReader(stream);
writer = new StreamWriter(stream);
writer.AutoFlush = true;
}

Once these references are created, they are stored in public properties.

executeCommand()

The execute command methods writes a string to the StreamWriter object.

public void executeCommand(string command)
{
writer.WriteLine(command);
writer.AutoFlush = true;
}

Once the string has been written, the buffer is flushed.

disconnect()

The disconnect() method closes the session and disconnects from the client.

public void disconnect()
{
sshClient.Disconnect();
}

The class only contains these three methods. There is one more step that needs to be taken and that is to read the StreamReader object for responses from the client. I have left this out of the class and leave it up to the application to do the reading.

readReader()

private void readReader()
{
try
{
int i;
for (i = 0; i < 3; i++)
{
Thread.Sleep(500);
if (ssh.stream.DataAvailable)
{
tbOutput.AppendText(ssh.reader.ReadToEnd());
tbOutput.ScrollToCaret();
Thread.Sleep(50);
}
tbDebug.AppendText(i.ToString());
}
}
catch(Exception ex)
{
MessageBox.Show(ex.Message.ToString());
}
}

In the readReader() method, I monitor the DataAvailable flag. I have had to play around with the number of iterations of the for loop as different tasks take different amounts of time. Some examples that I came across only call this method once, but I found that some data is then missed. Setting the iteration too high causes unnecessary delays and setting it too low does not allow all the data to be read. There are other methods that can be used, but I still need to give those a try.

Implementation in LabVIEW

UPDATE: I have uploaded a video of a LabVIEW application being used to to communicate with LinuxLite running in a virtual machine.

LabVIEW SSH front panel

My main aim was to get a LabVIEW application working so once I had my class written, I moved into LabVIEW mode and connected everything up.

Using the .NET palette, I was able to call the constructor, read/write properties and execute methods on the class.

LabVIEW .NET pallette

I wrote a simple state machine application to test the class. All the references are stored in a typedef cluster which is shifted around each state. On the front panel there are buttons that generate events to call each case.

Constructor and connect to client

LabVIEW SSH constructor

 LabVIEW SSH connect

Execute commands on the remote client

LabVIEW SSH Execute Command

Disconnect from the client

LabVIEW SSH Disconnect

Read the StreamReader object

LabVIEW SSH readStream

LabVIEW SSH readStream 2

With this application, I am able to connect to a remote client, execute commands as I would in PuTTY and then disconnect when I am done.

There are a few things that I still need to sort out. The main one is that terminal characters are being returned. These are not seen in PuTTY as PuTTY removes them from the string that is shown. The other is that the prompt is being written twice. From what I have read this is caused by the client echoing what it receives. I still need to look at this too.

In future versions, I also want to add SFTP functionality. Being able to upload and download a file will be quite a nice feature. I also want to add different login options. Being able to login using private keys will also be useful.

As with all my posts, you can download the LabVIEW code. The download link contains a slightly modified library from the above post. If you have any feedback, please feel free to contact me on Google+ or send me an email. The LabVIEW application have been tested on the default Raspbian image running on a Raspberry Pi B.

Download LabVIEW LabSSH & LabSFTP Library

Greg

Executing Perl scripts in LabVIEW

The project that I am currently working on requires Perl scripts to be executed through a LabVIEW application which configures the UUT. As Perl is not natively supported by Windows and LabVIEW (I might be wrong here), other tools are needed in order to execute the scripts correctly.

As the scripts were developed on Linux, there was never an issue running them before developing the LabVIEW application.

Running Perl scripts on Windows

First we need to be able to execute the Perl scripts on Windows, then we can move on to LabVIEW.

The tool I am using is called Cygwin.

Cygwin is:

  • a large collection of GNU and Open Source tools which provide functionality similar to a Linux distribution on Windows.
  • a DLL (cygwin1.dll) which provides substantial POSIX API functionality.

To install Cygwin, these are the steps I took:

  • Download and install the your require for your PC
  • Select the Root Directory (C:\Users\gpayne)
  • Select the Local Package directory (C:\cygwin)
  • Select Available Download Sites: http://cygwin.mirror.constant.com
  • When selecting packages make sure you select perl(under Interpreters Group) and ssh (under Net Group) packages.
  • Ensure to add the shortcut to the desktop (We will use this later)

Once installed, running the shortcut on the desktop will open a terminal.

Cygwin Mintty terminal

The pwd command will give you the location and should be the same as set by the Root Directory above.

Create a Perl script in that directory. As an example I have created a Perl script that just prints a number for 5 seconds and then exits. To run the script, enter ./Test_Script.pl in the command line and watch as it runs.

#!/usr/bin/perl -s

my $number = 5;
while($number--)
{
print "$number\n";
sleep 1;
}
exit 0;

Cygwin Mintty terminal running Perl script

Running Perl scripts in LabVIEW

To execute an external application from LabVIEW, one way is to use the System Exec vi. This covers executing the application/script, however Windows is still not able to run a Perl script if it is just called.

The first thought that popped in my mind was to use a batch file.

Using Windows batch (*.bat) files

After doing a bit of research, I found a simple way of calling the Perl script, using bash.exe from a batch file.

@echo off

C:
chdir C:\Users\gpayne\bin

bash --login -c "./Test_Script.pl"
exit 0

This batch file, navigates to the bin directory that was installed by Cygwin and executes the Perl script using bash. The batch file then exits when the script completes.

To accomplish this in LabVIEW is really simple. Just pass the path of the batch file into the command input of System Exec and run the vi. The file runs and the output is reported.

LabVIEW system exec batch file Perl script

LabVIEW system exec batch file Perl script output

This is great because now we can run a Perl script on Windows through LabVIEW and get the Standard Output and Return Code once the script is complete.

This worked well until I started seeing times when the batch file would not exit. I tried all the escape codes that you can call on exit but nothing worked consistently.

The Perl script would execute perfectly every time when run in the terminal, but when run from the batch file and LabVIEW, it would not.

This was not acceptable so I had to look for another way to execute the script successfully every time.

Using Cygwin and Mintty.exe

As the Perl script worked perfectly when run in the terminal, I started looking at ways of replicating it from within LabVIEW. First was to look at what was run when you double click the desktop shortcut. The target points to C:\Users\gpayne\bin\mintty.exe -i /Cygwin-Terminal.ico - and this is what got me started.

I noticed that the application that is run is called Mintty.exe so I took a look at the help file. To get the help file, just type mintty --help at the terminal.

Cygwin Mintty terminal help

I was not interested in the --icon option, but the --exec option looked promising. This got me thinking of what I wanted to execute using Mintty.exe. I needed to execute my Perl script using bash.

So I started to build up my string that I would write to System Exec in LabVIEW. After some trial and error, I was successful in executing the Perl script. This is what I came up with.

C:\Users\gpayne\bin\mintty.exe -e /bin/bash -c '/home/gpayne/Test_Script.pl'

The bash help files are also helpful so from the terminal type bash --help or bash -c "help set".

This would execute the Perl script with bash running in Mintty. This was all good until I noticed that the standard output was not being reported back to LabVIEW. I needed the standard output as this is what I parse to determine if the script was successful or not.

This is very easily solved by piping the standard output from the script to a file and then get LabVIEW to read the file once the script exits. This does add an extra step, but by executing the script in this way, it runs and exits cleanly every time, being much more reliable than using the batch file. This is my final string that was used.

C:\Users\gpayne\bin\mintty.exe -e /bin/bash -c '/home/gpayne/Test_Script.pl > StandardOutput.txt'

 LabVIEW system Mintty bash Perl script output

After trying both methods, I settled on using Mintty instead of Windows batch files. They seemed a lot more reliable over many executions.

This method can surely be expanded to running Python scripts too, which I will leave for another day.

As usual, please direct any questions, comments or tips to my email or on Google+.

Greg

LabVIEW: Built Application Version Property

A LabVIEW project that I have previously worked on had many different components, each with there own version numbering. A global variable was used to READ the version numbers when the application was run.

This worked well, but became rather cumbersome when we had to manually change the global variable each time we modified or built the application. This became apparent and very frustrating when a build would be run, which could easily take an hour or two to complete, and only when running the application did we realise that we forgot to update the global or save its default value.

I thought there must be an alternative so went about exploring the application properties and methods. As it turned out, it is really quick and easy to pull the application version number from the built executable in LabVIEW.

LabVIEW Application Version main

LabVIEW Application Version subvi block diagram

Only two property nodes and one method are needed to get the version number from the built application. First you need to get the type of application that is being run. An enumerated type is returned and if this vi is run from within an application, the App.Kind property will be “Run TIme System”. In this case, pass in the path to the executable, and then get a reference to the FileVersionInfo. The FileVersion property can then be read. This will be the same value as set in the Version Information setting of the Application Properties.

Application Version Information properties

The App.Kind property can be used in a number of ways when you want specific settings to be applied only when running in certain environments.

I hope you find this useful and as usual the project used in the post can be downloaded below.

Download Build Version Property

Greg

LabVIEW Actor Framework – Linked Network Actor (LNA)

Following on from the LabVIEW Actor Framework Basics post, I wanted to continue the project showing how to use a Linked Network Actor. The Linked Network Actor (LNA) library uses network streams to communicate between Actors across a network connection. You can download the library and read all about the details over on the community page.

Either start at the beginning of the previous post, or just download the project here.

Once you have the project open, start by creating a new class, Remote Actor, and setting its inheritance to Actor.

LabVIEW Actor Framework Remote Actor Inheritance

Next you need to add the Linked Network Actor library to your project. If you used VIPM to install the library, you can find the lvlib in the following location. C:\Program Files (x86)\National Instruments\LabVIEW 2013\vi.lib\NI\Actors\Linked Network Actor

LabVIEW Actor Framework Linked Network Actor.lvlib

For your newly created Remote Actor, follow the steps in the previous post for overriding ‘Pre Launch Actor.vi’, ‘Actor Core.vi’ and ‘Stop Core.vi’. You will also need to create a launcher VI to start the Remote Actor. All these steps have been covered before and you will be left with four VIs that look as follows.

LabVIEW Actor Framework Pre Launch Init

LabVIEW Actor Framework Actor Core

LabVIEW Actor Framework Stop Core

LabVIEW Actor Framework Remote Launcher

You will now have a normal Actor that can be run from the launcher and will stop cleanly when the front panel of the Actor Core is closed.

Adding the Linked Network Actor – Remote Actor

Create a global VI which is used to define the Remote Actor identity, Local Actor identity and the IP Address of the Remote Actor. I have used a global VI in this example to keep these settings in one place, but in a proper application, these values should be saved in some sort of config file and then added in using the constructors.

Actor Framework LNA names

Now we need to create the Launch LNA VI and the Kill LNA VI. The Launch LNA VI will be run from the Remote Actor Core and the Kill LNA VI will be run from the Remote Stop Core.

In the Launch LNA VI, you need to launch an instance of ‘Linked Network Actor.lvclass’. However, before the Actor is launched, a few properties need set. Using the global VI from above, set the name to be RemoteActor, set a buffer size and a timeout. Once these properties are set, the Actor can be launched using the Remote Actor as the enquerer. Make sure to set the front panel to FALSE and wire the Remote LNA Enqueuer into the private data of Remote Actor. This enqueuer will be needed later when we want to send messages.

LabVIEW Actor Framework Remote Actor Launch LNA

Next we need to create the Remote Kill LNA VI which wraps the Send Normal Stop VI and is called from the Remote Stop Core. This will stop the Remote LNA when the Remote Actor is stopped.

LabVIEW Actor Framework Remote Kill LNA

Local Actor

Once we have the Remote LNA running, we need a local LNA that is going to connect to it. Once this connection is made, messages can be sent between Actors across a network.

Again we need to create a Launch LNA and Kill LNA VI which will be launched by the Parent (local) Actor Core and stopped by the Parent (local) Stop Core respectively. Both VIs are similar to the Remote version, except for a few additions to the Launch LNA VI.

In the Parent Launch LNA VI, we need to specify connection URL which consists of the Remote Name and Remote IP Address. Once this URL has been constructed, we can run the ‘Send Connect.vi’ which is part of the LNA library.

LabVIEW Actor Framework Parent Launch LNA

The Parent Kill LNA VI also uses the Send Normal Stop VI and is run from the Parent Stop Core.

Sending a Message

Once you have the Remote LNA and Parent LNA set up, all you need to do is create a method to run and build a message using the Actor Framework Message Maker tool. Then when you want to send a message, unbundle the LNA enqueuer and wire the message into the ‘Send Transmit Network Message.vi’. This will execute the remote method referenced in the message Do.vi.

LabVIEW Actor Framework Send LNA Message

If you need to send data as part of the message, you will be able to add the data to the message using property nodes.

Messages can now be sent across a network with ease.

As usual the working project can be found below and if you have any comments or advice, please send me an email or alternatively leave a comment on Google+. When running the program, make sure you start Remote Actor first, and then Launch the Parent Actor. It must be done this way as the Parent connects to the Remote.

Download Actor Framework LNA LabVIEW Code

LabVIEW: Tips, Tricks and Saving Time

I have been rather busy over the last few weeks at work. The inspiration for blog posts hasn’t been flowing that well so I decided to put a list of a few simple tips together. Although I have been using LabVIEW for a few years, these are things that I have only recently come across that have made my programming life that little bit easier/efficient.

Array element names:

One of the great things about arrays is that you can change the settings of on element and that change gets applied to each element inside of that array. I came across a use case the other day where I wanted each element in the array to have a specific name. Due to the nature of arrays, each element’s properties are identical, this cannot be done.

LabVIEW Array elements names_1

A way to get around this is to add a string indicator to the cluster and place it where you want the name to appear. Then when you create the array, all you need to do is specify a name for each element using a Bundle by Name function. The best string to use is a Classic >> String & Path >> Simple String and then make the background transparent.

LabVIEW Array elements names_2

LabVIEW Array elements names_3

By initialising the array first, you can name each element. You still have all the control as you would normally with the array functions, this just provides a neat way to display arrays on a front panel.

For Loop efficiency:

If you have a For Loop and each iteration does not rely on the previous iteration, there is an option which can be enabled which can speed up the execution of the entire for loop. For small For Loops this most probably will not make much difference, but when working with large For Loops which process a lot of data, you should notice a difference.

For Loop efficiency_1

By right clicking on the For Loop, select Configure Iteration Parallelism…

For Loop efficiency_2

Enable the setting and you will notice ‘P’ terminal has been added below for ‘N’. By setting this number, 10 in the above example, you are saying that instead of executing a single iteration at a time, you want the first 10 iterations to execute in parallel, then the next 10 and so forth.

Case Structure efficiency:

When I am using case structure with an enum as the selector, I always wire up my error cluster, data cluster and any other wires that are shifted between cases using the Linked Input Tunnel option. This means that whenever you create new cases within that structure, the wire automatically gets wired.

Case Structure efficiency_1

This might not seem like such a big deal, but does help when pushed for time. It is also pretty easy to forget to wire a terminal up and have to come back to it when you have a broken run arrow.

Another setting for the Case Structure selector when using strings, is to set the selector to no be case sensitive. This setting should not be used all of the time, but does come in handy in some use cases.

Case Insensitive Case Structure

Customising controls:

Controls are relatively easy to customise when you know which ones are best to use and where to start.

Start with a blank control file (.ctl) and place down the control you want to edit. I find that the best controls to edit are the Classic Controls. Below I have added a Gauge from the Classic Controls pallet.

Customising Controls_1

Click on the spanner in the toolbar and you will notice that the control gets split into its elements. I have changed the background colour so that the element borders can be seen clearer.

Customising Controls_2

By using the Tools Pallet and the paint brush, you are able to change the colour of each element within the gauge. If you want the add an image to the background, the white area in the above image, right click on the background, select Import from File at Same Size. Then select the file and it will appear as the background image.

Customising Controls_3

Once you have edited the control as you need, click on the tweezer and the control will be taken out of edit mode.

Customising Controls_4

This is a very quick and rough example, but you can now make very complex and graphical designs with the help of some image editing software to get the base images.

Quick Drop:

I have been using the basic quick drop for a while now and I know many people do use it so am not going to go into it with too much detail. One point that I would like to make is something that I only found out this week. You are able to configure the settings and also use shortcuts instead of typing the whole word of the function.

To get to the settings window, use CTRL+space to bring up the quick drop window, then select Configure in the bottom right corner of the window. Here you will be able to change the settings, add short cuts and view what all you can do with quick drop.

Quick Drop

CTRL+T is one that I found out about this week and am already using it every day.

That’s about all for today. When I think of some more tips and tricks I will be sure to update this post or write a new one if I can get a few more. The vi’s that I have used in the above examples can be found below.

If you have any comments, tips or advice, please send me an email or leave a comment on Google+ as I have disabled comments here to try and control spam.

Download Tips and Tricks LabVIEW Code

Greg