Developing a LabVIEW DataSocket-Driven Sequencer

Author(s):
Oliver Shafer - E2V Technologies

Industry:
Imaging Equipment

Products:
LabVIEW

The Challenge:
Implementing real-time measurement and control and rapidly transferring data in our test environment.

The Solution:
Using NI DataSocket enabled us to share live data with other LabVIEW applications at a greater data transfer rate through a network connection.

E2V Technologies (E2V)
E2V, formerly Marconi Applied Technologies, is one of the world’s leading designers and manufacturers of solid-state imaging devices. Since 1980, we have been manufacturing charged coupled device (CCD) sensors at our Chelmsford UK site for a wide range of demanding applications, including the Hubble Telescope and real-time dental x-rays.

Project Introduction
Slowscan 5 is the new production test camera for E2V CCDs controlled by NI LabVIEW. We used a Pulse Instruments (PI) sequencer unit to generate the clock signals for the CCDs. The sequencer runs via the PIs in-house software application, PI-Pat, where timer files are generated graphically on a Windows NT operating system contained within the sequencer PC.

Because we needed all project specific data and user control to be performed and stored on a separate image acquisition PC, this PC had to control the PI sequencer PC.

The standard method for driving the PI sequencer is to load a timer file onto a version of PI-Pat running remotely on the image acquisition PC. The remote PI-Pat sends the data via General Purpose Interface Bus (GPIB) to a version of PI-Pat running on the sequencer PC, which then drives the sequencer.

GPIB Restrictions
Our initial aim was for LabVIEW to control the sequencer from the image acquisition PC. We achieved this by running PI-Pat on both PCs and controlling the remote PI-Pat from LabVIEW via OLE automation. This enabled timer files to be sent via the GPIB connection to the sequencer PI-Pat, which then drove the sequencer.

When large timer files transferred to the sequencer, there was a considerable delay between loading a timer file in LabVIEW and the actual implementation by the sequencer. This occurred because we converted the timer file from PI file format to GPIB code on the acquisition processor. The data was then sent to the sequencer’s processor and converted from GPIB back to PI file format. In the final stage, PI-Pat sent the timer file to the sequencer for hardware implementation.

Enabling GPIB Alternatives
The resulting step was to reduce the time needed to send a timer file to the sequencer. We networked the image acquisition and sequencer PC, which allowed us to investigate other methods of data transfer.

Using LabVIEW DataSocket
DataSocket provides live data exchange between different applications on one computer or between computers connected through a network. DataSocket is a programming tool designed to share and publish real-time data in many applications.

E2V used the DataSocket Transport Protocol (DSTP) to read and write data across our stand-alone network. When we use the DSTP, the DataSocket Server communicates with any virtual instrument (VI). This allows the VI to publish or subscribe to data. We can identify different types of data through tag names, which append to the URL address.

Using DataSocket, we sent commands to the sequencer via the network rather than GPIB, even when using LabVIEW executables. This improved our data transfer efficiency by up to 500 percent.

System Design
The next target was to completely control the sequencer via the network from a VI on the acquisition PC. We achieved this by publishing data from a VI on the acquisition PC to a subscribing VI on the sequencer PC. The VI then drove the sequencer by OLE Automation.

Every variable on the user VI, such as run, stop, and load timer file, contained a different URL tag, so the subscriber could distinguish it.

The timer files were copied across the network to the sequencer PC in PI file format, making the GPIB conversion process redundant and greatly decreasing the time it takes to load a timer file and run it on the sequencer.

We also developed a feature that loads user selected timer files copied to the sequencer PC into PI-Pat and stacks the files. In the event that a timer file is selected again, it will be available in the sequencer’s memory.

When the user selects sequencer shutdown from the acquisition PC, it clears the timer file stack, so it only uses the new version of timer files when the system starts.

Design Challenges
We faced a number of challenges in building the DataSocket driven sequencer. First, we found that if we changed a publishing data field before we received the information, DataSocket would overload. This was overcome by disabling the integer control until we completed an error check.

An error check system ensured all the data was being received. However, there were a large number of controls writing data, which meant that each control needed its own DSTP protocol and error checking. We corrected this by bundling all the controls and publishing the data as a cluster, which was then unbundled in the subscriber VI, allowing one DSTP protocol and one error check.

Final Working System
This solution has proved to be very successful. The final system is a sub-VI operating on the acquisition PC. It writes data via DataSocket to a LabVIEW application, which is located on the “Windows start up” menu, and runs on the sequencer PC. This application reads data from the acquisition PC and runs the sequencer software via OLE automation.

Future
The next stage of this part of the project is to connect the stand-alone network to the internet. This will allow us to run the sequence remotely and perform remote image acquisition. A major benefit is enabling development engineers to fault find VIs remotely.

For more information, contact
Oliver Shafer
E2V Technologies
Chelmsford, UK
CM1 2QU
Tel: 01245493493
Fax: 01245453604
E-Mail: oliver.shafer@e2vtechnologies.com
Web: www.e2vtechnologies.com

Browse All Case Studies »