Hi Jeremy,
From your pyEPICS call, there are a number of layers:
1) Your server (not sure which one this uses)
2) Channel Access server - 2-4 steps are what we would call EPICS comm time < 1 msec
network
3) Channel Access Client
4) EPICS database housing the device - this could have a scan time that could contribute to the delay
- - what is the SCAN field of the record you are getting?
5) EPICS Device Support - this could be immediate for register based devices to slow for GPIB
6) EPICS driver - this matches the time of the hardware and can either read ahead or on
demand and then wait for the hardware.
7) hardware - whatever the protocol response time there is to this - or time to
next trigger
For 200 msecs, the first place I would look is in the scan rate of the database record.