EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Latency between NI LabVIEW RT (cRIO) and EPICS on RT Linux
From: "Johannes Spinneken (EGI)" <[email protected]>
To: "[email protected]" <[email protected]>
Date: Tue, 6 Feb 2018 19:33:13 +0000

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

 

 

 

 


Replies:
Re: Latency between NI LabVIEW RT (cRIO) and EPICS on RT Linux Mooney, Tim M.
Re: Latency between NI LabVIEW RT (cRIO) and EPICS on RT Linux Gabriel de Souza Fedel

Navigate by Date:
Prev: RE: procServ under systemd service Mazanec Tomáš
Next: EtherCAT newbie question Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: procServ under systemd service Ralph Lange
Next: Re: Latency between NI LabVIEW RT (cRIO) and EPICS on RT Linux Mooney, Tim M.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
ANJ, 09 Feb 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·