Experimental Physics and
Industrial Control System

Gabriel de Souza Fedel <[email protected]> · 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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System