Passing telnet session between LabVIEW calls from TestStand

From TestStand I am calling VI's from telnet.llb.
In one TestStand step am opening a telnet session to an IP address and collecting the telnet connection (U32). In the next TestStand step I pass the telnet connection to a telnet write VI but get this error.
"Dequeue Element in Acquire Semaphore.vi:1->Telnet Write.vi:1->Telnet Write.vi.ProxyCaller"
The telnet open, write, read, and close work great if I pass the telnet session number within the same VI. But I need to keep the session open between calls from TestStand because one huge VI is not feasible.
thank you
josh
Solved!
Go to Solution.

Hi,
Maybe the following link can help
http://forums.ni.com/t5/NI-TestStand/Can-a-Telnet-session-be-passed-from-1-vi-to-the-next-in-test/m-...
Regards
Ray Farmer

Similar Messages

How to change Enumerator programmatically in LabVIEW called in Teststand

How to change Enumerator programmatically in LabVIEW called in Teststand ?
I know that Enumerator cannot be changed programmatically since the data type itself different from other controls like Ring and Combo box.
My application involves in Property loader which will load the list of names to Enumerator during Initialization. And the same shall be used by operator to select in further steps for testing. I tried with Ring and combo box but it doesn't works because its not giving dropdown option in TestStand Steps to select the name.
I need a drop down and also programmatically changing the value of the same variable. I had gone through all forum solutions regarding Enum, but I couldn't get any work around for this.
Please suggest me a solution or best work around to do this.
Thanks,
Vijay
L&T Limited
Certified LabVIEW Developer
India.

Can you provide an example of how a ring control/combo box does not work? This should be the way to do what you want unless I am misunderstanding exactly what you want to do. In theory you could have a dynamic enumerator type, but there are lots of hoops to jump through using VI server and scripting and it is not worth the effort. Aesthetically, you can make the ring control and enumerated data type look exactly the same. I would be using a ring control.
Please post an example of how it does not work.

HTBasic hanging while doing a GPIB command, Called from TestStand

I have functions in HTBasic called from TestStand for doing GPIB communications for different test sets. When i run the main sequence, the sequence hangs in a HTBasic step. The step is different every time. Does anybody know about this problem?

Hi,
I have some questions.
Does the HTBasic programs run by themselves?. Or does it only hang when executed in TestStand?.
What GPIB driver and interface are you using?. What GPIB operations are you performing?. Is there any error message shown?.
The main idea is to figure out if the error is caused by the GPIB operation or by TestStand.
Include any information you may consider important.
DiegoF
National Instruments.

Problem calling a LabVIEW VI from TestStand

I'm am currently migrating my companies test scripts from TestStand 3.0 to TestStand 4.1.1 and VI's from LabVIEW 7.0 to LabVIEW 8.6. I have re-saved all of the sequence files to the new version as well as performed the 'Mass Compile' operation on all of our custom VI's. During the execution of one of the sequence files a call is made to a VI (through a LabVIEW library). If I run this sequence file on a machine with the development software and have the Adapter for LabVIEW set to use the development system the VI executes as expected. If I have the adapter set to use the Run-time engine (in this case 8.6, the same as the development version) I get an error:
"LabVIEW: The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Open the VI in LabVIEW using File>>Open and verify that it is runnable."
I noticed that in the library file there are sub VI's that are called from "C:\Program Files\National Instruments\LabVIEW 7.0\vi.lib" This directory only exists on machines that have the development system installed. Perhaps this is why the VI does not execute using the runtime engine

Ray is right. Development environments are backwards compatible (you can run VIs compiled in LabVIEW 7.1 or 8.5 in LabVIEW 8.6). That's why you can run your sequence just fine on the development system, but on the target machines you are using the LabVIEW Run-Time engine, which is not backwards compatible. With the Run-Time engine, ALL VIs need to be in the same version as the Run-Time engine (including VIs in vi.lib, tools.lib, instr.lib, etc.).
The first thing I would check is make sure everything has been mass compiled to 8.6, including vi.lib. If you are still getting the error you should be able to tell at what point the error occurs so you can look at that specific VI. Open it and confirm there isn't a broken run arrow and check to see what subVIs that VI is using and confirm they all have been compiled in version 8.6 too.
This should get you going, but if not just let us know.
Message Edited by CorbinH on 05-07-2009 08:24 AM

