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
