Technical Reference: This Document Applies To TLA System Software Version 5.0 and Above
Technical Reference: This Document Applies To TLA System Software Version 5.0 and Above
Technical Reference: This Document Applies To TLA System Software Version 5.0 and Above
www.tektronix.com
Copyright © Tektronix, Inc. All rights reserved. Licensed software products are owned by Tektronix or its suppliers and
are protected by United States copyright laws and international treaty provisions.
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the
Rights in Technical Data and Computer Software clause at DFARS 252.227-7013, or subparagraphs (c)(1) and (2) of the
Commercial Computer Software - Restricted Rights clause at FAR 52.227-19, as applicable.
Tektronix products are covered by U.S. and foreign patents, issued and pending. Information in this publication supercedes
that in all previously published material. Specifications and price change privileges reserved.
Contacting Tektronix
Tektronix, Inc.
14200 SW Karl Braun Drive or P.O. Box 500
Beaverton, OR 97077 USA
1 Introduction............................................................................................................................... 2
2 Implementing TPI.NET Remote Clients ................................................................................... 3
2.1 Compiling Against the Shared DLL................................................................................... 3
2.2 Deployment ....................................................................................................................... 3
2.3 Connecting to the TLA Application.................................................................................... 4
2.3.1 Connecting with a Configuration File ......................................................................... 4
2.4 Accessing Interfaces ......................................................................................................... 5
2.5 Receiving Events from the TLA Application...................................................................... 5
TPI.NET Remote Clients are managed .NET applications that access functionality of the TLA
application. Such an application runs as a separate process from the TLA application and may be
run either on the same controller or on a PC connected via a network to the TLA. A remote client
application has its own user interface separate from the TLA application. Access to the TLA is
realized through remoting services built into .NET and through the shared DLL
“TlaNetInterfaces.dll” that remote client applications compile against and use at runtime.
Development Overview
TPI.NET remote clients are developed by creating managed applications that utilize services,
classes, and interfaces defined by the TlaNetInterfaces.dll. Before a remote client can be fully
implemented, the developer needs the following items:
• A .NET enabled compiler, Visual Studio .NET for example.
• A copy of TlaNetInterfaces.dll.
• Version 1.1 of the .NET Framework.
All remote client developers must use .NET-enabled compilers, which can create assemblies with
code that executes under the Common Language Runtime. The NET interface specifications for
the TLA application have been written with the expectation that remote clients will be developed
most often with Microsoft's Visual Basic, C#, or Managed C++.
In order to create a remote client application, the developer must have a copy of
TlaNetInterfaces.dll, which is a DLL present in every V5.0 TLA software installation. It is an
assembly that contains metadata for all TLA remote interfaces and TPI.NET types. The file holds
the compiled definitions of all .NET types that are currently described in the document entitled
"TPI.NET Reference Manual." Both the TLA application and all remote client applications are
compiled using references to the metadata in this assembly. TlaNetInterfaces.dll serves a
purpose similar to that of a header file. It holds the definitions of types that will be used by
multiple projects, including projects that are compiled separately. The TlaNetInterfaces.dll may be
copied from the folder “C:\Program Files\TLA 700\System” on the TLA system.
V5.0 TLA software is built against the version 1.1 of the .NET framework. Visual Studio 2003
creates applications for this version of the .NET framework and is highly recommended for
building remote clients targeting the V5.0 TLA application. The TLA application ships with a re-
distributable install for the version 1.1 of the .NET framework and it may also be downloaded from
the Microsoft web site.
Code Samples
The same CD that contains this document also contains sample code for a small TPI.NET client
application. This sample is presented in three separate languages supported by Microsoft Visual
Studio .NET: Visual Basic .NET, C#, and C++ with managed extensions. Each sample has a
solution file that can be opened and built to produce a working plug-in or client application.
To use these sample projects, copy the directory contents of the desired sample from the CD into
a directory on the computer that contains your development environment.
Under Visual Studio 2003 C#, a reference to the shared DLL is specified through the Solution
Explorer. Select the project node from the solution tree control. Select “Add Reference…” from
the Project menu and use the dialog to add a reference to the shared DLL.
Visual Studio 2003 C++ also lets you specify references to .NET assemblies using References
folders. Alternatively, the path of the folder containing the shared DLL can be specified through
the Project Properties. Open “Configuration Properties”, then “C/C++” and select the “General”
category. Enter the folder name on the line labeled “Resolve #using References”.
Then add the line #using “TlaNetInterfaces.dll” at the top of the .cpp source files of the remote
client.
The shared DLL contains type and interface definitions organized into three namespaces:
Tektronix.LogicAnalyzer.Common
Tektronix.LogicAnalyzer.TpiNet
Tektronix.LogicAnalyzer.PlugIn
Types and interfaces may be referred to with either fully qualified namespace names or by just
their names when namespace scoping statements have been used.
2.2 Deployment
A remote client application may reside directly on the TLA controller or on a networked PC. The
.NET Framework version 1.1 comes pre-installed on version 5.0 TLA controllers, and V1.1 is the
recommended Framework on which to run TPI.NET clients. The TLA application ships with a re-
distributable install for the version 1.1 of the .NET framework and it may also be downloaded from
the Microsoft web site.
A TPI.NET remote client has minimal installation requirements in order to be used with the TLA
application. Generally, a remote client consists of the following files located in a common folder:
No registry changes are necessary for a remote client application installation. The installation is
accomplished simply by placing the appropriate files in a common folder as outlined above.
The TLA application publishes this interface with the help of the configuration file “C:\Program
Files\TLA 700\tla700.exe.config”.
The ITlaSystem object is a well-known singleton. It can be obtained by calling the framework
method System.Activator.GetObject() with arguments specifying ITlaSystem type and a suitable
url for the networked TLA controller. A simpler and more flexible means of obtaining the
ITlaSystem object is by using a client configuration file and a utility class provided by the shared
DLL.
The localhost component can be replaced by an IP address or symbolic IP name. This allows a
remote client to target a different TLA system without needing to be recompiled.
C# example:
using Tektronix.LogicAnalyzer.TpiNet;
public class MyTlaConnection
{
public static ITlaSystem ConnectToTla()
{
An application developer might use the configuration file with a localhost setting to develop and
debug the application on a PC. In this case, TLAVu could be installed on the PC and would be
targeted by the application under development. The developer could also choose to target a real
TLA controller during development by replacing localhost in the configuration file with the network
address of the TLA controller.
At run time, the remote application obtains a handle to an instance of an object implementing the
ITlaSystem interface. The ITlaSystem object is obtained through a call to
RemoteTlaSystem.Connect( filename ) as described in the section above.
The ITlaSystem interface provides some values directly, such as the application software version
string through the ITlaSystem.SWVersion property. The ITlaSystem interface also provides
handles to other interface objects. These in turn may provide values or services directly or they
may provide handles to other interfaces. The interface objects are accessed as a hierarchy with
ITlaSystem as the root.
The complete list of interfaces is documented separately in " TPI.NET Reference Manual".
Support for events is a standard feature of the .NET programming languages and compilers. An
event is a member of a class or interface in the same sense that methods and properties are
members. The ITlaRunControl interface has a RunCompleted event that is expressed in C# as:
An event member has a name (RunCompleted) and a delegate type (System.EventHandler). The
delegate type defines the signature of any handler method that can be called in response to the
event. More information on event syntax and delegates is available in the Visual Studio
documentation.
Note that the default security levels for the version 1.1 .NET Framework will prevent TPI.NET
clients from receiving events. A configuration file can be used to set up remoting so that events
work as expected. The example file ITlaSystemRemoteClient.config can be used to correctly
configure remoting with a TPI.NET client application. See Section 2.3.1 Connecting with a
Configuration File.
When one application callback is invoked in response to an event from another application, the
.NET framework invokes this callback from a thread of a thread pool on the receiving process.
The callback does not execute in the main thread of the receiving application. If a remote
application utilizes events from the TLA application, it becomes a multi-threaded application.
A remote client utilizing events from the TLA application must be designed as a multi-threaded
application. This includes making its data access thread-safe and preventing deadlock situations.
In order to prevent deadlocks associated with maintaining thread-safe data, the TLA application
sends remote event notifications on a worker thread and does not block waiting for remote
callbacks to complete. From the remote client application perspective, events may be received
well after the event of interest actually occurred. The callback implementation should not assume
that the TLA application is still in the same state as when the event originally occurred.
Under the .NET Framework, the server (TLA application) needs access to the assembly (remote
EXE file) containing the event handler. This presents a problem when sending events to remote
clients.
To solve this problem, a number of small “shim” classes are defined in the TlaNetInterfaces.dll.
These shim classes are available to both the TLA application and the remote client through the
shared DLL. The shim classes are used as a bridge between the TLA event and the remote
client. A remote client that attempts to register for events directly rather than with shims will
experience a run time exception.
The remote client creates a new instance of a shim and registers the shim’s OnRemoteEvent
method on the TLA event. The remote client registers its actual callback on the shim’s
RemoteEventOccurred event. When the TLA event fires, the shim’s OnRemoteEvent method is
called and it fires the RemoteEventOccurred event to call the remote clients actual callback.
using Tektronix.LogicAnalyzer.Common;
using Tektronix.LogicAnalyzer.TpiNet;
public class TestRunCompleted
{
EventRemoter shim;