Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 8 Mar 2012 10:33:51 -0600

Hi Emmanuel,

On 2012-03-08 Dirk Zimoch wrote:
> This looks strange. Are you sure that your link has the correct type,
> e.g. INST_IO, not CONSTANT, PV_LINK or CA_LINK or something like this?
> 
> Do you check psi->inp.type before you parse the value?

This is important, and explains what you're seeing if the device support being 
used for the record is the default "Soft Channel".  When dbPutString() parses 
a string for an INP or OUT field for which the device support selected says 
the link type is CONSTANT (which is what soft channel support uses), the link 
field becomes a struct pv_link.  The first member of a struct pv_link is the 
PV name extracted from that string, which ends at the first space character.  
That matches what you're seeing:

> Emmanuel Mayssat wrote:
> >
> > It turns out this method doesn't work correctly anymore.
> > Indeed the psi->inp.value.instio.string is truncated at the first
> > 'space' char.
> > In my case, that means, it cannot scanf the 'df= ...'
> > I also noticed that I now have to include the '@' char, when before I
> > didn't have to.

Only the record's device support is supposed to be looking at that data.  The 
particular device support selected using the record's DTYP field controls what 
kind of address to expect in the INP field using the device() DBD entry.  Note 
that in versions of Base before 3.14.12 the DTYP field of a record must be set 
before its INP field in the .db file.

> > That change appeared between 3.14.8 and 3.14.11
> >
> > What is the correct way to read the INP field now?

It sounds to me that you need to write your own device support for the 
stringin record which has the address type INST_IO.

- Andrew
-- 
Never interrupt your enemy when he is making a mistake.
-- Napoleon Bonaparte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System