Re: INP field length

[Dirk Zimoch <dirk.zimoch@psi.ch>]

Hi Steve

I once tested this and found that 78 chars after the @ are possible 
(after macro expansion). However due to CA limitations you cannot read 
the link completely with caget.

For ports without addresses (RS232, TCP) you can skip the " 0" address 
part at the end (saves you 2 chars). Use short names for protocol files, 
protocol names, port names.

Dirk

Steve Kinder wrote:
> Hi Andrew
>
> Thanks for the reply, that was what I thought. But just to clarify my 
> specific case. I'm using StreamDevice2 and have a INP field as follows 
> with template/substitution.
>
> field(INP, "@TEST.protocol getCs($(DEVICE),C2,C3,C4) $(port) 0")
>
> If I understand things correctly, whatever the length of DEVICE and port 
> I shouldn't encounter problems. Well due to the length of the field at 
> least.
>
> Regards
>
> Steve
>
> ----- Original Message ----- From: "Andrew Johnson" <anj@aps.anl.gov>
> To: <tech-talk@aps.anl.gov>
> Cc: "Steve Kinder" <steve@dsoft-solutions.co.uk>
> Sent: Monday, March 15, 2010 3:30 PM
> Subject: Re: INP field length
>
>
> > Hi Steve,
> >
> > On Monday 15 March 2010 04:45:15 Steve Kinder wrote:
> > > Is there any length restriction on an INP field, before or after the
> > > expansion of any macros it may contain?
> >
> > Unlike many places inside the IOC, there is no built-in length 
> > limitation to
> > the value that can be placed in a link field using dbLoadRecords(), which
> > means that the @parm part of a hardware link address can be as long as 
> > you
> > like.
> >
> > Of course if you want to read or update the field through CA there is 
> > a 40
> > character limit to the string you can pass as a DBR_STRING, and with 
> > the new
> > array-of-chars support in 3.14.11 using the @ field modifier I believe 
> > CA will
> > still limit you to passing at most 72 characters to/from a link field.
> >
> > HTH,
> >
> > - Andrew
> > --
> > The best FOSS code is written to be read by other humans -- Harald Welte