Hi
I am fairly new to EPICS and have been testing an application with the
following setup:
* National Instruments cRIO running an EPICS server
* EPICS client on RT Linux (fully preemptible Kernel 4.9.76) using
EPICS base libs (C application)
* PV write on cRIO in LabVIEW RT, with new data at 1ms intervals
(using 1ms timed loop)
* Read of EPICS PV in RT Linux with loop times <1ms
* Posting data back to another EPICS PV to then be read as “round
trip” timing on cRIO
The setup works in principle, but I am seeing higher latencies than I
was expecting. I was hoping to achieve latencies in the low ms order
(say 1 – 2ms data round trip from cRIO to RT Linux back to cRIO). In
practice, I observe round-trip timings of order 10ms. Two questions:
(i)What is the best timing (latency) that can generally be achieved
using EPICS? Is there something fundamental in the protocol that
prohibits data exchange in the low ms order? I understand that this will
of course depend on target hardware / software, but a ballpark figure
would be good as “expectation management”. A typical ping between cRIO
and Linux RT takes approx. 0.2ms, so the hardware seems clearly capable
of <1ms timings.
(ii)Does anyone have experience with running EPICS on LabVIEW RT / cRIO?
I suspect some (most) of the latency is due to the way in which NI
handles TCP traffic. I already discovered that data is normally buffered
for 10ms (or 8 kB). This can be avoided by using the Shared Variable
Data Flush VI:
http://zone.ni.com/reference/en-XX/help/371361H-01/lvcomm/flushsharedvar/
which indeed reduced round-trip timings by around 8-10ms. However, I
seem to be unable to push timings down further below the 10ms round-trip
mark. Any guidance would be much appreciated.
Many thanks!
Best wishes
Johannes
Johannes Spinneken PhD FRSA
/Principal Systems Engineer/
*Evergreen Innovations UK & USA*
+1 916 266 3709 (US cell)
+44 7868 923583 (UK mobile)
www.evergreeninnovations.co <http://www.evergreeninnovations.co/>
