Guider binning
Eric Dejouhanet
eric.dejouhanet at gmail.com
Thu Jun 4 13:03:55 BST 2020
Hello Jasem,
You raise an interesting point. Originally, I hadn't planned to do
anything different than what the Options are doing now. That is, only
offer the possibility to serialize the set of Options pertaining to a
specific Module.
Then, from Scheduler, I would send those serialized settings (if any) to
each module when initiating an Observation Step that involves them.
Thus, because Scheduler is supposedly using a specific equipment Profile
(which it actually may do only once at the beginning I think), we can
say that the listed settings are tied to an equipment Profile. At least
that was my intent, from the point of view of Scheduler.
Now, if I consider the point of view of the module alone, the user may
choose to load Settings created with a different set of devices than
what the current Profile is defined with. That currently happens in the
Capture module, where one may create a Sequence file with the CCD and
Filter Wheel Simulators, and load it with their real camera and filter
wheel (which their Simulator is mimicking). There are sometimes
incompatibilities, and the code currently does not handle that very
well. We can expect the same situation to happen in other modules.
There is some sort of fallback method to design here in each module
separately. Not the right camera device? We may just reject the
settings, or pick the device currently in use and hope for the best, or
default some fields, or define a blank "default" value that would reset
a parameter to its default. Any ideas?
--
-Eric
mailto:eric.dejouhanet at gmail.com -- https://astronomy.dejouha.net
More information about the Kstars-devel
mailing list