Re: GPIB - asyn - streamdevice

[Dirk Zimoch <dirk.zimoch@psi.ch>]

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