PyDevCom: A generic device communications application

Abstract

PyDevCom is a small application written in the python programming language for communicating with astronomical instrumentation devices (e.g. temperature monitors and controllers, motion controllers, etc.) that use serial communication interfaces. It provides a highly configurable framework for defining an interface for communicating with a serial device. The configuration information for PyDevCom is stored in an XML file which is designed to be easily read and customised. Therefore when an interface to a new device is required, a new configuration file for the device is all that is needed. This avoids having to write a new device specific communications application. The core PyDevCom application can be used interactively in a Python terminal, or may be executed inside a script, providing a great deal of flexibility for testing hardware in the lab. PyDevCom has its own platform-independent GUI, based on wxPython, which automatically constructs the interface for a given device from the information in the XML configuration file. Future development for PyDevCom will add several new user interface features that include a plug-in architecture for adding specially tailored GUI interfaces written in python. Once these features have been implemented they will extend PyDevCom to function as a lightweight instrument control system.

Full text

PyDevCom: a generic device communications application
Stewart A. M cLay
UK Astronomy Technology Centre, Royal Observatory, Edinburgh, Scotland
ABSTRACT
PyDevCom is a small application written in the python programming language for communicating with as-
tronomical instrumentation devices (e.g. temperature monitors and controllers, motion controllers, etc.) that
use serial communication interfaces. It provides a highly configurable framework for defining an interface for
communicating with a serial device. The configuration information for PyDevCom is stored in an XML file
which is designed to be easily read and customised. Therefore when an interface to a new device is required,
a new configuration file for the device is all that is needed. This avoids having to write a new device specific
communications application. The core PyDevCom application can be used interactively in a Python terminal, or
may be executed inside a script, providing a great deal of flexibility for testing hardware in the lab. PyDevCom
has its own platform-independent GUI, based on wxPython, which automatically constructs the interface for a
given device from the information in the XML configuration file. Future development for PyDevCom will add
several new user interface features that include a plug-in architecture for adding specially tailored GUI interfaces
written in python. Once these features have been implemented they will extend PyDevCom to function as a
lightweight instrument control system.
Keywords: Instrument Control, Python
1. INTRODUCTION
Many astronomical instruments require some form of environmental control and possibly some mechanism control
to operate efficiently. Environmental control is necessary to achieve conditions where the instrument can operate
at optimal performance with minimum interference. This is especially true for infrared and sub mm instruments
that require a cryostat that is cooled to extreme temperatures to reduce the background signal and improve
the detector read noise. Mechanism control may be required for focusing the camera, changing a filter, image
rotation, etc. Generally, the hardware and the software to control the environment and mechanisms is combined
into the same sub-system.
Lots of leading observatories have their own software and hardware infrastructure for environmental and
mechanism control. These systems may have been in use for several years and will probably continue to be in
use for the rest of the instrument’s lifetime. Many of today’s systems were originally developed in the 1990’s
and are based on VME bus hardware with processor boards, motion controllers, RS232 serial and digital IO
interfaces. Also there are several types of devices with RS232 serial interfaces that are used and are sometimes
interfaced through the Ethernet via terminal servers which act as RS232 to Ethernet adapters. These include
electronic devices such as motion controllers, temperature monitors/controllers, pressure gauge monitors, etc. A
few telescopes adopted EPICS
1
as their software platform whilst others have developed their own proprietary
software. Many of these systems run on the licensed VxWorks real-time operating system although very few
instruments really require that type of performance from an operating system with the computing power available
these days.
The author has spent several years working at the UK Astronomy Technology Centre (UK ATC) developing
such systems for several instruments that have been installed at a few of the world’s leading telescopes. Most of
these instruments used the software and hardware systems described in the previous paragraph. The opportunity
to develop a new system for a in-house technology demonstrator project came along which presented the oppor-
tunity to apply some fresh thinking for trying out new ideas. As with any engineering project it is important to
Further author information: (Send correspondence to S.A.M.)
S.A.M.: E-mail: sam@roe.ac.uk, Telephone: +44 (0)131 6688304
Advanced Software and Control for Astronomy II, edited by Alan Bridger, Nicole M. Radziwill
Proc. of SPIE Vol. 7019, 701914, (2008) · 0277-786X/08/$18 · doi: 10.1117/12.789336
Proc. of SPIE Vol. 7019 701914-1
2008 SPIE Digital Library -- Subscriber Archive Copy

