Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 12 Jun 2008 10:56:50 -0500

On Wednesday 11 June 2008 17:25:35 Szalata, Zenon M. wrote:
> I have observed the following undesirable behavior in a combination of
> longout record and a EDM Text Control widget set to display format "Hex":
> When I enter the value 0x80000000 in the text control, it gets converted in
> the record to 0x7fffffff.  I suppose that either the EDM widget or the
> epics longout record perform signed conversion.  But why 0x7fffffff?  I
> have tested this on a pure software IOC running on Linux.  Now, when I
> enter 0x80000000 I want that to be the value in the record.  Is it possible
> that longout is not appropriate for this?  If so, what record type should I
> use?

Assuming you're using the target architecture linux-x86 and not linux-x86_64 
(which is known to not work properly), your longout.VAL field is a signed 
32-bit integer, which can hold values from -2147483648 to 2147483647 decimal. 
In hex, those values are -0x80000000 through 0x7fffffff but note the sign on 
the one - it's negative.  It is not possible to express the value +2147483648 
as a signed 32-bit integer, although as an unsigned number its hex 
representation is 0x80000000.  Note that CA doesn't support unsigned types; 
there is no DBF_ULONG available to CA clients, although the IOC side does 
implement this type, which CA transports using a DBF_DOUBLE.

Can you enter the value -0x80000000 properly into your EDM Text Control?

I'm not sure precisely where your value is being clipped, but I would suspect 
EDM since the IOC doesn't do numeric conversions of hex numbers sent over CA 
as a DBF_STRING.

HTH,

- Andrew
-- 
Talk is cheap. Show me the code. -- Linus Torvalds

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System