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  <2026 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  <2026
<== Date ==> <== Thread ==>

Subject: Re: Record TIME field taken from another record's VAL
From: Torsten Bögershausen via Tech-talk <tech-talk at aps.anl.gov>
To: Majer Karel <Karel.Majer at eli-beams.eu>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Tue, 17 Mar 2026 12:58:00 +0100
Hej Karel and all.
It seems as there is a mismatch.
The documentation (our driver) says that the parameter
TS_MS=200
means 200 milliseconds.
It seems,
after digging into the code and the description from Beckhoff,
that we ask for
2000000 msec towards the PLC prgram ?!?
Investigations are ongoing.
BR
/Torsten



On 2026-02-26 13:08, Majer Karel wrote:
Hi Torsten,
Thank you, this makes the impact of the settings clearer.
Best regards,

Karel
------------------------------------------------------------------------
*From:* Torsten Bögershausen <tboegi at edom.se>
*Sent:* Monday, February 23, 2026 5:56 PM
*To:* Majer Karel <Karel.Majer at eli-beams.eu>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>; tboegi at edom.se <tboegi at edom.se>
*Subject:* Re: Record TIME field taken from another record's VAL
Hej Karel,
here is more light from testing:

Having a longin with
ADSPORT=852/TIMEBASE=PLC/T_DLY_MS=500/TS_MS=200/ GVL_PILS.stEL5101CounterValue.nvalue?

... and running camonitor gives, when I move the motor 1 mm:

LabS-MCAG:MC-MCU-1006:EncoderRaw 2026-02-23 17:37:26.395846 4724
LabS-MCAG:MC-MCU-1006:EncoderRaw 2026-02-23 17:37:34.616832 4711
LabS-MCAG:MC-MCU-1006:EncoderRaw 2026-02-23 17:37:34.816508 4690

While pyadsmonitor uses something corresponding to
T_DLY_MS=1/TS_MS=1/
(No, it doesn't use EPICS. I am talking about the parameters for
the notifications, which both epics/twincat-ads and
python/adsmonitor use. See
https://urldefense.us/v3/__https://gitlab.esss.lu.se/mcag/sources/pyads-monitor__;!!G_uCfscf7eWS!Z5cc0MKOQ6tMOAXxqt0xIG8FJXPawJFnRoN7MkmWJRVMYy1Zr_7HYBK6cQvGfEh0rhkVZTtpvFyUT3S19Zk$ <https:// gitlab.esss.lu.se/mcag/sources/pyads-monitor>


stEL5101CounterValue.nvalue         2026-02-23 17:37:34.478 4723
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.518 4722
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.538 4721
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.538 4720
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.566 4719
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.567 4717
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.568 4716
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.579 4715
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.587 4713
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.617 4711
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.617 4710
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.618 4708
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.628 4706
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.638 4705
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.666 4703
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.667 4702
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.668 4700
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.677 4699
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.688 4698
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.717 4696
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.717 4695
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.718 4694
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.728 4693
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.738 4692
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.818 4691
stEL5101CounterValue.nvalue         2026-02-23 17:37:34.818 4690


I hope that this explains things a little bit more ?
/Torsten


On 2026-02-19 10:14, Torsten Bögershausen via Tech-talk wrote:
Hej Karel,

for a second we may need to imagine, how the "notifications" may work:
The client (EPICS) will ask for a notificaton for each PLC variable
we want to monitor.
Now the PLC needs to assemble these notification messages.
Several notifications may be bundled into one message,
that goes over the wire. Especially when they share the same timestamp.
The ADS library inside the IOC will fiddle them apart.
The question, when a notifcation is send, is done in the PLC,
and there should be some code, that compares the old and the new value.
The parameters you are asking for are all defined by Beckhoff.
Because of that, we are reluctant to repeat the documentation.
What we can do, is to provide some best practise, may be.
For a handful of variables I don't expect major problems.
When we use a zillion of variables, things may need some fine tuning,
either in software, or go for faster hardware.

As you know, this is an open source project.
Contributions, feedback or other questions are always welcome.

HTH,
please don't heasitate to ask more questions.
/Torsten



On 2026-02-18 16:04, Majer Karel wrote:
Hello Torsten,

I think some concise overview of the possible options usable in INP and OUT links would be nice. I understand the basic use, but it's not clear to me how the various options for setting poll rate, sample rate and delay work, how sampling rate and delay settings for ads driver interact with these, and if it's important to match PLC cycle time or not.

Best regards,

Karel
------------------------------------------------------------------------
*From:* Torsten Bögershausen <tboegi at edom.se>
*Sent:* Monday, February 16, 2026 11:02 AM
*To:* Majer Karel <Karel.Majer at eli-beams.eu>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
*Subject:* Re: Record TIME field taken from another record's VAL
Hej Karel,

Having examples was so far the most helpful thing that we have.
What do you think/suggest is missing ?
BR
/Torsten


On 2026-02-16 09:29, Majer Karel wrote:
Hello Torsten,

Thanks for your answer.
I think we can handle the the PTP synchronization.
I'm interested in twincat-ads driver which I wasn't aware of. Is there any documentation on it besides the included examples?

Thanks,

Karel
------------------------------------------------------------------------
*From:* Torsten Bögershausen <tboegi at edom.se>
*Sent:* Friday, February 6, 2026 5:26 PM
*To:* Majer Karel <Karel.Majer at eli-beams.eu>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>; tboegi at telia.com <tboegi at telia.com>
*Subject:* Re: Record TIME field taken from another record's VAL
I think that there are 2 questions:
a) can I synchronize TwinCAT with PTP ?
b) can I trasnport timestamps over ADS ?
Yes.
<https://urldefense.us/v3/__https://infosys.beckhoff.com/english.php?
content=..*content*1033*__;Ly8v!!G_uCfscf7eWS!e2Ig-ypHK- _tCLuRgVos2YoEjuSyQSQj1J9wcVPAeL0WvE2Yz0TEkTzRNmcntIpdqUOpy4OIwxYnbAooRXo$ tc3_ads_intro/115883019.html&id= <https://urldefense.us/v3/__https://infosys.beckhoff.com/__;!!
G_uCfscf7eWS!e2Ig-ypHK- _tCLuRgVos2YoEjuSyQSQj1J9wcVPAeL0WvE2Yz0TEkTzRNmcntIpdqUOpy4OIwxYn3PZmGS8$ english.php?content=../content/1033/tc3_ads_intro/115883019.html&id=>>