Calling labview executable from teststand

I have a labview VI that I build into an exe, and I'd like to call it from my teststand sequence in the setup - other test steps need to use its capabilities in the remainder of the sequence (main). If it were just a VI, then no problem, the inputs would be visible to me, and I could pass them in. Since it's an executable, though, my step is of type "Call Executable", but I don't see anywhere that it allows me to pass in the inputs it needs. Thoughts?
Solved!
Go to Solution.

What version of TestStand are you using? With TestStand 4.0 for the 'Call Executable' step there is a line called
Argument Expression:
Enter your parameters to pass into your LabVIEW executable. You will have to know which ones to pass in and in what order. I believe you can seperate the arguments by spaces. In my attachment, I pass in one parameter to a LabVIEW executable.
Remember, though you have to set the Build properties in LabVIEW to allow it to Pass command parameters to the application.
Thanks,
PH
Attachments:
Call Executable.JPG ‏48 KB

How to display non modal dialog box in a Dll call from TestStand implemented in visual c

Dear Jason F.
Applications Engineer
National Instruments
Hello
I did the same way you told me
the non modal dialog appeared and
system hangs and
giving the error message
""SeqEdit.exe-Application Error
The instruction at �0x047fc5b0� referenced memory at �0x047fc5b0�. The memory could not be �read� ""
please solve my problem
and thanks for yours early response
you can email me at
[email protected]

Hi Mkehret,
Does your dialog have ActiveX controls on it? If your DLL dialog uses ActiveX controls and is not programmed in a certain manner it can hang because of a conflict in the threading model used by the TestStand Engine that is calling into your DLL and the model that is required by the MFC ActiveX Container. If you are using ActiveX controls in your dialog, you need to make special considerations for the threading model MFC dialogs that use ActiveX controls need in order to work properly. The example under \Examples\MFCActiveXContainerDlg illustrates how to appropriately handle this situation as well as explaining why it is necessary.
Note: The above example displays the dialog as modal, but this is irrelevant to the problem I am describing.
Again for information on properly creating a dialog class object and displaying it as non-modal refer to the information on MSDN that I referred you to in this post:
http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=506500000008000000E98A0000&USEARCHCONTEXT_CATEGORY_0=_8_&USEARCHCONTEXT_CATEGORY_S=0&UCATEGORY_0=_8_&UCATEGORY_S=0
If your dialog does not use ActiveX controls or after trying the programming method illustrated in the "MFCActiveXContainerDlg" example TestStand still hangs when calling your DLL, try calling your DLL from another environment just to make sure whether the DLL works at all. If the DLL works properly when called by another environment (e.g. VB, VC++, LabVIEW, or CVI), please submit a MINIMAL and REPRODUCEABLE example source project for your DLL for us to look at (please exclude all unnecessary code not required to reproduce the specific problem of displaying the dialog, and include all files necessary to build your dll with any
specific instructions needed to do so).
Jason F.
Applications Engineer
National Instruments
www.ni.com/ask

Passing strings to a LAbVIEW application from Visual-C++ using ActiveX

Hello all,
I have built a LabVIEW application with ActiveX server enabled. I can
start the application, and can read and set simple control values like
numerics.
But now I want to pass (SetControlValue) strings and read (GetControlValue) strings from controls.
After searching a whole day for examples or HowTos I found nothing. Can
anyone give me tip where I can find something about that?
Examples are also appreciated.
Best regards
Heinrich Eidloth

