Hi Mark,
A couple things I can think of off hand are:
1. Issue casr command on IOCs and see if they connect to any other IOCs
2. You might try running caSnooper to see if there are CA search requests for
the disconnected PVs
Providing that the IOCs are within the same subnet your EPICS environment
variables appear to be fine. I am assuming that you have no channel access
security files being loaded on any of your IOCs.
The only other thing that I can think of doing for now is to run a Wireshark
trace as one of the IOCs boot. Then you should be able to see the CA search
requests and subsequent replies. If you do this and need the Wireshark plugin
for CA I do have one built for wireshark-1.8.10 but could probably build it
for a newer release if needed.
Marty
On 01/12/2017 06:38 AM, Mark Rivers wrote:
Folks,
We are having problems with all of our vxWorks IOCs. We recently upgraded from base 3.14.12.5 to 3.14.12.6. We have not changed the version of vxWorks, which is 6.9.4.1. We did update the Linux server on which we build and boot the IOCs from Fedora 15 to Centos 7.
The IOCs work fine as CA servers, all Linux and Windows clients can connect to them fine. But the IOCs are not working as CA clients. All records with CA links to other IOCs fail to connect, they have STAT=LINK. SNL programs can connect to local PVs but not to PVs on other IOCs. This is true whether the IOC hosting the target PV is running on Linux or VxWorks.
Here is an example where the DOL field points to a valid PV in another VxWorks IOC. When I test the record it has STAT=LINK.
ioc13idc> dbtr "13IDC:filter:EnergyBeamline",10
ACKS: INVALID ACKT: YES ADEL: 0
ALST: 74.9806201550387 AOFF: 0 ASG:
ASLO: 0 BKPT: 00 DESC: 13-ID-C Filters beamline energy
DISA: 0 DISP: 0 DISS: NO_ALARM DISV: 1
DOL:CA_LINK 13BMC:m1.RBV NPP NMS DRVH: 0 DRVL: 0
DTYP: Soft Channel EGU: EGUF: 0 EGUL: 0
EOFF: 0 ESLO: 1 EVNT: 0
FLNK:DB_LINK 13IDC:filter:Energy HHSV: NO_ALARM HIGH: 0
HIHI: 0 HOPR: 0 HSV: NO_ALARM HYST: 0
INIT: 0 IVOA: Continue normally IVOV: 0
LALM: 74.9806201550387 LBRK: 0 LCNT: 0
LINR: NO CONVERSION LLSV: NO_ALARM LOLO: 0 LOPR: 0
LOW: 0 LSV: NO_ALARM MDEL: 0
MLST: 74.9806201550387 NAME: 13IDC:filter:EnergyBeamline
NSEV: NO_ALARM NSTA: NO_ALARM OIF: Full OMOD: 0
OMSL: closed_loop ORAW: 75 ORBV: 0 OROC: 0
OUT:CONSTANT OVAL: 74.9806201550387 PACT: 0
PHAS: 0 PINI: NO PREC: 4 PRIO: LOW
PROC: 1 PUTF: 0 PVAL: 74.9806201550387
RBV: 0 ROFF: 0 RPRO: 0 RVAL: 75
SCAN: Passive SDIS:CONSTANT SEVR: INVALID SIML:CONSTANT
SIMM: NO SIMS: NO_ALARM SIOL:CONSTANT STAT: LINK
TIME: 2017-01-11 18:11:02.007588962 TPRO: 0 TSE: 0
TSEL:CONSTANT UDF: 0 VAL: 74.9806201550387
value = 0 = 0x0
However, that 13BMC:m1.RBV PV works fine from Linux caget:
corvette:~/support/CARS/iocBoot>caget 13BMC:m1.RBV
13BMC:m1.RBV -0.856875
The record above works fine with CP links as long as the PVs are local to that IOC.
This is on a different IOC where the SNL program connects fine to local PVs, but fails to connect to the 2 PVs that are in another IOC.
epics> seqShow BM13_Energy -
State Program: "BM13_Energy"
thread priority = 50
number of state sets = 1
number of syncQ queues = 0
number of channels = 26
number of channels assigned = 26
number of channels connected = 24
number of channels monitored = 24
options: async=0, debug=0, newef=1, reent=0, conn=1
State Set: "Energy"
thread name = BM13_Energy; Thread id = 0x211e110
First state = "init"
Current state = "init"
Previous state = "init"
Elapsed time since state was entered = -Inf seconds
Wake up delay = Inf seconds
Get in progress = [00000000000000000000000000]
Put in progress = [00000000000000000000000000]
epics> seqChanShow BM13_Energy -
State Program: "BM13_Energy"
Number of channels=26
View: State set Energy
#14 of 26:
Variable name: "xt_ht"
type = double
count = 1
Value = 0
Assigned to "13BMD:m22.VAL"
Not connected
Monitored
Not sync'ed
Status = -2
Severity = -1
Message = disconnected
Time stamp = <undefined>
Next? (+/- skip count)
This is the output of epicsPrtEnvParams:
ioc13idc> epicsPrtEnvParams
EPICS_AR_PORT: 7002
EPICS_CAS_AUTO_BEACON_ADDR_LIST is undefined
EPICS_CAS_BEACON_ADDR_LIST is undefined
EPICS_CAS_BEACON_PERIOD is undefined
EPICS_CAS_BEACON_PORT is undefined
EPICS_CAS_IGNORE_ADDR_LIST is undefined
EPICS_CAS_INTF_ADDR_LIST is undefined
EPICS_CAS_SERVER_PORT is undefined
EPICS_CA_ADDR_LIST is undefined
EPICS_CA_AUTO_ADDR_LIST: YES
EPICS_CA_BEACON_PERIOD: 15.0
EPICS_CA_CONN_TMO: 30.0
EPICS_CA_MAX_ARRAY_BYTES: 88000
EPICS_CA_MAX_SEARCH_PERIOD: 300.0
EPICS_CA_NAME_SERVERS is undefined
EPICS_CA_REPEATER_PORT: 5065
EPICS_CA_SERVER_PORT: 5064
EPICS_CMD_PROTO_PORT is undefined
EPICS_IOC_LOG_FILE_COMMAND is undefined
EPICS_IOC_LOG_FILE_LIMIT: 1000000
EPICS_IOC_LOG_FILE_NAME is undefined
EPICS_IOC_LOG_INET: 164.54.160.182
EPICS_IOC_LOG_PORT: 7004
EPICS_TIMEZONE: CUS::360:031302:110602
EPICS_TS_NTP_INET is undefined
IOCSH_HISTSIZE: 50
IOCSH_PS1: epics>
value = 0 = 0x0
This is the output of the "version" and "coreRelease" commands on vxWorks.
ioc13bma> version
VxWorks (for Motorola MVME2700 - MPC 750) version 6.9.4.1.
Kernel: WIND version 2.13.
Made on Jul 27 2015 17:59:12.
Boot line:
dc(0,0)corvette:/usr/local/vw/VX6941/mv2700-dev6-debug e=164.54.160.74:ffffff00 h=164.54.160.82 u=iocboot tn=ioc13bma s=/home/epics/support/CARS/iocBoot/ioc13bma/st.cmd
value = 180 = 0xb4
ioc13bma> coreRelease
############################################################################
## EPICS R3.14.12.6
## EPICS Base built Jan 9 2017
############################################################################
value = 0 = 0x0
ioc13bma>
Any ideas on what the problem could be and any diagnostics to run to track it down?
Thanks,
Mark
- References:
- Problems with vxWorks IOCs on base 3.14.12.6 Mark Rivers
- Navigate by Date:
- Prev:
Problems with vxWorks IOCs on base 3.14.12.6 Mark Rivers
- Next:
Support for Queensgate NPC-D-5110DS piezo controller edmund.warrick
- 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:
Problems with vxWorks IOCs on base 3.14.12.6 Mark Rivers
- Next:
Re: Problems with vxWorks IOCs on base 3.14.12.6 Michael Davidsaver
- 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
|