You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the following PVs are available on the local BSS module as strings:
Proposal start (${P}:proposal:startDate)
Proposal end (${P}:proposal:endDate)
ESAF start (${P}:esaf:startDate)
ESAF end (${P}:esaf:endDate)
If possible, could there also be PVs with these values as numbers given the unix-epoch timestamp? Not sure if integers or floats is better, probably depends on how much precision the source data has?
Two use cases come to mind:
Compatibility with the pydm date time widget, which expects numbers.
These signals could then be included in the ophyd BSS device and used to do math for how old the proposal/ESAF are.
Use case 2 is not that tricky to work around by converting the string to a timestamp, but use case 1 requires a custom widget or a regular QDateTime widget with the logic in python.
The text was updated successfully, but these errors were encountered:
Currently, the following PVs are available on the local BSS module as strings:
If possible, could there also be PVs with these values as numbers given the unix-epoch timestamp? Not sure if integers or floats is better, probably depends on how much precision the source data has?
Two use cases come to mind:
Use case 2 is not that tricky to work around by converting the string to a timestamp, but use case 1 requires a custom widget or a regular QDateTime widget with the logic in python.
The text was updated successfully, but these errors were encountered: