Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Mon, 03 Nov 2008 10:39:30 +0100

Hi Zen,
First of all, it does not make much sense to read that array as a huge string
with StreamDevice and then to use a genSub to convert it to float. StreamDevice
has been designed to do conversions. Please see the StreamDevice documentation
for waveform records.
Then, when reading without InTerminator (and probably a short ReadTimeout) any
interruption in the input is "end of string". Such interruptions may occur
because the GPIB data stream is wrapped into packages for IP transfer and long
arrays may need two or more packages.
In principle, StreamDevice together with asynDriver implements a "atomic"
transfer. The communication port is locked until the transfer is done. But with
InTerminator="", you tell the system: "Whenever input is a bit late, then the
transfer is done.
You say the data is ASCII coded floating point. In that format, it is usually
terminated properly and separated by comma. Then, the protocol should look like
this:
rTDCh12 {
  Separator=",";
  out "TRAC:SOUR CH\$1;:TRAC\$1:INDEX 1;:TRAC\$1:AVER:DATA?";
  in "%f";
}
The waveform should be of type DOUBLE or FLOAT.
The %f in the format is repeated until no further input is found or until NELM
points have been read, whatever occurs first. NORD is set accordingly.

ASCII is usually a quite inefficient encoding for huge waveforms. Often devices
offer a "raw" format, (e.g. 2 byte integer). This format is not terminated
because raw input may consist of CR LF bytes. However, it has a fixed input
length. Often is is prefixed by a header that defines the input length.
Unfortunately StreamDevice cannot interpret this header. (This would be
something for a asyn interpose layer, I guess). But you can easily calculate the
size yourself. If the header looks like this "#800001000" the total input size
is 1010 (10+2*500). And you can use a format like this:
  InTerminator="";
  MaxInput=1010;
  in "#800001000%2r";
The waveform should be of type SHORT. You may then use a acalcout record
(->SynApps) to convert the waveform to float.
Best regards,
Dirk

Szalata, Zenon M. wrote:

I have two GPIB instruments attached to ICS 8065 Ethernet - GPIB Controller (according to the manual this device is a replacement for the Agilent E2050 and E5810). I have written two soft IOC's to control and monitor two instruments (one is Agilent 33220A Waveform Generator, the other is Boonton 4500B RF Peak Power Analyzer). Both IOC programs use epics R3-14-9, asyn R4-9, and streamdevice R2-3. The 33220A IOC has a records with SCAN="1 second", which reads the status byte. The 4500B IOC has a waveform record with SCAN="5 second", which is used to read waveform data, a stream of ASCII coded floating point values. The waveform consists of 500 data points. This stream of data is converted to floating point data in a genSub record.
The 4500B IOC program performs flawlessly when it is the only one running. When the 33220A IOC program is also running, the waveform data read by the 4500B IOC gets corrupted from time to time. I interpret what is happening as follows: while the waveform data is being read, the other IOC program requests a status byte and somehow these two concurrent operations interfere with each other. How can I solve this? Is it possible to make reading the waveform an atomic operation (i.e. uninterruptable)?
I am using the following streamdevice protocol for reading the waveform:
rTDCh12{ InTerminator="";  out "TRAC:SOUR CH\$1;:TRAC\$1:INDEX 1;:TRAC\$1:AVER:DATA?"; in "%10000c";}
Any suggestions will be greatly appreciated.
Zen

--
Dr. Dirk Zimoch
Paul Scherrer Institut, WBGB/006
5232 Villigen PSI, Switzerland
Phone +41 56 310 5182

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System