establish the project requirements. Or in this case to put it more simply, “what do I need to make a good device
control software system?” Whilst considering the answer to this question the following list of requirements were
gathered.
• Send commands to and receive replies from devices
• Monitor the status of sensors/gauges/digital IO/analogue IO attached to the devices
• Support for different types of communication protocols (RS232, USB, TCP/IP)
• Highly configurable and re-usable for different devices
• Easy and quick to configure for a new device
• Logging of operations and monitored data
• Plot monitored data and monitor alarm status
• Flexible interface for automated testing in the labs
• Easy to use Graphical User Interface (GUI)
• A generic framework that could be adapted for different applications
• Portable across popular operating systems (MS Windows, Apple OSX, Linux) for running on a regular PC
When conceiving the list of requirements it soon became apparent that two key requirements were likely to
prove the most challenging. To develop an application that is highly configurable and re-usable for different
devices whilst being simple and quick to configure. These two requirements generally conflict with each other.
A balance would have to be struck to develop the best application that met those requirements.
2. MAIN FEATURES OF PYDEVCOM
When deciding how to develop an application that met the requirements listed in section 1 a number of design
decisions had to be made. Another key factor to be taken into consideration was the short development time
allocated for this project. In order to develop an application that had several features in a short space of time
the choice of programming language and development tools would play an important role.
• Programmed in the Python programming language
– Easy to learn and fast for developing applications
– Portability across platforms and run time environments (Jython, IronPython)
– Flexibility and ease of use that comes from using a scripting language
– Lots of free software modules, libraries, frameworks and applications available
• Device interface is specified in a highly configurable XML file
• Application is split into two parts:
– Core application uses the device configuration file and communicates with devices. It can also be used
for automated test scripts.
– GUI for manually controlling devices uses the core application. Interface is automatically constructed
using information from the device XML configuration file.
• Support serial communications in both ASCII and binary
• Support RS232, USB and TCP/IP protocols
Proc. of SPIE Vol. 7019 701914-2

• Logging: operational logging and status monitoring logging
Choosing to use the python programming language was an important decision. Flexibility for testing hardware
is very important as you never know what problems you might face until they arise. This is particularly true
when testing mechanisms and you need to quickly provide a program that can automate a sequence of commands
to test their accuracy and reliability. Using a scripting language in these circumstance provides a good solution
for balancing flexibility with a short development time to get tests up and running.
The decision was also made to develop the application so that it was compatible with Jython version 2.1
which supports the equivalent CPython language version. This would allow the application to be used in Java
programming application environments. This feature was used as part of the Star Picker
2
instrument developed
at the UK ATC where PyDevCom was compiled into a JAR file that was linked into a Java application for
running the instrument.
An explanation of the decision for using the XML document format for specifying device interfaces and a
description of the file format is given in section 3.
The application design was split into two core parts. The core of the application would handle the parsing of
the configuration file and provide the functionality for handling communications with remote devices. It would
also handle the formatting of commands and processing the replies for controlling and monitoring the device. A
simple API that made it easy to take advantage of the highly configurable interface for controlling devices would
be provided. A good simple API is important for developing automated test scripts quickly when carrying out
lab tests.
As well as a scripting interface a GUI would be necessary to provide an easy to use interface for manually
controlling devices. The GUI interface is an extension of the core application. As the main concept of the
application is to provide a highly configurable interface for different types of devices the GUI would also have
to reflect this. Therefore it would have to automatically construct the interface from the information read from
the configuration file. When the GUI application reads a device configuration file it then decides what widgets
it needs to tailor the interface for the command or monitored variable that it must provide.
Most of the devices we use provide a simple interface that is normally a stream of ASCII characters for
receiving and sending messages. This has the advantage of being easy to test and debug using just a terminal.
In most cases, all you need is to send a short stream of ASCII characters containing a command to configure
some setting on the device. Or to ask it to send back a reply with the value for some input value such as a
temperature sensor. The format for these commands are normally trivial. An example of for the command to
read back the temperature sensor value in Kelvin for a sensor input on a Lakeshore 218 device is shown below.
The input is the number of the sensor input, CR and LF are the ASCII control characters for carriage
return and line feed, and +nn.nnn represents the numerical value format that is given in the reply. PyDevCom
provides support for hexadecimal, ASCII and a special ASCII control character syntax.
Command =⇒ KRDG?inputCRLF
Reply ⇐= +nn.nnnCRLF
When a device is being used there are two kinds of logging that need to be performed. Logging of how the
device is being used during normal operations is especially useful for testing and debugging problems. The other
kind of logging is the archiving of status information retrieved whilst monitoring devices. PyDevCom supports
both of those logging requirements.
3. CONFIGURATION IS AT THE HEART OF PYDEVCOM
As mentioned in section 1, the key requirement for PyDevCom was to deliver an application that was highly
configurable if it was going to be reusable with different devices. It also had to be relatively quick and easy to
create new configurations for new devices. This would require a lot of thought and consideration about how best
to achieve a good configuration format that met these requirements. The decision was made to use the Extensible
Mark-up Language (XML) document format for configuring the application. XML is a general purpose mark-up
Proc. of SPIE Vol. 7019 701914-3

