Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Mon, 7 Dec 2009 10:23:28 -0600

Eric Norum wrote:
>
> 1) I think that caget does not require the '-d LONG' since specifying -0x
> (or b or o) sets  type = DBR_LONG; anyway.

It might internally (I haven't looked at the code), but it doesn't display the 
result using 0x.  My experience matches Ernest's:

tux% cainfo anjHost:compressExample.N
anjHost:compressExample.N
    State:            connected
    Host:             tux:5064
    Access:           read, write
    Native data type: DBF_DOUBLE
    Request type:     DBR_DOUBLE
    Element count:    1
tux% caget -0x anjHost:compressExample.N
anjHost:compressExample.N      23
tux% caget -d LONG -0x anjHost:compressExample.N
anjHost:compressExample.N
    Native data type: DBF_DOUBLE
    Request type:     DBR_LONG
    Element count:    1
    Value:            0x17

> 2) The getopt format string in camonitor does have "d:" in it, but
> there's no corresponding "case 'd':'"statement in the following switch
> statement.  An oversight, perhaps? Could the option-handling code from
> caget.c be copied to camonitor.c?

That might trigger a question of how to display the results for the structured 
types.  Currently camonitor outputs one line per monitor event and only 
supports a limited number of data types with a fixed output format.  If we 
allow -d the tool would have to break one of those assumptions.  In this case 
I suspect making the -0 option always make DBR_LONG requests for a DBF_DOUBLE 
or DBF_FLOAT type would resolve this problem without needing us to add -d 
support.

Maybe Stephanie could work with Ralph (who maintains catools) to develop a 
solution?

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harald Welte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System