Closed LeeYangLBLBCS closed 1 year ago
I just configured the ADSimDetector to generate images, enabled the NDPluginPva, and started a pvaDriver. They are able to communicate fine.
In your screen shot the text entry widget for the PV Name is empty, although there is a readback. What happens if you type 13SIM1:Pva1:Image there and press Enter?
This is what my screen looks like
In my case I did not type the PV name, that was remembered by autosave. Note that it does appear in the text entry widget. All I did was start acquisition in both the SIM and PVA drivers.
Comparing the MEDM screens, my ADPvaDriver.adl does not match yours. The other two on the left, simDetector.adl and NDPva.adl look correct.
Note that you are getting these 2 errors after iocInit:
2023/03/23 22:36:22.183 pvaDriver::connectPv exception initializing monitor: 0 or empty channel name
2023-03-23T22:36:22.214 ServerContext configured with no Providers will do nothing!
Your commonPlugins.cmd has these lines commented out:
# Optional: load NDPluginPva plugin
#NDPvaConfigure("PVA1", $(QSIZE), 0, "$(PORT)", 0, $(PREFIX)Pva1:Image, 0, 0, 0)
#dbLoadRecords("NDPva.template", "P=$(PREFIX),R=Pva1:, PORT=PVA1,ADDR=0,TIMEOUT=1,NDARRAY_PORT=$(PORT)")
# Must start PVA server if this is enabled
#startPVAServer
You don't need to load the PVA plugin if you don't want it, but I think you need to uncomment startPVAServer line, or add that line to st.cmd.
Your ADPvaDriver.adl
screen, in the pvaDriver section, shows a (PVA) PV name of 13SIM1:image1
. Might that be 13SIM1:Pva1:Image
instead? That's what my ADSimDetector instance publishes. (My IOC prefix is ad:
while yours is 13SIM1:
, here is my console):
(base) prjemian@zap:~$ pvinfo ad:image1
Timeout
ad:image1 Error: channel destroyed
(base) prjemian@zap:~$ pvinfo ad:Pva1:Image
ad:Pva1:Image
Server: 192.168.144.97:5075
Type:
epics:nt/NTNDArray:1.0
union value
boolean[] booleanValue
byte[] byteValue
short[] shortValue
int[] intValue
long[] longValue
ubyte[] ubyteValue
ushort[] ushortValue
uint[] uintValue
ulong[] ulongValue
float[] floatValue
double[] doubleValue
codec_t codec
string name
any parameters
long compressedSize
long uncompressedSize
dimension_t[] dimension
dimension_t
int size
int offset
int fullSize
int binning
boolean reverse
int uniqueId
time_t dataTimeStamp
long secondsPastEpoch
int nanoseconds
int userTag
epics:nt/NTAttribute:1.0[] attribute
epics:nt/NTAttribute:1.0
string name
any value
string descriptor
int sourceType
string source
string descriptor
alarm_t alarm
int severity
int status
string message
time_t timeStamp
long secondsPastEpoch
int nanoseconds
int userTag
display_t display
double limitLow
double limitHigh
string description
string format
string units
BTW, Mark's screen also shows the 13SIM1:Pva1:Image
PV name.
thnaks - that fixed the problem. set PVName=13SIM1:Pva1:Image
PVAServer is started on the ADSimDetector IOC (shown below). Does it also need to be started on PVADriver IOC?
The log I showed was for PVADriver IOC, where "startPVAServer" was commented out.
# Optional: load NDPluginPva plugin
NDPvaConfigure("PVA1", 20, 0, "SIM1", 0, 13SIM1:Pva1:Image, 0, 0, 0)
dbLoadRecords("/opt/epics/base-7.0.4/../modules/synApps_6_1_epics7/support/areaDetector-R3-7/ADCore/ADApp/Db/NDPva.template", "P=13SIM1:,R=Pva1:, PORT=PVA1,ADDR=0,TIMEOUT=1,NDARRAY_PORT=SIM1")
# Must start PVA server if this is enabled
startPVAServer
2023-03-25T09:20:18.587 Using dynamically assigned TCP port 53419.
I think I was wrong about needing to start the PVA server. That is only needed for NDPluginPva (which is a PVA server), not for pvaDriver (which is a PV access client).
I agree. You should start the PVA server only if you want your PVADriver IOC to be a relay (mirror, republisher, gateway, whatever) for the 13SIM1:Pva1:Image
. I can imagine a few circumstances you might want such a relay:
Imagine this network topology:
[ADsimDetector IOC] [pvaDriver IOC]
[camera IOC] --> [relay IOC] --> client(s)
[camera subnet] | [client subnet]
The relay IOC has access to PVs from IOCs on both the camera subnet and the client subnet. The client subnet PVs could be additional metadata to contribute (via an attributes.xml file) to the image republished from the relay IOC.
AFter starting PVA IOC, the PV Connection status is always Down. MEDM screen attached below, followed by IOC startup log.