Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Thu, 24 Aug 2006 11:23:27 -0500

Hi Pete,

Have you taken a look at the wrappers in ezcaIDL.c?  In addition to
wrappers around all of the ezca functions I added a couple of additional
ones

ezcaIDLGetCountAndType
ezcaIDLGetEnumStrings

I am appending the documentation for the IDL procedure caGetCountAndType
which works around the enum restriction you have encountered, and also
for caGetEnumStrings.

Cheers,
Mark

function caGetCountAndType, pvname, count, type
;+
; NAME:
;       caGetCountAndType
;
; PURPOSE:
;       This function returns the number of elements and data type of a
;       Channel Access process variable.
;
; CATEGORY:
;       EPICS Channel Access Interface
;
; CALLING SEQUENCE:
;       Status = caGetCountAndType(pvname, count, type)
;
; INPUTS:
;       pvname: The name of the process variable for which information
is to
;               be returned.
;
; OUTPUTS:
;       count:  The number of elements in the process variable. This is
1 for
;               scalar process variables and more than 1 for arrays.
;
;       type:   This is a 3 element array containing information about
the data
;               type of the process variable.
;               type(0) = Channel access data type as defined in
"cadef.h"
;               type(1) = EZCA data type as defined in "ezca.h"
;               type(2) = IDL/PV-WAVE data type as defined in size()
;               These data types are as follows:
;
;               Name    Channel Access      EZCA        IDL/PVWAVE
;               String      0                 1             7
;               Short       1                 2             2
;               Float       2                 4             4
;               Enum        3                 2 (short)     2 (short)
;               Byte        4                 0             1
;               Long        5                 3             3
;               Double      6                 5             5
;
;   The function return value of caGetCountAndType is a status value.
The
;   status is 0 if the routine was successful (i.e. the process variable
exists)
;   and non-zero if the routine failed.
;
; SIDE EFFECTS:
;       This routine will cause a Channel Access search to take place if
this is
;       the first time this process variable has been referenced.
;
; RESTRICTIONS:
;       The channel access data type enum is mapped to EZCA and IDL
short
;       data types.  However, application programs can use this routine
to
;       determine if the native channel access data type is enum, and
then
;       use caGet(pvname, value, /string) to read the string equivalent
of the
;       process variable. Programs can also use
;       caGetEnumStrings(pvname, strings) to read the strings for the
all of
;       the possible values of an enum process variable.
;
; PROCEDURE:
;       This routine uses ezcaPvToChid() and then ca_element_count() and
;       ca_field_type().
;       Note that this routine always returns its values "immediately",
even
;       if it is called between a caStartGroup and caEndGroup.
;
; EXAMPLE:
;       IDL> status = caGetCountAndType('test_mca1.VAL', count, type)
;       IDL> print, status
;       0                       ; Status = success
;       IDL> print, count
;       2048                    ; Array with 2048 elements
;       IDL> print, type
;           5       3       3   ; Long data type
; MODIFICATION HISTORY:
;       Written by:     Mark Rivers
;       June 28, 1995
;-

function caGetEnumStrings, pvname, strings
;+
; NAME:
;       caGetEnumStrings
;
; PURPOSE:
;       This function returns all of the choice strings associated with
a
;       Channel Access "enum" process variable. It is particularly
useful
;       for building menus of options.
;
; CATEGORY:
;       EPICS Channel Access Interface
;
; CALLING SEQUENCE:
;       Status = caGetEnumStrings(pvname, strings)
;
; INPUTS:
;       pvname: The name of the process variable for which the enum
strings
;               are to be returned. The native channel access data type
of
;               this process variable must be enum (3).
;
; OUTPUTS:
;       strings: A string array containing the strings for each possible
;               value of the enum variable.
;
;       The function return value of caGetEnumStrings is a status value.
The
;       status is 0 if the routine was successful (i.e. the process
variable
;       exists and is of type enum) and non-zero if the routine failed.
;
; SIDE EFFECTS:
;       This routine causes a channel access read. It does not use the
;       grouping mechanism of EZCA, i.e. it always executes immediately.
;
; RESTRICTIONS:
;       There must be less than MAX_ENUM_STATES enum strings and they
must each be
;       less than MAX_STRING_SIZE characters.
;
; PROCEDURE:
;       This routine uses ezcaPvToChid and then ca_get() with a request
type
;       of DBR_GR_ENUM.  The functionality required by this routine is
not
;       presently provided directly in EZCA, although it should probably
be
;       added.
;
; EXAMPLES:
;       IDL> status = caGetEnumStrings('test_mca1.SCAN', strings)
;       IDL> for i=0, n_elements(strings)-1 do print, strings(i)
;       Passive
;       Event
;       I/O Intr
;       10 second
;       5 second
;       2 second
;       1 second
;       .5 second
;       .2 second
;       .1 second
;
; MODIFICATION HISTORY:
;       Written by:     Mark Rivers
;       June 28, 1995
;-

> -----Original Message-----
> From: D. Peter Siddons [mailto:[email protected]] 
> Sent: Thursday, August 24, 2006 10:24 AM
> To: Andrew Johnson
> Cc: [email protected]
> Subject: Re: ezca and ENUM
> 
> Hi Andrew,
>    Yes, a string would work as well, but I was writing the Octave 
> wrappers for ezca which I'd like to make self-contained and general. 
> This implies asking the record what type it is in order to make calls 
> with the correct type. It would be nice if valid types were 
> treated as 
> such by the library :) As it is, I trap the ENUM type in my 
> wrapper and 
> turn it into a SHORT, and all is well. But it hides what I 
> feel is a bug.
> Pete.
> 
> 
> Andrew Johnson wrote:
> > D. Peter Siddons wrote:
> >> I noticed that the ezca library does not recognize ENUM as a valid 
> >> data type. One can work around that by telling it to use a SHORT 
> >> instead. If 
> > 
> > Would it help to use string data for doing I/O to DBF_ENUM 
> fields?  That 
> > way you don't need to know the exact ENUM definition (which 
> could change 
> > at runtime even for mbbx.VAL fields); your code just uses 
> the strings 
> > for the states that you need to use, and the IOC does the necessary 
> > conversions automatically.
> > 
> > Just an idea,
> > 
> > - Andrew
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System