Thanks all for the feedback
Clarification:
For ITER, we'll have a IEEE 1588-2008 network to provide time accuracy "below 1 micro-second", as per the norm, and below 50 ns with a properly configured network and maybe better as time goes.
(People interested in IEEE 1588-2008 can contact us, BTW)
Controllers will also be interfaced to fast communication network for feedback but that's another story.
The time expression won't be far in future (long pulses are still expressed in minutes) but they shall be precise.
To sum up the type aspect:
- A pair of integer is required & signed integers are good enough for now ... provided that UINT32 support is completed within the next 68 years.
- Relative time (pulse time), with ns precision can fit in a FLOAT64 for 125 hours or something like that, which would be OK for us.
- A ns precision for a software interrupt is somehow excessive and microsecond precision would fit into a FLOAT64 mantissa but it's not very good to have many resolutions.
We are considering a waveform with 2 ints for time PVs and maybe FLOAT64 records for relative time (pulse time).
I also guess that pvData will/shall allow time struct with ns fractions in the API.
Best regards,
Franck
-----Original Message-----
From: Di Maio Franck
Sent: 18 October 2010 14:56
To: '[email protected]'
Cc: Golob Janez; Makijarvi Petri; Mahajan Kirti
Subject: Manipulating time in records
Dear EPICS advanced
An issue that I guess has been encountered in other labs already.
A typical ITER use case:
"Do A at time T",
- T: a setting controllable by PV(s),
- A: an action implemented by a record triggered by an event occurring at time T.
We are implementing this use case with a module that receives time over PTP, so the time shall be expressed with nano-second resolution.
So we need:
- one unsigned int32 for seconds
- one (unsigned or not) int32 for fraction of second expressed as nano-seconds.
Same as time-stamp (TS), right?
Maybe 2 longout but I am not sure if UINT32 is OK with longout.
In addition, we'll have "pulse time", with a specific time origin, so maybe also sub or calc records to convert between relative and absolute time.
We'll appreciate advices on the records to be used... Good or bad ideas/experiences welcome.
Thanks in advance!
Franck
- Replies:
- Re: Manipulating time in records Marty Kraimer
- Re: Manipulating time in records Luedeke Andreas
- References:
- Manipulating time in records Di Maio Franck
- Re: Manipulating time in records Luedeke Andreas
- Navigate by Date:
- Prev:
Lookup table problem Silver
- Next:
Re: Lookup table problem Maren Purves
- 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: Manipulating time in records Luedeke Andreas
- Next:
Re: Manipulating time in records Marty Kraimer
- 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
|