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  2018  2019  2020  2021  2022  2023  2024  <2025 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  <2025
<== Date ==> <== Thread ==>

Subject: Re: Update IOC with pushed data
From: "Kasemir, Kay via Tech-talk" <tech-talk at aps.anl.gov>
To: Dave Bracey <dbracey at fnal.gov>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Tue, 10 Jun 2025 16:07:39 +0000

 

We would like data to travel through an IOC with as little latency as possible. Can I use Event Scanning rather than Periodic to achieve this? At one point I tried having a data source use a User-Defined Event to trigger record processing, but

> We would like data to travel through an IOC with as little latency as possible.  Can I use Event Scanning rather than Periodic to achieve this? 

 

Yes, event or I/O Interrupt scanning would be the way to minimize latency.

 

> At one point I tried having a data source use a User-Defined Event to trigger record processing, but I didn’t get it working at that time.

 

Should be easy to test:

# File test.db

record(ai, "test")

{

   field(SCAN, "Event")

   field(EVNT, "42")

   field(TPRO, "1")

}

 

Run `softIocPVX -d test.db`.

In the IOC shell, type `postEvent 42` and you’ll see a log message that the record was processed.

 

The trick would then be to get that event generated without you having to type “postEvent 42” all the time.

If you have a timing system, it might emit events. Or you might be able to use the “event” record to generate the event, and the processing of the event record in turn may be triggered by your timing system.

 

> I’m assuming this is the idea behind I/O Interrupt Event triggering – the record is triggered to process on new I/O, and the Device or Driver handler reads the data from the data source.

 

With I/O interrupt, you don’t have to pick an event ID like the 42 in the above example and then worry about posting that event.

Device support modules that support I/O scanning allow you to basically say this:

 

record(ai, “test”)

{

   field(DTYP, “SomeDeviceSupport”)

   field(INP, “Something that makes sense to SomeDeviceSupport”)

   field(SCAN, “I/O Intr”)

 

… and now SomeDeviceSupport will read from your hardware and magically process the record whenever there’s a new value.

For an example, see stream device, which can read data via network or serial connection and then process your record whenever it receives a new value,

https://paulscherrerinstitute.github.io/StreamDevice/processing.html#iointr

 

 

 


Replies:
RE: Update IOC with pushed data Mark Rivers via Tech-talk
References:
Update IOC with pushed data Dave Bracey via Tech-talk

Navigate by Date:
Prev: Update IOC with pushed data Dave Bracey via Tech-talk
Next: Retiga E7 and ADKinetix John Dobbins via Tech-talk
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  <2025
Navigate by Thread:
Prev: Update IOC with pushed data Dave Bracey via Tech-talk
Next: RE: Update IOC with pushed data Mark Rivers via Tech-talk
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  <2025
ANJ, 10 Jun 2025 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions ·
· Download · Search · IRMIS · Talk · Documents · Links · Licensing ·