Experimental Physics and
Industrial Control System

"Szalata, Zenon M." <[email protected]> · Mon, 3 Nov 2008 17:39:52 -0800

Hi Dirk,
Thank you for replying.
First, a little explanation.
The instrument only sends the waveform data as ASCII coded string, no raw data option is available.
I chose to use genSub to reformat the data only because I needed to rescale it by adding offset and multiplying the result by a scale factor.  These come from longin epics records.
I implemented your suggestion for the protocol and also added ReadTimeout=2000 to the protocol.  This unfortunately did not cure the interference I see between the two GPIB instruments as described in my original note.  So, now I have:

--------------------------------------------
record( waveform, "$(P)wfTrCh$(N)Data"){
  field( DESC, "hist$(N) data")
  field( DTYP, "stream")
#  field( DISV, "0")
#  field( SDIS, "$(P)wCh$(N)Enable.VAL  NPP NMS")
  field( INP,  "@rfpmChan.proto rTDCh12($(N)) L$(L) $(A)")
  field( EGU,  "points")
  field( NELM, "1000")
  field( FTVL, "FLOAT")
  field( FLNK, "$(P)gsCh$(N)WForm PP")
}

rTDCh12{   ReadTimeout=2000; Separator=",";
           out "TRAC:SOUR CH\$1;:TRAC\$1:INDEX 1;:TRAC\$1:AVER:DATA?";
           in "%f";}
-------------------------------------------- 
I suppose it is possible that I do not really know how to use the ICS 8065 controller, or that this device has some implementation flaw.

Eric Norum suggested that perhaps merging these two IOC's into one could lead to a working solution.  What do you think?  I have used epicsMutex in a device driver I wrote, but I do not see how to use something like a Mutex on the epics record level.  Of course, a very simple solution would be to use one ICS 8065 Ethernet - GPIB controller for each IOC.
In the one IOC solution it might be possible to carefully arrange record scanning such that no two data reading records can scan simultaneously.  It seems tricky.

Thanks,
Zen

-----Original Message-----
From: Dirk Zimoch [mailto:[email protected]] 
Sent: Monday, November 03, 2008 1:50 AM
To: Szalata, Zenon M.
Cc: EPICS Techtalk
Subject: Re: GPIB - asyn - streamdevice

I forgot to say: Try to increase ReadTimeout until the problem goes away.

Dirk Zimoch wrote:
> 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