language capable of describing many types of data. Or put simply XML is a way of describing data. It is for
these reasons that it was chosen for the document format for this application.
• Well formed documents can be produced that are relatively human-legible making it easier to learn
• XML is now ubiquitous throughout the web and and other software technologies
• XML is well supported by popular programming languages and utility applications
• There are schema language formats available for validating XML document formats
Remote device configuration files written in the XML format are fundamental to how the PyDevCom appli-
cation works. Each remote device that is controlled by PyDevCom must have its own configuration file. The
configuration file contains all the information about how to communicate with the device. This includes the
information regarding the connection protocol as well as the data format for commands and replies. PyDevCom
was purposely designed to be highly configurable in this way to maximise re-usability of the application for
future use. The design of the file format was driven by trying to provide as much flexibility and functionality
as possible whilst always bearing in mind that the application should be easy to use even for non experienced
programmers. Hopefully this balance has been achieved as well as producing an application that can be used
for communicating with a wide range of devices whilst possibly including other types of devices that were not
originally envisaged.
3.1 Device Configuration File Description
A tree describing the hierarchy of the main XML element nodes that make up a configuration file is shown in
figure 1. At the top of the tree is the XML document’s root node element which is the Device node. It is the
parent node of all the other sub nodes that collectively specify the interface for communicating with the remote
device.
The Device node has name and description attributes which are self explanatory. Each device that is loaded
must have a unique name so it can be identified. The Device node must contain a Communication node which
specifies that communication protocol to be used and the necessary configuration information for setting up a
remote connection to the device for that protocol. At this time TCP/IP and RS232 protocols are supported
with plans for USB support although others may be added in the future. The node also allows the user to
define delimiter bytes that can be added to outgoing messages and stripped off from incoming messages. This
is useful as it is common for remote devices to wrap up data messages with control byte codes for handling
communications. The device may contain two further types of sub nodes that are optional. One is the Control
node which is used for specifying the interface for controlling the remote device by defining operations that send
commands and interpret replies. The other is the Monitor node that specifies the interface for monitoring the
device and retrieving status information.
The Control, Monitor and the Container nodes have similar properties. In the source code the Control,
Monitor and Container nodes are classes derived from the same parent class. The Container node’s purpose
is what its name suggests. It is used for grouping together sub element nodes that are all of the same type. You
may choose to use a Container for grouping together child nodes that share a common purpose. For example,
you may have a group of Operation nodes that are used to set-up and configure a device and another group
of operations that are used for controlling the device after it is set-up and in its normal operational state. A
Container can also have child nodes that are Container nodes as well. This is useful for creating a hierarchy
of Operation or Variable node groups.
The Control and Monitor nodes are like Container nodes but with extra properties. A Control node can
have multiple Container or Operation nodes as child nodes. This rule also applies to child Container nodes of
the Control node. It is used to group together operations that are used for controlling the device interactively.
The Monitor node can have multiple Container or Variable nodes as child nodes. As with the Control node
the same rule applies to child Container nodes. It is used for monitoring the status of the device. For example,
periodically reading the sensor values of a temperature monitoring device at regular time intervals.
Proc. of SPIE Vol. 7019 701914-4

