Experimental Physics and
Industrial Control System

<[email protected]> · Mon, 15 Feb 2010 16:53:56 -0000

Hi,

In a recent exchange between Dirk and us about streamDevice, Dirk
pointed out one way in which stringout is different to other base output
records - it won't call device support if UDF is true.

Is this deliberate or a bug? If it is a bug, should we fix it because it
will result in a behaviour change?

I can see a viable argument that the opposite should be true - device
support shouldn't be called if UDF is true. A third alternative is that
the  decision should be deferred to device support.

I know stringout is different to other standard output records because
constant links can't be strings, because strings resolve as db or CA
links. The workaround is to put the string into VAL and make OMSL
supervisory. This should actually solve our problem (because UDF won't
be true anymore), but I was wondering whether there was any reasoning
behind the current implementation.

Cheers,

Nick Rees
Principal Software Engineer           Phone: +44 (0)1235-778430
Diamond Light Source                  Fax:   +44 (0)1235-446713
-----Original Message-----
From: Dirk Zimoch [mailto:[email protected]] 
Sent: 02 February 2010 08:29
To: Cobb, Tom (DLSLtd,RAL,DIA)
Cc: Pratt, Linda (DLSLtd,RAL,DIA); Rees, Nick (DLSLtd,RAL,DIA)
Subject: Re: StreamDevice bug

Hi Tom,

You found a bug in the stringout record (not in stream device). The 
stringout record does not process its output link as long as it is UDF. 
Once you wrote to the VAL field it works. Setting DOL to a *numeric* 
value solves the problem.

The relevant code is here: (src/rec/stringoutRecord.c)

static long process(pstringout)
	struct stringoutRecord	*pstringout;
{
...
         if(pstringout->udf == TRUE ){
                 recGblSetSevr(pstringout,UDF_ALARM,INVALID_ALARM);
                 goto finish;
         }

         if (pstringout->nsev < INVALID_ALARM )
                 status=writeValue(pstringout); /* write the new value
*/
         else {
...

No other record has such "if(pstringout->udf == TRUE )" code.

Best regards,
Dirk

[email protected] wrote:
> Hi,
> 
> We've been doing some testing of our modules, and uncovered a minor
bug
> in streamDevice, I wonder if you've seen it before?
> 
> Symptoms:
> Processing a stringout record that runs a function without a format
> convertor has no effect. Ao, bo and longout records all work fine.
> 
> Example:
> 
> Database:
> record(ao, "TESTSTREAM:ao")
> {
>     field(DTYP, "stream")
>     field(OUT,  "@test.proto reseed streamDeviceAsyn")
> }
> 
> record(bo, "TESTSTREAM:bo")
> {
>     field(DTYP, "stream")
>     field(OUT,  "@test.proto reseed streamDeviceAsyn")
> }
> 
> record(longout, "TESTSTREAM:longout")
> {
>     field(DTYP, "stream")
>     field(OUT,  "@test.proto reseed streamDeviceAsyn")
> }
> 
> record(stringout, "TESTSTREAM:stringout")
> {
>     field(DTYP, "stream")
>     field(OUT,  "@test.proto reseed streamDeviceAsyn")
> }
> 
> Protocol file:
> reseed { out "SYSTEM:RESEED" ; }
> 
> Test:
> Sniffing the serial line reveals that a "caput TESTSTREAM:ao.PROC 1"
> sends "SYSTEM:RESEED", but a "caput TESTSTREAM:stringout.PROC 1" sends
> nothing.
> 
> Any ideas?
> 
> Thanks,
> Tom Cobb,
> Diamond Light Source Ltd.
> Diamond House
> Harwell Science and Innovation Campus
> Didcot
> Oxfordshire
> OX11 0DE
> Tel +44 (0) 1235 778582
> 

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System