Subject: |
Re: Latency between NI LabVIEW RT (cRIO) and EPICS on RT Linux |
From: |
Gabriel de Souza Fedel <[email protected]> |
To: |
[email protected] |
Date: |
Fri, 9 Feb 2018 14:28:10 -0200 |
Hello Johannes,
The Epics Server Implementation from Labview RT it is very "simple" and
not a very good epics implementation. We tried to use and found many
problems (we don't use it anymore).
Here at LNLS we are using cRIO, and testing epics base inside linux rt.
There is a initiative for cRIO that could be helpfull:
https://github.com/irio-i2a2
Regards
On 06-02-2018 17:33, Johannes Spinneken (EGI) wrote:
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/>
--
Gabriel Fedel
Software de Operação das Linhas de Luz
Laboratório Nacional de Luz Síncrotron – (LNLS)
Centro Nacional de Pesquisa em Energia e Materiais (CNPEM)
[email protected] | +55 (19) 3512 1226
www.lnls.cnpem.br
- References:
- Latency between NI LabVIEW RT (cRIO) and EPICS on RT Linux Johannes Spinneken (EGI)
- Navigate by Date:
- Prev:
Re: Where is histogram? Southern, Tim
- Next:
Re: FLNK length limit Hinko Kocevar
- 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
<2018>
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Latency between NI LabVIEW RT (cRIO) and EPICS on RT Linux Johannes Spinneken (EGI)
- 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
<2018>
2019
2020
2021
2022
2023
2024
|