nd
eter
onaI)
onaI)
Figure 1. The PyDevCom device configuration XML document element node structure
Also, both the Control node and the Monitor node can have a Logging node but it is optional. This node
is responsible for specifying the logging criteria such as the name of the log file for storing log messages or data.
If the Logging node is not included then it is assumed that logging is not required. The logging for the control
part of the system logs operational events during run time. The logging for the monitor part focuses on archiving
status information.
The Monitor node has one other unique child node that is a Command node. These Command nodes are used for
retrieving status information from the remote device. Several commands can be specified to accumulate status
information from the remote device. The data retrieved from these commands is then parsed by the monitor’s
Variable child nodes.
An Operation node contains information about sending commands to and receiving replies from the re-
mote device. All operations must specify name and description attribute values that describe its purpose. An
Operation offers a lot of flexibility for defining a sequence of Command child nodes that can use several parame-
ters as defined in the Parameter child node(s). A Parameter node has attributes for specifying a default value,
keyword value pairs and expressions for converting/modifying the parameter value. The keyword value pairs
are used to provide human readable values that can be substituted by values that the device understands. The
expressions can be used for converting the parameter’s units. The Reply child nodes are used for interpreting
Proc. of SPIE Vol. 7019 701914-5

the different types of reply from the device to the commands.
A Variable node declares some kind of status value that is being monitored on the remote device. Again, all
variables must specify name and description attribute values that describe what the variable’s value is used for.
For example, a temperature monitor device will have temperature sensor values that can be read by sending a
command that results in an array of temperature values in specific units being sent in reply. A Variable node
is defined for each sensor value which includes information about how to extract the value from the reply data.
Similarly to the operation’s Parameter nodes, the variable has attributes for keyword value pairs and expressions
for converting/modifying the variable’s value. These attributes are useful for providing human readable values
and/or changing the value’s units. The commands that are sent to the device to generate the reply status data
is defined in the Monitor node as well as the interval period between status updates.
3.2 A Short Example From A Device Configuration File
XML element nodes can contain sub elements which are also referred to as child elements. An example is shown
in the XML text shown below. Here we have a parentElement that contains a childElement. Notice that the
child element contains data and that the parent element does not. Although in XML it is possible for the parent
element to contain both data and child elements the conventionusedinPyDevComisthatanelementmay
contain only data or child elements but not both. This is an important feature that is strongly related to the
way in which the source code has been designed. More information about how the configuration file structure
maps onto the software design is given in section 3.3. In PyDevCom an XML element that contains data is
referred to as an attribute of the parent element.
<parentElement>
<childElement>Child element data</childElement>
</parentElement>
In the following block of XML text we can see an actual snippet of XML taken from a real device configuration
fileforatemperaturemonitordevice. This block of XML describes a command sent to the device for reading
back the sensor temperature values in Kelvin units as shown in section 2. It shows an Operation element which
allows the user to define a command or several commands with several parameter values to be sent to the remote
device and the format of the various types of replies that might be received from the device in response to
the commands. The Operation is a parent element which consists of numerous child elements. The Name and
Description elements that contain data are attributes of the Operation.TheOperation, shown in the listing
below, also contains three types of child elements that are also parent elements. These elements are Command,
Parameter and Reply. Not all of the attribute elements shown in this example are required and can be used
optionally by the author of the device configuration file.
<Operation>
<Name>Get Kelvin Reading</Name>
<Description>Get sensor(s) Kelvin value reading</Description>
<Command>
<Timeout>5.0</Timeout>
<Message>KRDG? PAR1</Message>
<Replies>All</Replies>
</Command>
<Parameter>
<Identifier>PAR1</Identifier>
<Description>Sensor input</Description>
<Default>All Sensors</Default>
<Substitute>All Sensors:0,Sensor 1:1,Sensor 2:2,Sensor 3:3,Sensor 4:4</Substitute>
</Parameter>
<Reply>
<Identifier>RP1</Identifier>
Proc. of SPIE Vol. 7019 701914-6