The problem you are running into is that a BSTR is not a normal string (%s in the printf), but a wide character string (i.e., two bytes per character) string with the size stored in it. If the string contains ASCII characters, such as Hello World, then the one of the bytes per character is 0 (for example, 'H' would be 0x48 0x0).
When printf sees this, it thinks that it is a normal, null terminated string of "H". That is what you are seeing. You might try the %S (capital S) since that tells it the string is a wide character string.
Also note that BSTR's are part of the COM (Automation) system and so are don't freed with a delete or free() statement. Instead you need to release the memory with a SysFreeString() call.
If you aren't very familiar with C/C++, then you've taken on an advanced topic on top of a complicated language. If you can, you might want to try using either VB6 or .NET (C# or VB.NET). Those languages handle all of this for you automatically and you don't have to worry about freeing the memory.
If not, the book I started with to learn COM programming was this one (http://www.amazon.com/gp/product/1572313498/104-3574382-6511132?v=glance&n=283155&n=507846&s=books&v...).
Brian Tyler
http://detritus.blogs.com/lycangeek

Error Code -2147467259 when custom FrontEnd Callback is called from Teststand.

Hello,
For the project I am working on, the standard LoginLogout sequence has to be overriden from a custom one. The sequence i implemented does the following: A connection to a database, located on a virtual machine at my pc, is initially opened, the user name and password are given by the user through a message popup and the information is compared to the database entries. If the username and password are valid, a new TestStand user with the corresponding user information and priviliges is created and set as current user. If not, the procedure is repeated five times and if it ends unsuccessfully, the user account is blocked.
The implemented sequence works just fine when I run it independently in TestStand, while I'm logged in as administrator using the standard TestStand Front End callback. When I added it in the LoginLogout sequence in the FrontEndCallbacks.seq in C:\Users\Public\Documents\National Instruments\TestStand 2010 SP1\Components\Callbacks\FrontEnd in order for this to be called instead of the standard one, I received the following errors:
1. Error HRESULT E_FAIL has been returned from a call to a COM component. Error Code= -2147467259
This error appears immediately after I open the sequence editor. (see also attached images
2. LABVIEW: (Hex 0x80004005) Unspecified error.
This error appears when I run the customized user interface in LabVIEW that calls the FrontEnd callback in the TtestStand public folder. After the error message appears my custom login dialog pops up and after the user logs in (the procedure works as expected) and then presses OK to the error message, the vi stops. It cannot execute further.
I suspect that there is a problem when connecting to the database but I cannot understand what it is or why this is happening since the sequence runs without problems in Testand.
Could someone help?
Thank you very much!

I am sorry for the omission. As seen during a highlighted execution of the GUI, the error appears after the call of IApplicationMgr.Start (see attached image).
Attachments:
error_blogdiagram.png ‏72 KB

Can't close CVI panels in DLL-Detach when called from Teststand

Hello,
i've got a problem with Teststand calling a DLL produced with CVI.
1. I use to DLL Attach and Detach calls to load or discard the panels. The attach part works fine, but when the TS sequence ends and i try to unload the module, the "DiscardPanel" function returns a error -129 "operation can only be performed in the thread it was created".
If i call the same dll from a CVI executable, this doesn't happen.
2. Additionally, the first time i run the sequence file the panel doesn't correctly quit and return to Teststand, so the whole thing hangs.
Does anybody have an idea, what is going wrong?
See attached files:
ErrorOnDllDetach.seq --> Call DLL from TS
\bin\usePanelsDll_dbg.exe --> Call DLL
from CVI
Attachments:
NoUnloadOfDll.zip ‏326 KB

Maik -
After some more investigation, because of limitations in Microsoft's operating system, developers and CVI are limited in what they can do in DLLMain. Basically load and unload CVI panels in DLLMain just does not work well if the DLL is loaded and unloaded arbitrarily like it is in TestStand.
One option is to never unload the panels and let CVI and the OS clean up the panels when the process terminates. You can do this by adding an extra reference to your DLL using LoadModule. You would basically prevent TestStand from unloading the DLL, so any dialog would stay around for as long as you like.
The best way to have the dialog go away when TestStand is no longer using it is to associate your dial
og lifetime with the execution that is displaying it. You load the panel either when the first call is made into the DLL or by an explicit call to a "Display" function exported from the DLL. Then have the dialog monitor for when the execution is terminated or stopped. This works because TestStand does not attempt to unload the DLL until the execution that is using it completes.
I have attached an example DLL and sequence that does just this. It uses a default pool thread to display a panel and that thread waits for either an explicit call to a "Discard" function exported from the DLL or or if the execution stops.
Hope this helps...
Scott Richardson (NI)
Scott Richardson
National Instruments
Attachments:
DLLProject.zip ‏344 KB

Passing state into a Task called from a continuation

I have implemented a solution from Crafting a Task.TimeoutAfter Method and I curious about the best practice regarding passing data upwards from a Task to its continuation.
I would like to know if the parent task released the semaphore, I could simply release it only in the continuation, is that safe enough?
Task task = Task.Factory.StartNew(
() =>
try
this.MyMethod(foo, bar);
catch
// Signal termination.
taskCancellationTokenSource.Cancel();
// Propagate up.
throw;
finally
// Release handle.
semaphore.Release();
TaskCreationOptions.AttachedToParent)
.TimeoutAfter(5000)
.ContinueWith(
antecedent =>
// How can I pass state/indicator into this task to know if I need to do ths?
semaphore.Release();
if (antecedent.IsCanceled || antecedent.IsFaulted)
throw new System.TimeoutException("A task has hung.");
Thanks!

Hi Ritmo2k,
The Semaphore.Release method will release one semaphore to the pool. If the pool is already full, it'll throw SemaphoreFullException, that means you cannot call Release method until a thread has called WaitOne method. And this method will return an integer
which indicates the count on the semaphore before Release method is called.
If I understand you correctly,you want to know the count on the semaphorebefore you call the second Release method. I think you could create a global integer variable to store the return value from the first call of the Release method.
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey.

How to pass variables to a program called from long text of an error msg ?

Hi,
The aim is the following: in the long text of an error message, there should be a link; this link must call a program or a transaction and pass to this program or transaction the four variables of the error message. Is it possible to insert such a link with parameters in the long text of the error message ? If yes, what is the syntax for this ?
(I searched in the forum and found the way to insert a link to a transaction, but I found nothing about parameters).

Thank you for the answer.
Unfortunately, this solution is not applicable in my case. I'm using the application log and the scenario is the following:
- the user displays the application log in transaction SLG1
- he sees a lot of error and succes messages
- by dubble-clicking on these messages, he displays the long text of the messages
- I want a link in these long texts to a transaction using the variables of the messages. I tried inserting a link to a transaction, and the transaction is well called, but with a breakpoint I checked variables SY-MSGV1 to MSGV4 and they are empty.

TestStand not passing VISA info to LabVIEW

Hi All,
I am encountering a problem passing a VISA resource name to LabVIEW (2014) from TestStand (2014) which I cannot for the life of me understand or solve. Thus and so, I would be exceptionally grateful for any help.
I have two Thurlby Thandar LXI power supplies in a test rack, each with unique IP and socket addresses, of the form (TCPIP0::192.168.0.3::9221:OCKET). I have a LabVIEW project which contains a number of VIs, each related to the various functions of the PSUs, which are called from TestStand as appropriate.
I'm calling the LabVIEW 'Initialise.vi' in TestStand within a "ForEach" loop to individually extract the PSU's addresses from an array, open a session, then store the SessionNumber, but the resource name data doesn't seem to make it through to the VI's front panel VISA control. I've checked, checked and re-cheked that the correct values are being pulled from the array, I've even tried putting the LabVIEW call in a sub-sequence, just so that I can verify the data is not being corrupted in any way, but all seems to be well. It's as if the link between TestStand and LabVIEW is somehow broken.
To clarify the issue, on the very first run, the VISA information does get through, but subsequent runs retain this value, rather than overwriting it with the next value in the array. Setting the Run Options of the LabVIEW Action step type to Load Dynamically then Unload after step executes overcome this issue, but cause problems when trying to control the PSU later on in the test sequence.
The most maddening thing is that this used to work up until a couple of weeks ago, but unfortunately I can't remember what, if any, changes I may have made.
I've reinstalled TestStand and LabVIEW, but it hasn't solved the problem.
I've made the VI re-entrant, but that doesn't make any difference (in truth it shouldn't, as although the VI is called numerous times, all calls are sequential rather than simultaneous, so re-entrancy shouldn't be an issue).
I've configured the PSUs in MAX and given them aliases and tried the addresses direct, but that makes no difference either.
I've also tried performing the same exercise of passing data to LabVIEW just using strings and that all works fine, it just seems to be an issue with VISA resource names.
I have a suspicion I've checked or un-checked a check-box somewhere in the bowels of TestStand that's causing all of this, but haven't a clue how to find it.
If anyone can shed some light on this why this issue is occurring, or could even just point me in the direction of some utility which could sniff dataflow between TestStand and LabVIEW, I would be very grateful.
Many thanks in advance

Personally, I use Action Engines to handle my instrument resources. You can call the AE directly in TestStand. What I typically do is have a string input for name and then do a quick lookup for the desired VISA Resource to then control the instrument. This keeps all of the VISA stuff (including resource references) in LabVIEW. Have never had a problem with doing it this way.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

While loop stuck in LabVIEW when VI called by TestStand only

LabVIEW 8.5, TestStand 4.0, Windows XP-SP3
The issue I’m facing is a different behavior of a LabVIEW VI whether it is called independently (in the LabVIEW environment: normal behavior) or from TestStand (unexpected behavior).
In the same VI, I've wired in parallel, so they can execute in parallel:
a call through “System Exec”, to a program which prompts for a user's answer. The case I’m concerned is when the answer will never come...
a while loop, managing a timeout which finally kills the program above when it waits infinitely for a user's answer
Just to be more precise for those who’d try reproducing the issue (but you might just have a look at the enclosed VI): in my case the program is the command line WinSCP.com. WinSCP prompts when it wants you to accept the host’s private key which is not in its cache. Don’t be afraid if you’re not used to WinSCP, the concern here is LabVIEW + TestStand.
What happens when we’re stuck in the “System Exec”:
under LabVIEW: it works fine, as expected; while stuck in the “System Exec”, the while loop executes in parallel
when the same VI is called in a TestStand sequence step (ActiveX automation server to the LVdevelopment system), it does not run the while loop (we're stuck in both System Exec and inside the loop). The only way to release everything is to manually kill the program called by the System Exec through Windows Task Manager.
For information, all tasks: TestStand (SeqEdit), LabVIEW and program (WinSCP) show 0% CPU and their memory usage is stable.
Have you an explanation for this unexpected / different behavior of the VI, only because it is called from TestStand?
Enclosed is the VI.
If you actually want running it, you might have WinSCP installed and a valid session to an accessible host (adapt path to WinSCP and session name), and do not put the host key in the cache!
Note: you won't see the same issue with other programs or commands called by System Exec (e.g. netsh, ftp...) even if they await a user's prompt.
Thanks for your help!
Solved!
Go to Solution.
Attachments:
CheckLabVIEWLock.vi ‏26 KB

Have you tried changing the Preferred Execution System of the VI from 'same as caller' to 'other1'.
Regards
Ray Farmer

How can I convert a Database Handle from TestStand to LabVIEW?

I want to use a Database Handle (already created in TestStand by an Open Database step) in a LabVIEW-VI (called from TestStand) to connect it with the "Connection Reference" input of the "Easy SQL.vi"? If I use a directly connection via the "TestStand - Get Property Value (Number).vi" I get back the error message 4101 in LabVIEW. How can I convert the Database Handle?
Test Engineering
digades GmbH
www.digades.com

The TestStand database step types use the CVI SQL Toolkit to talk to databases. The handle that you are referencing is an internal memory location and not a actual handle that you can directly use. Currently as implemented the handle that is stored in a numeric TestStand property for the connection and the SQL statement are the handle values returned from the CVI SQL Toolkit. So for the connection handle, you could call the CVI SQL Toolkit function
DBGetConnectionAttribute (
int Connection_Handle,
tDBConnectionAttr Attribute,
void *Value);
and get the CVI CAObjHandle reference. With this you could then call the CVI ActiveX function
CA_GetInterfaceFromObjHandle(
CAObjHandle Object_Handle,
const IID *Interface_Id,
int Force_AddRef,
void *Inte
rface_Ptr,
int *Did_AddRef);
to get the actual ActiveX interface reference. This would have to be converted into a LabVIEW reference.
You may want to consider just using LabVIEW to open a new parallel reference only using the toolkit.
Scott Richardson
National Instruments

Fatal error Labview.lib not called from a Labview process

in teststand my vi works fine with adapter set for LV development
when I configure the LV adapter for runtime, I get fatal error Labview.lib not called from a Labview process
what is going on?
how do I fix it?
thanks.

Howdy Stephen -
Are you by chance calling a LabVIEW DLL within your LabVIEW VI which is being called from TestStand? I know this error occurs when a LabVIEW DLL built in a different version of LabVIEW than the selected Run-time Engine.
Here is a KnowledgeBase which references the issue:
KnowledgeBase 203EA3XC: LabVIEW.LIB Error When Calling a LabVIEW DLL Built with VIs That Use Externa...
If this is the case, you will need to open the LabVIEW DLL source VI in the LabVIEW version you are using and rebuild the DLL.
Thanks and have a great day!
Regards,
Andrew W || Applications Engineer
National Instruments

Passing telnet session between LabVIEW calls from TestStand

Similar Messages

Maybe you are looking for