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