<Status>Success</Status>
<Expression>.+</Expression>
<Message>Got sensor(s) Kelvin values</Message>
</Reply>
</Operation>
The Command element has three attributes. The first of these is the time out period in seconds for the
command execution time. If the device fails to reply to the command within the allocated time it will be
assumed that the command has failed. The Message attribute is the actual data sent to the device to tell it to
execute the command. Notice that the message contains ‘PAR1’ which matches the Identifier attribute value
of the Parameter element. This means that the parameter’s value will used to replace the identifier when the
message is sent to the device. The Replies element lists the Identifier attribute values of the Reply elements
that are applicable to this command. In this case the value ‘All’ means that all Reply elements are applicable
regardless of their Identifier value.
The Parameter element’s Identifier attribute is used in the command’s Message attribute as described the
previous paragraph. The Description attribute provides an explanation to the user about what the parameter
is for. The Default attribute states the default value for the parameter that is used in the event that a parameter
value is not supplied when the operation is executed. The Substitute attribute is a list of keyword value pairs
that is very useful for presenting the user with a human readable values which can then be substituted with
values that the device understands. Notice that the default value ‘All Sensors’ is one of the substitute values
and therefore in the event that a parameter value is not supplied the value ‘0’ will be used in the message sent
as part of the command to the device. Therefore actual the command string sent to the device using the default
parameter value would be ‘KRDG? 0’.
The Reply element specifies what type of reply we can expect from the device in response to the command.
In this case, if we receive a reply at all from the device to this particular command then we can safely assume
that the device has understood the command and has sent us a reply that is the temperature sensor values
we asked for. Otherwise, the device will not reply and the command will timeout and it will be assumed that
the command failed which would be correct. The reply’s Identifier attribute matches the value used in the
command element’s Replies attribute so we know this reply is associated with that command. The Status
attribute can be configured as ‘Success’, ‘Warning’ or ‘Failure’ which reflects the outcome of the command
judging by the reply from the device. The Expression attribute accepts a regular expression value which is
used for pattern matching the value sent from device to this reply element. The expression ‘.+’ in Python
programming language will accept one or more of any characters. The Message attribute is a human readable
message associate with this reply that can be used to explain the outcome or meaning of the message sent back
from the device.
Although the sample of XML used in this example does not demonstrate it. The configuration file also
supports hexadecimal and control character codes. The syntax for inserting hexadecimal values is ‘#x0a0b;’
where the hexadecimal values are prefixed with ‘#x’ and suffixed with a ‘;’. Also, the ASCII control character
codes can be specified from a table where ‘[CR]’ and ‘[ACK]’ are examples of the carriage return and acknowledge
control characters. This feature allows greater flexibility for specifying messages used in commands to and replies
from devices.
Operations may contain a sequence of several commands that may have numerous parameters that result in
numerous replies with different values. This allows the device configuration file author to construct larger and
more complicated operations for controlling and monitoring devices. Admittedly, a full and complete interface
for a complicated device can result in a large configuration file. This process can be made less painful by using
an XML editor which automatically checks the validity of the configuration file using the available XML schema
file. But using a configuration file that has a flexible structure for describing the interface to a device is still a
lot quicker than writing new code to do the same job. The advantage of having a common file structure is that
it provides the software developer with the opportunity to develop framework around this structure that can be
reused for different device configuration files. This is the main advantage of using the PyDevCom application.
PyDevCom offers several features that are available to all devices configured in this way as they all share similar
properties.
Proc. of SPIE Vol. 7019 701914-7

3.3 The Relationship between the Configuration File Structure and the Code Design
The way in which the XML format is used in the configuration files has been chosen deliberately to improve ease
of use and understanding of how the application’s code has been designed. By reading the configuration file it
is easy for a developer to understand what data is a new object or an attribute belonging to an object in the
source code.
Figure 2. Class diagram for the core PyDevCom application
PyDevCom is written in the python programming language which is an object orientated programming
language. The classes in the core PyDevCom application map onto the XML nodes in the configuration file. As
described in the previous section, all child elements are attributes of the parent element. An attribute that has
child elements of its own is an object. These object elements are defined as classes in the PyDevCom application.
This can be seen by comparing the class diagram in figure 2 and comparing the names of classes with the names
of XML elements in figure 1. Although they are not shown in the diagram the classes have the same attributes
as defined in the XML configuration file format. Of course, there are additional classes and attributes used in
the source code to help implement the functionality of the application. When the device configuration file is
loaded an instance of each object is created in the application for every instance defined in the configuration
file. The reason for the strong mapping of the configuration file format with the source code design is to make
it easier for developers to access the source code. Improving the accessibility of the code is very appealing for
future developers who may wish to extend and adapt the application to add more features or wider support for
other devices.
Proc. of SPIE Vol. 7019 701914-8

