Re: Latency between NI LabVIEW RT (cRIO) and EPICS on RT Linux

["Mooney, Tim M." <mooney@aps.anl.gov>]

Hi Johannes,

With an interrupt service routine, vxWorks can read from or write to an IndustryPack FPGA at around 10 kHz, but I would not try to process an EPICS record at that rate - at least not a record that isn't prepared to throttle the rate at which it posts monitors.  I don't usually process general purpose EPICS records faster than around 100 Hz.  I think it's pretty common practice to keep stuff faster than around 100 Hz restricted to driver code, which doesn't really have to know about EPICS.

Tim Mooney (mooney@aps.anl.gov) (630)252-5417
Beamline Controls Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab

---

From: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> on behalf of Johannes Spinneken (EGI) <johannes@evergreeninnovations.co>
Sent: Tuesday, February 6, 2018 1:33:13 PM
To: tech-talk@aps.anl.gov
Subject: Latency between NI LabVIEW RT (cRIO) and EPICS on RT Linux

 

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