c) Is there an EPICS driver that support it ?
Yes:
https://urldefense.us/v3/__https://github.com/epics-modules/twincat-
<https://urldefense.us/v3/__https://github.com/epics-modules/twincat->
ads/__;!!G_uCfscf7eWS!e2Ig-ypHK- _tCLuRgVos2YoEjuSyQSQj1J9wcVPAeL0WvE2Yz0TEkTzRNmcntIpdqUOpy4OIwxYnNIwp_Bc$  <https://urldefense.us/v3/__https://github.com/epics-__;!!G_uCfscf7eWS!
e2Ig-ypHK- _tCLuRgVos2YoEjuSyQSQj1J9wcVPAeL0WvE2Yz0TEkTzRNmcntIpdqUOpy4OIwxYnPEsneLY$
modules/twincat-ads/> <https://urldefense.us/v3/__https://github.com/
epics-__;!!G_uCfscf7eWS!e2Ig-ypHK- _tCLuRgVos2YoEjuSyQSQj1J9wcVPAeL0WvE2Yz0TEkTzRNmcntIpdqUOpy4OIwxYnPEsneLY$
modules/twincat-ads/>

But back to a)
TwinCAT has different clocks.
You can synchronize the TwinCAT time (TcTime ??) with NTP.

If you need PTP, then you can synchronize the distributed clock
("DC") with PTP.

All details are tooooo long to describe here.
If you want more details, I am happy to set up
a video meeting.

BR
/Torsten


On 2026-02-06 15:50, Majer Karel via Tech-talk wrote:
Hello,