4. HOW TO WRITE SCRIPTS FOR TESTING DEVICES
One of most important requirements for PyDevCom was to provide a flexible interface that supported automated
testing. The design solution for this was choosing to use the Python programming language for developing the
application. Python is a scripting programming language that is easy to learn and fast for writing code. Python
applications can be executed without spending time compiling and linking files. This is makes it very convenient
for using in lab conditions where newly written test scripts can be created and executed quickly.
The following example shows the core PyDevCom application being used interactively in a python terminal
session. The PyDevCom application’s Device module is imported and the device configuration file for a Lakeshore
218 temperature monitor device is open and read. After reading the device configuration file we can now execute
operations for controlling the remote device. The example shows the operation for configuring the input curve
for sensor input 3 being executed. Another operation to read back the input curve value for the sensor 3 is
executed to verify it is set to the correct value. Note that the value returned ‘1’ is how the device represents the
input curve for a diode. The executeOperation method takes the name of the operation as it first argument
followed be a variable list of arguments that apply to that particular operation. A monitor thread is started that
will continually monitor the status of the temperature monitor device’s sensors. A reference to the Variable
object for sensor 3 is obtained and the description, units and value attributes for the variable are printed out to
the terminal.
% python
...
>>> import Device
>>> ls218 = Device.Device()
>>> ls218.readConfigFile(’../xml/ls218.xml’)
>>> ls218.executeOperation(’Configure:Set Input Curve’, ’Sensor 3’, ’Diode’)
(’Success’, ’Command sent successfully’, [])
>>> ls218.executeOperation(’Status:Get Input Curve’, ’Sensor 3’)
(’Success’, ’Got sensor input curve’, [’1’])
>>> ls218.startMonitor()
>>> sensor3 = ls218.getMonitor().getVariable(’Sensor Temperatures:Sensor 3’)
>>> print sensor3.getDescription()
Sensor input 3 temperature
>>> print sensor3.getUnits()
Kelvin
>>> print sensor3.getValue()
107.0
The above example is a simple one to give a taste of how easy it is to get started with PyDevCom using
a python terminal but more sophisticated test scripts can be written. PyDevCom has been used for testing
mechanisms in the lab for reliability and accuracy. These tests repeated a sequence of movements continuously
over long period of time and logged measurement data for analysis.
5. WXPYDEVCOM GUI OVERVIEW
The core PyDevCom application provides python modules that can used in scripts or included in other ap-
plications. Using the Jython platform also allows it to used in Java application environments as described in
section 2. Naturally, we need a GUI that allows us to interactively use the remote device. The GUI displays
the monitored status information for a device and makes it easy to initiate operations on a device. Therefore we
have a GUI that is another layer of software that runs above the core application. It supports multiple instances
of pydevcom by being able to load several instances of device configuration files. This allows the user to control
and monitor several devices in one application. It also allows the devices to share a common framework that
provides additional features for interfacing with the device. The main features are listed below.
Proc. of SPIE Vol. 7019 701914-9

