Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Thu, 27 May 2010 13:08:34 +0200

Hi Carl
The simple but frustrating fact is: You cannot run anything with dynamic
data types or array sizes through the gateway.
This is because CA does not support data type changes yet. This
information is only fetched once at connection time. Thus a client must
disconnect and reconnect to run with the updated data type. The gateway
is a client that keeps the connection for two more hours after the last
client disconnected (Though this timeout can be modified with an
environment variable).
So at the moment only this approach works:

1. Close ALL clients accessing the waveform. (You must be sure that
really every client has disconnected, not only yours.)

2. reboot the IOC

3. Wait for 2 hours

4. restart the client.
If you are not patient enough but have access can restart the gateway:
1. Reboot the IOC
2. Restart the gateway
Sorry about these bad news.
Dirk
Carl Schumann wrote:

Hi,
It turns out the IOC changes the element count on the PV dynamically, so rebooting would present some issues:
1. The required frequency and determining when one is required.   The element count appears to be the product of two PV's values which may be changed by users at any time.
2. Disruption to other connections.   What does EPICS do if anything to reestablish connections when a machine along the connection is rebooted?
Thanks,
Carl
----- Original Message -----
From: Jeff Hill <[email protected]>
Date: Friday, May 21, 2010 3:30 pm
Subject: RE: PV's element count differs though CA gateway
To: 'Carl Schumann' <[email protected]>, [email protected], 'Dehong Zhang' <[email protected]>
Cc: 'Salah J Chaurize' <[email protected]>, "'Denise S. Finstrom'" <[email protected]>
Hi Carl,
I suspect that the gateway has been attached to that PV for a long
time, and

that it learned a maximum element count when it initially connected
which is

no longer accurate. Rebooting the IOC or restarting the gateway, whichever

is easiest, might help. Also, note that services (a waveform record in
an

IOC in this case presumably) generally report a maximum element count
when

the client connects, but can choose to return a lesser current amount
of

elements later as appropriate. 
PS: I am out the door on the way to Oxford for the codeathon Saturday

afternoon, and since the rules here say that I can't take my smart
card out

of country then I will not have email access for some weeks after
that, but

perhaps I will see you at the EPICS meeting.
Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107
Message content: TSPA
-----Original Message-----
From: [email protected] [mailto:tech-talk-
[email protected]] On Behalf Of Carl Schumann
Sent: Friday, May 21, 2010 1:15 PM
To: [email protected]; Dehong Zhang
Cc: Salah J Chaurize; Denise S. Finstrom
Subject: PV's element count differs though CA gateway
Tech-talk, Dehong Zhang,
We have a client application which attempts to access a PV's

elements 0

to 999 .   This application is run on two sets of machines.   One set
must go through an EPICS gateway to access the PV.  The other set does
not do so.    The application does not run properly when going through
the gateway because of an out-of-bounds error at element 940.   It is
able to access elements all they way up to 999 without issue when there
is no gateway involved.
We were able to track this issue down to a difference in the element

count reported by the originating IOC vs. the gateway using cainfo.

For the gateway case cainfo reports element count 940, but for the

non-gateway case cainfo reports 1000. Using EPICS_CA_ADDR_LIST we

were able to reproduce both element counts on a single machine depending

on whether the gateway or the originating IOC responded. The

result is

attached.
Me and my co-workers find this result unexpected and are not sure

how to

fix it. Any help would be appreciated please. Thanks for your time.
Sincerely,
Carl Schumann
P.S.: for my co-worker Dehong owner of the hins_ws.py:

The client is hins_ws.py. The PV is PD_LEBT:Inst:WS1.RST1. It is

the

out-of-bound error that prevents the Save Result button from generating
a file.   Do have any insight about what might be going on here?  Thanks.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System