Hi,
Here is my test on linux-x86_64 arch, using pcaspy 0.7.0 anaconda
package from https://anaconda.org/paulscherrerinstitute/pcaspy
It does not reproduce the problem. Any chance that you could test using
the same setup?
#### start the pcaspy server using anaconda python
$ source /home/scratch/miniconda/bin/activate
$ conda install -c paulscherrerinstitute pcaspy
$ python test.py
#### start camonitor
$ pwd
/home/scratch/base-3.15.5
$ ./bin/linux-x86_64/camonitor T1:TEST-{A,B,C,D}
T1:TEST-A 2017-11-03 10:07:14.817723 0 UDF INVALID
T1:TEST-B 2017-11-03 10:07:14.817748 0 UDF INVALID
T1:TEST-C 2017-11-03 10:07:14.817738 0 UDF INVALID
T1:TEST-D 2017-11-03 10:07:14.817757 0 UDF INVALID
#### caput
$ ./bin/linux-x86_64/caput T1:TEST-A 1
Old : T1:TEST-A 0
New : T1:TEST-A 1
#### the output from camonitor
T1:TEST-A 2017-11-03 10:07:50.314596 1
Best
Xiaoqiang
On 11/02/2017 10:14 PM, Jameson Graef Rollins wrote:
Hi, all. I'm noticing a strange behavior when using the camonitor
command line tool in EPICS 3.15. I'm seeing a behavior change
between 3.15 and 3.14.
I have a test pcaspy IOC running that is serving four channels. (As
an aside, I am also slightly suspicious that the problem could be in
pcaspy, but I'm not sure). I launch the IOC, so it has so far seen
no client connections. I then connect with camonitor:
$ camonitor T1:TEST-{A,B,C,D} T1:TEST-A
2017-11-02 13:57:42.126037 0 T1:TEST-B
2017-11-02 13:57:42.126067 0 T1:TEST-C
2017-11-02 13:57:42.126055 0 T1:TEST-D
2017-11-02 13:57:42.126082 0
So far so good. I then use caput to change one the values, but
camonitor outputs something for all channels it's monitoring, even
the ones that haven't changed:
T1:TEST-A 2017-11-02 13:57:50.067417 1 T1:TEST-C
2017-11-02 13:57:42.126055 0 T1:TEST-B
2017-11-02 13:57:42.126067 0 T1:TEST-D
2017-11-02 13:57:42.126082 0
Note that this here is specifically what I see as the problem:
camonitor is reporting changes on channels that have no changes.
This is different behavior than I was seeing in 3.14.
If I think do another put, I only see the one channel change:
T1:TEST-A 2017-11-02 13:57:55.484140 2
If I kill camonitor and reconnect things seem to work as expected:
$ camonitor T1:TEST-{A,B,C,D} T1:TEST-A
2017-11-02 14:06:30.586715 2 T1:TEST-B
2017-11-02 14:02:11.625264 0 T1:TEST-C
2017-11-02 14:02:11.625251 0 T1:TEST-D
2017-11-02 14:02:11.625278 0
When I do a put only the one channel changes:
T1:TEST-A 2017-11-02 14:06:47.025503 3
I don't see this behavior with the pyepics epics.camonitor function.
That would seem to point to it being an issue with camonitor cli.
However the fact that things behave as expected on subsequent
connections makes me think it might be pcaspy startup issue.
Any ideas?
jamie.
#!/usr/bin/env python
from pcaspy import Driver, SimpleServer
prefix = 'T1:TEST-'
pvdb = {
'A' : {},
'B' : {},
'C' : {},
'D' : {},
}
class myDriver(Driver):
def __init__(self):
super(myDriver, self).__init__()
if __name__ == '__main__':
server = SimpleServer()
server.createPV(prefix, pvdb)
driver = myDriver()
# process CA transactions
while True:
server.process(0.1)
- Replies:
- Re: issue with either camonitor or pcaspy in 3.15? Jameson Graef Rollins
- References:
- issue with either camonitor or pcaspy in 3.15? Jameson Graef Rollins
- Navigate by Date:
- Prev:
RE: concurrent put callbacks Andrew C. Starritt
- Next:
Anyone else using Bira Ethernet Power Supply Controllers? Dunning, Michael
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
<2017>
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
issue with either camonitor or pcaspy in 3.15? Jameson Graef Rollins
- Next:
Re: issue with either camonitor or pcaspy in 3.15? Jameson Graef Rollins
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
<2017>
2018
2019
2020
2021
2022
2023
2024
|