[INSTRM-119] Move device configuration into ics_config product. Created: 31/May/17  Updated: 28/Jan/22  Resolved: 28/Jan/22

Status: Won't Fix
Project: Instrument control development
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Normal
Reporter: cloomis Assignee: cloomis
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
is blocked by INSTRM-28 Provide an id object to track site, c... Done
Duplicate
is duplicated by INSTRM-1281 move device/instrument configuration ... Done
Relates
relates to INSTRM-132 Switch to YAML config file for enuActor Won't Fix
Epic Link: ics_config
Sprint: 2017-10A
Reviewers: arnaud.lefur

 Description   

The XCU, CCD, and HX actors all either have or will have device configuration which needs to be tracked. Examples:

  • per-ccd bias offsets, other voltages
  • per-motor ranges and limits
  • current thresholds to track
  • temperature/power/etc setpoints
  • many others.

These should not be in the code products. Much of it currently is.

Can this list be fleshed out by LAM? Any design comments welcome.

I'll start by proposing a tree of YAML files, one directory per actor, and one configuration item per line. I'm imagining a "default" configuration file, plus overrides.

I'll point out that this might be the place to declare alarm thresholds, and perhaps everything which is currently in the hated ics_xcuActor/etc files. Also, the PFI configuration should not be part of this.



 Comments   
Comment by arnaud.lefur [ 14/Jun/17 ]

For enu, we absolutely need to track slit configuration : home, tool coordinates systems which come from the slit alignment procedure. For now, I was pushing it as a keyword so I can retrieve the history from the archiver.
But I agree that ics_config would be a good place to put it.

We need to talk about that next week, especially if we link that to alarm handling also

Comment by cloomis [ 23/Jun/17 ]

Showed proof-of-concept to Fabrice and Arnaud. Since they will be using this, I'm asking Arnaud to review. I'd like to come out of this shutdown using both INSTRM-119 and INSTRM-28

INSTRM-28 is a partial requirement, since it provides a namespace for spectrograph ID interpolation.

Interpolation is currently only done on individually fetched strings, which I think is sufficient for current needs. I think I should add an option to recursively check for strings in the returned data structure.

Comment by arnaud.lefur [ 14/Sep/17 ]

That's good for me.
The syntax of the YAML file can be a bit tricky. But they are really powerful and interpolate names allow to factorize even more.
It will definitely make our life easier.

Comment by shimono [ 17/Sep/17 ]

which part did you feel tricky? we might be better to have them documented not to get confused and bug..

Comment by shimono [ 25/Jan/18 ]

This ticket is marked as review completed, but nothing has done on github.
Just raise what to do cloomis / arnaud.lefur.

Comment by hassan [ 28/Jan/22 ]

Ticket has already been addressed as part of other work.

Generated at Sat Feb 10 16:21:44 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.