I'm using Labwerx, a 3rd party add-on to LabView for SSH. I have a single development license and have VI's working from my development environment. To deploy this add-on, I need to generate an executable with the code (or else buy a lot of development licenses that are very spendy). I have to deploy this to numerous test stations using TestStand to run sequences. In my sequences, I will be writing and reading SSH (via Shell) many times, each with a different command (string).
The problem stems from calling an executable from TestStand with inputs. My intent is to open an SSH session, then run through a bunch of steps each with a different command to be sent via SSH, then close the session. Calling an executable from TS executes it then returns. It doesn't keep the session open. I know you can develop an executable from LV code that access a command line input, but I'm not sure how this would work where I need to keep the session open and call the executable over and over (I'm trying to avoid opening and closing the SSH session over and over).
I'm looking for suggestions.
Have you found a solution?
I actually face the same situation.
Do you have to generate an executable with the code? Are you able to deploy labssh vi by using TestStand?
I could not deploy labssh by using TestStand, only if I generate an executable with the code, and call the executable in TestStand ;(
Hope to hear from you.
I iterated on a couple of undesirable solutions until, working with Labwerx I found a good solution. My plan had been to use a packed library, however since Labwerx origianlly had removed the block diagram of one of their key vi's, you could not build the vi's into a PPL. Working with them, I got them to add the block diagram back in. The latest release of LabSSH can be built into a PPL.
So, I wrapped LabSSH in my own code with the interfaces I wanted for my TestStand use case and then built a PPL from it. The top level library contains the few interface vi's I need in TestStand. PPL's work great with TestStand because they limit what vi's the user can choose to call.
To clarify a bit further, my PPL launches an asynchronous process that opens the SSH sessions and closes them when complete at the end of the sequence. That way I can keep the sessions open for an entire sequence as I have to write many SSH commands over the course of a test. I also designed my SSH process to handle many sessions.
Thank you very much for the reply.
I did not use PPL, I tried PPL, it did not work for me.
However, I put labssh.dll file into the same folder as the My VI that calls labssh VI, it works.
I also would like to keep the session open and close it at the end of the sequence. When I did the test, I used "get open session.vi" to retrieve the open session. It got the right number of the open session, the "open session count" was correct, but the "array of sessions" was empty. I tried time and time again, no matter how many session I opened, the "array of the sessions" was always empty. Have you encountered the same issue as that I met. Do you have to call "keepalive Config.vi" and "Keepalive Send.vi" to keep your open session alive?
Thank you for your time!
LabWerx has very specific instructions for creating build specs. Once they included the block diagram in init.vi, I've been able to successfully build exe's and PPL's.
Do you keep the LabVIEW reference to the SSH app alive? Do you reopen it each time you make a call? I have not had any issues with the sessions closing on me. I init the SSH app and some time later I open an SSH session. In some cases I open multiple sessions. I do not use the "keepalive Send.vi". I have all this wrapped up in an Actor so I can launch it asynchronously, thus it sits in the background and waits for me to queue up SSH commands.
It's been quite awhile since I did this work, so my recollection of details is fuzzy at this point.
Thank you very much for the reply and the link.
Well, I thought you meant PPL built by TestStand. I could make it work according to the link as you stated at the very beginning.
I did not keep the LabVIEW reference alive, because my commands have very short time intervals.
Well, I will have a look at launching asynchronously.
Thank you again!