Eile yiew Help
Lakeshore 218 star picker 1 UltraCam
Monitor Status Information
Status Good
Theta Pwis—
[1-Motion Status-
Move in Progres STAND STILL Position
PyDevCom (Generic Device Cammnnication Application)
Last update 15:14:31 Failed Attempts S
M icronwitch Status-
Home
-Phi Pueis
1-Motbon Status—
MoveinPmgres
INACTIVS Reverse Limit
UtiIi Peed
Sequencers plot i [uenceC
______________
Indeo = I Device
Dperation
Parameterr
STAND STILL Position
Home
200000 velocity
INAcTIvS Forward Limit INACTIvS
200000 velocity
INAcTIvS Forward Limit INACTIvSINACTIvS Reverse Limit
-Dripper--
Arm
RSTCTSD law
PDM
Setup Device I Configure Pwes F Move Pwes 1 Dripper
PrimaryReference__[ l5ec0ndaYereel
jogging
] [o
Set Relative
] [-iooooo
Set Absolute
] [ooooo
[o
[-iSSOSS ]
[200000
3
-
Lakeshore 218
Configure :Set Input Curve
flSensor
4
-
Lakeshore 218
Configure :Set Input Status
flSensor
5
-
Lakeshore 218
Configure :Set Input Type
flSensor
8
-
Lakeshore 218 Status :Det Input Curve
flSensor
7
-
Lakeshore 218 Status :Det Input Status
flSensor
8
-
Lakeshore 218
Status :Det Input Type
flSensor
S
-
Lakeshore 218 Status :Det Kelvin Reading
pAll Sens
10
-
Star Picker Setup Device:Reset Controller
[]
11
-
StarPicker
Setup Device:Download Programn
[]
12
-
Star Picker Configure Pwes:Reverse Limit
fl5000!
13
-
Star Picker Configure Aees:Forward Limit
P855555
14
-
Star Picker Configure Aees:Motor Power
[!DN!, !D
15
-
Star Picker Configure Aees:Home Switch
[!PRIMAR
18
-
Star Picker
Configure Pwes:Acceleration
p20480!,
17
-
Star Picker
Configure Aees:Deceleration
'20480',
18
-
Star Picker
Configure Aees:Speed
fl20000',
18
-
Star Picker Move Puees :Primary Reference
[]
20
-
Sequencer
Wad 10 seconds None
21
-
Star Picker Move Pwes :Set Absolute
['200000
22
-
Star Picker
Move Pwes:Move [2 steps)
[]
23
-
Sequencer
Repeat 10 times None
24
-
Star Picker Move Puees :Set Relative
['100000
25
-
Star Picker
Move en:Move [2 steps)
[]
28
-
Star Picker Move Puees :Set Relative
['- 10000
27
-
Star Picker
Move Pwen:Move [2 steps)
[]
28
-
Sequencer Sndofrepeat
None
28
-
Star Picker Move Pwes:Set Absolute
['200000
-
Star Picker
Move Pwes:Move [2 steps)
[]
Move
[
Move(2steps)
]
Stop
Logging Panel
R]3°
I>] [r I>]
Indeo Date-Time Level I Status
Type
Device
Dperation Parameters I Reply
75 2008-05-23 15:11:52 Success
Reply
Star Picker Move Aces :Move [2 steps) Successful move with backlash correction :['MDvSPIS DK']
78 2008-05-23 15:11:52 Information
Dperation
Star Picker Move Pwes :Set Absolute
['200000', '200000']
77 2008-05-23 15:11:52 Success
Reply
Star Picker Move Aces :Set Absolute
Successful absolute position update:[':']
78 2008-05-23 15:11:52 Information
Dperation
Star Picker Move Aces :Move [2 steps)
[]
78 2008-05-23 15:11:53 Success
<
Reply
Star Picker Move Aces :Move [2 steps) Successful move with backlash correction :['MDvSPIS DK']
1>1
• Uses wxPython which is portable over MS Windows, Apple OSX and Linux GTK
• Device GUI constructed from information in configuration files
• Support for plug-in devices (write your own plug-in). Plug-ins can extend CPython using C/C++.
• Sequencer for automating control of devices (open/save sequence files)
• Plotting monitored variables
• Logging and alarm handling
• Lightweight instrument control system
The GUI is written using the wxPython
3
toolkit which has been ported to most popular platforms. It attempts
to use native widgets wherever it can and generally tries to emulate the native look and feel of that platform.
A screen shot of the GUI is shown in figure 3. When a device configuration file is read a new device panel is
added to the central pane’s notebook. The new device panel is automatically constructed using information
from the configuration file. Particular widgets are used and arranged to represent the structure of the container,
operation, parameter and variable elements from the device file. There is no need to write any code for a new
device as the configuration file is all the user needs.
Figure 3. A screenshot of the GUI for wxPyDevCom
Proc. of SPIE Vol. 7019 701914-10

However, should users wish to develop their own customised device panel then they can do this by coding
their own plug-in that can be loaded by the wxPyDevCom application. Support for customised plug-ins is useful
for users who wish add an interface to a remote device who’s interface cannot be supported by the PyDevCom
configuration file format. An example of this exists where a plug-in for interfacing with the UltraCam
4
camera
controller system (also developed at the UK ATC) has been written. The interface for UltraCam uses the HTTP
protocol for sending messages in XML which is beyond the scope of what is supported in PyDevCom. But by
using the API provided in wxPyDevCom the plug-in is also able to share access to features provided for other
devices. Users may decide to write a plug-in because they want to use a customised interface for their device
instead of the one automatically generated. They can do this whilst still using the core PyDevCom application
to interface with the device. The CPython interpreter can also be extended by modules written in C/C++
programming languages. Therefore for time critical components performance does not need to be compromised
completely by using an interpreted language.
The operation sequencer can be seen in figure 3 in the pane on the top right side. The sequencer has the
appearance of the play list and has travel buttons you would expect to find in many desktop media player
applications. This has the benefit of presenting most users with an interface that they are likely to be familiar
with and will hopefully find intuitive to use. The sequencer can be used in similar way as a media application
but has some important differences. Of course, instead of playing back media the sequencer executes operations.
These operations are those defined as part of the interface from the device configuration files. Operations can
be added to the sequence by enabling the record button and activating the operations in the device panels.
The sequencer records the operations that are initiated by the actions of the user on the device panels. The
user can also select operations from an operation choice dialog panel. Operations can be enabled, disabled,
added, deleted, cut, copied and pasted in the sequencer. There are also special sequence operations for adding
repeat loops, timed delays and executing system commands. The sequencer also supports loading sequences of
operations from and saving to files.
wxPydevCom will eventually provide support for plotting monitored variables. This is very useful for plotting
values from temperature sensors and pressure gauges which is something that is very important for instruments
that have a cryostat. The user can select multiple monitored variables from a variable tree list dialog panel.
There are two types of logging that are required for remote devices. There is logging of device operations for
tracking the commands to and replies from the device whilst it being used. There is also archiving status infor-
mation from the device for recording data from sensors and other inputs. As well as logging status information
another very useful feature is support for configuring alarm handling so alarms are triggered when monitored
variables exceed configurable limits to alert the user about potential problems. There is already support for
both of these types of logging in the core PyDevCom application. Further work needs to done for including and
extending existing logging support in wxPyDevCom. The logging of operations can be seen in the bottom pane
of figure 3.
6. FUTURE DEVELOPMENT
At the moment the core PyDevCom code base has been written to be compatible with Python version 2.1 which
at the time of development was the latest version of the Python programming language support by the Jython
project. Hopefully Jython will make a version 2.5 compatible release this year and PyDevCom will be updated
to take advantage of new features available in python.
The device configuration file format is likely to evolve. As more and more devices are used with PyDevCom
they are likely to throw up new problems that may require extending the format support to support these
devices. The file format is extensible and over time it likely that it will mature to include more improvements
for supporting new features for interfacing with remote devices.
All the features described in the previous section describing the GUI provided by wxPyDevCom can combine
to provide a lightweight instrument control system. The flexibility and range of features provided will hopefully
make for a very adaptable application that will find a number of uses in the future.
Proc. of SPIE Vol. 7019 701914-11

REFERENCES
[1] Beard, S. M. and Rambold, W. N., “Model for the development of instrument control software using EPICS,”
in [Advanced Telescope and Instrumentation Control Software ], Lewis, H., ed., Proc. SPIE 4009, 250–261
(2000).
[2] Hastings, P., Howat, S. R., Spanoudakis, P., van den Brink, R., Norrie, C., Clarke, D., Laidlaw, K., McLay,
S., Pragt, J., Schnetler, H., and Zago, L., “A scalable pick-off technology for multi-object instruments (Pro-
ceedings Paper),” in [Optomechanical Technologies for Astronomy], Lemke, E. A.-E. J. A. D., ed., Proc. SPIE
6273, 62732X–1 to 62732X–12 (2006).
[3] Rappin, N. and Dunn, R., [wxPython in Action], Manning Publications, Greenwich (2006).
[4] Beard, S., Vick, A., Atkinson, D., Dhillon, V., Marsh, T., McLay, S., Stevenson, M., and Tierney, C., “The
Ultracam camera and control and data acquisition system,” in [Advanced Telescope and Instrumentation
Control Softwar e], Lewis, H., ed., Proc. SPIE 4848, 218–229 (2002).
Proc. of SPIE Vol. 7019 701914-12