Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Tue, 7 Nov 1995 15:52:45 -0600 (CST)

Yesterday Ben-Chin Cha wrote:

> I found out that in general that the caget in ezcaIDL is
> 3 times slower than CaIDL.
> In case 1 a caget is repeated 100 times on an AI record, in case 2 a 
> caget is repeated 100 times on a waveform record with float type with 4000 
> elements ...
>                   CaIDL             ezcaIDL
> 
> Case 1             1 sec             4 sec
> Case 2             3 sec             9 sec

This is simply incorrect.  These results were the result of using the ezca
default timeout of .05 seconds.  The correct comparison is with a very short
timeout in ezca.  In this case the following results are obtained on a 
Sparc LX.
                   CaIDL              ezcaIDL

Case 1             0.72 sec            0.83 sec
Case 2             3.05 sec            3.16 sec

Thus, ezcaIDL is at worst 10% slower than CaIDL.

The benchmark programs which produced these results are:

For ezcaIDL:
    casettimeout, 1.e-6
    t1 = systime(1)
    for i=1, 100 do s = caget('13BMA:test_ai', value)
    t2 = systime(1)
    print, 'Elapsed time for caget on AI: ', t2-t1
    t1 = systime(1)
    for i=1, 100 do s = caget('camac_wf1', value)
    t2 = systime(1)
    print, 'Elapsed time for caget on 4000 element waveform: ', t2-t1
    end

For CaIDL:
    t1 = systime(1)
    for i=1, 100 do s = caget('13BMA:test_ai')
    t2 = systime(1)
    print, 'Elapsed time for caget on AI: ', t2-t1
    t1 = systime(1)
    for i=1, 100 do s = caget('camac_wf1')
    t2 = systime(1)
    print, 'Elapsed time for caget on 4000 element waveform: ', t2-t1
    end

> I also found out that the startgroup and endgroup can not handle
> do loop get correctly in ezcaIDL (example is attached at the end.) 
> If I use array with the 'do loop' it always return 0 (for double 
> type PVs) or null string for the requested PV array. If I tried 
> to redo array get for string type, ezcaIDL core dumped.  

> PRO realarray_ezca,pvnames             ; this will not work in ezcaIDL
> no = n_elements(pvnames)
> val = make_array(no,/double)
> castartgroup
> for i=0,no-1 do begin
>         st = caget(pvnames(i),val(i))
> end
> print,caendgroup()
> for i=0,no-1 do begin
> print,pvnames(i),val(i)
> end
> END

This example reflects a basic misunderstanding of how IDL works. In IDL the
statement:
        st = caget(pvnames(i),val(i))
passes the value of val(i), not a pointer to val(i). Thus, caget() cannot
return anything into val(i) using this syntax.  It is completely analagous to 
C - one would have to specify &val(i) to get a return value back in C. IDL
does not have an "address-of" operator.

Ben-Chin is correct that in ezcaIDL one cannot read an array of values, each
from a different process variable, inside an asynchronous group.   However,
one can read values into individual IDL variables, as she illustrated.

In CaIDL there are signficant restrictions on operations which can be done in
"asynchronous groups", i.e. between calls to ca_pend_event():

- caget() of a list of process variables can only return an array of doubles 
  or an array of strings. It is not possible to return  other data types, and a
  single call to caget() can only return all doubles or all strings.

- It is not possible to have an asynchronous caget() of a process variable 
  which is itself an array (e.g. waveform record)

Neither of these restrictions are present in ezcaIDL.

____________________________________________________________
Mark Rivers                             (312) 702-2279 (office)
CARS                                    (312) 702-9951 (secretary)
Univ. of Chicago                        (312) 702-5454 (FAX)
5640 S. Ellis Ave.                      (708) 922-0499 (home)
Chicago, IL 60637                       [email protected] (Internet) 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System