We have a number of Beckhoff PLCs installed and we are using ADS device support (https://urldefense.us/v3/__https:// epics.cosylab.com/documentation/adsDriver/index.html__;!! G_uCfscf7eWS!e2Ig-ypHK- _tCLuRgVos2YoEjuSyQSQj1J9wcVPAeL0WvE2Yz0TEkTzRNmcntIpdqUOpy4OIwxYnoPsVpG4$ <https://urldefense.us/v3/__https://epics.cosylab.com/documentation/ adsDriver/index.html__;!!G_uCfscf7eWS!euLXnna7-qCt-D3EjV5-bjzosTfKt- sd4lVcov9BLro2tBUjLRx-ed8iuDCVso9vUKL04d9SoJjsUQ8dHHIoBcTCJ3EHAw$>) to talk to them. We have considered synchronizing them with PTP and timestamping PVs with PTP timestamps from the PLC, but it's not clear how to do that of if it's even possible. The ADS protocol does not carry data timestamp (https:// infosys.beckhoff.com/english.php?content=../content/1033/ tcinfosys3/11291871243.html&id= <https://urldefense.us/v3/__https:// infosys.beckhoff.com/english.php? content=..*content*1033*tcinfosys3*11291871243.html&id=__;Ly8vLw!! G_uCfscf7eWS!euLXnna7-qCt-D3EjV5-bjzosTfKt-sd4lVcov9BLro2tBUjLRx- ed8iuDCVso9vUKL04d9SoJjsUQ8dHHIoBcR89fZiHg$>) and the device support documentation doesn't mention possibility of using TSE field to obtain hardware timestamp. My idea was to convert PTP timestamp to double matching EPICS time format, publish it into ai record and use its VAL to set TIME fields of other records published by the ADS IOC. I found some tech talk on Soft Timestamp device support, but I understand it reads from other record's TIME field. Is there a way to use ai VAL field to set TIME of other records?

Thanks,

Karel Majer

*Karel Majer | Senior software developer*
Phone: +420 266 051 514
E-mail: karel.majer at eli-beams.eu



*ELI Beamlines Facility|The Extreme Light Infrastructure ERIC*
Za Radnicí 835, 252 41 Dolní Břežany, The Czech Republic
https://urldefense.us/v3/__http://www.eli-beams.eu__;!!G_uCfscf7eWS!
<https://urldefense.us/v3/__http://www.eli-beams.eu__;!!G_uCfscf7eWS!>
e2Ig-ypHK- _tCLuRgVos2YoEjuSyQSQj1J9wcVPAeL0WvE2Yz0TEkTzRNmcntIpdqUOpy4OIwxYnw2XNBl4$  <https://urldefense.us/v3/__http://www.eli-beams.eu__;!!G_uCfscf7eWS!
e2Ig-ypHK- _tCLuRgVos2YoEjuSyQSQj1J9wcVPAeL0WvE2Yz0TEkTzRNmcntIpdqUOpy4OIwxYnw2XNBl4$ > <https://urldefense.us/v3/__http://www.eli-beams.eu__;!!G_uCfscf7eWS!e2Ig-ypHK-_tCLuRgVos2YoEjuSyQSQj1J9wcVPAeL0WvE2Yz0TEkTzRNmcntIpdqUOpy4OIwxYnw2XNBl4$
<https://urldefense.us/v3/__http://www.eli-beams.eu__;!!G_uCfscf7eWS!
e2Ig-ypHK- _tCLuRgVos2YoEjuSyQSQj1J9wcVPAeL0WvE2Yz0TEkTzRNmcntIpdqUOpy4OIwxYnw2XNBl4$ >> <https://urldefense.us/v3/
__https://urldefense.us/v3/__http://www.eli-beams.eu/__;!! G_uCfscf7eWS!e2Ig-ypHK- _tCLuRgVos2YoEjuSyQSQj1J9wcVPAeL0WvE2Yz0TEkTzRNmcntIpdqUOpy4OIwxYn_QGsA0g$
__;!!G_uCfscf7eWS!euLXnna7-qCt-D3EjV5-bjzosTfKt- sd4lVcov9BLro2tBUjLRx- ed8iuDCVso9vUKL04d9SoJjsUQ8dHHIoBcTijQcDzg$>








Replies:
Re: Record TIME field taken from another record's VAL Majer Karel via Tech-talk
References:
Record TIME field taken from another record's VAL Majer Karel via Tech-talk
Re: Record TIME field taken from another record's VAL Torsten Bögershausen via Tech-talk
Re: Record TIME field taken from another record's VAL Majer Karel via Tech-talk
Re: Record TIME field taken from another record's VAL Torsten Bögershausen via Tech-talk
Re: Record TIME field taken from another record's VAL Majer Karel via Tech-talk
Re: Record TIME field taken from another record's VAL Torsten Bögershausen via Tech-talk
Re: Record TIME field taken from another record's VAL Torsten Bögershausen via Tech-talk
Re: Record TIME field taken from another record's VAL Majer Karel via Tech-talk

Navigate by Date:
Prev: Re: Re: the least EPICS_CA_MAX_ARRAY used for EIGER2 4M detector Zhibang Shen via Tech-talk
Next: Re: Record TIME field taken from another record's VAL Majer Karel 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  <2026
Navigate by Thread:
Prev: Re: Record TIME field taken from another record's VAL Majer Karel via Tech-talk
Next: Re: Record TIME field taken from another record's VAL Majer Karel 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  <2026
ANJ, 19 Mar 2026 · Home · News · About · Talk · Base · Modules · Extensions ·
· Distributions · Download · Documents · Links · Licensing ·