<div dir="ltr">So I think we could still retain the current Options:: approach for all modules, but for some values, we tie them to each equipment profile if there are changes made?<div><br></div><div>For example, the select for the last used camera, or last used filter wheel...etc. We would have to make a specific list to find which settings are tied to a profile vs generic options.<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>--</div><div>Best Regards,<br>Jasem Mutlaq<br></div><div><br></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 4, 2020 at 3:04 PM Eric Dejouhanet <<a href="mailto:eric.dejouhanet@gmail.com">eric.dejouhanet@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Jasem,<br>
<br>
You raise an interesting point. Originally, I hadn't planned to do <br>
anything different than what the Options are doing now. That is, only <br>
offer the possibility to serialize the set of Options pertaining to a <br>
specific Module.<br>
<br>
Then, from Scheduler, I would send those serialized settings (if any) to <br>
each module when initiating an Observation Step that involves them. <br>
Thus, because Scheduler is supposedly using a specific equipment Profile <br>
(which it actually may do only once at the beginning I think), we can <br>
say that the listed settings are tied to an equipment Profile. At least <br>
that was my intent, from the point of view of Scheduler.<br>
<br>
Now, if I consider the point of view of the module alone, the user may <br>
choose to load Settings created with a different set of devices than <br>
what the current Profile is defined with. That currently happens in the <br>
Capture module, where one may create a Sequence file with the CCD and <br>
Filter Wheel Simulators, and load it with their real camera and filter <br>
wheel (which their Simulator is mimicking). There are sometimes <br>
incompatibilities, and the code currently does not handle that very <br>
well. We can expect the same situation to happen in other modules.<br>
<br>
There is some sort of fallback method to design here in each module <br>
separately. Not the right camera device? We may just reject the <br>
settings, or pick the device currently in use and hope for the best, or <br>
default some fields, or define a blank "default" value that would reset <br>
a parameter to its default. Any ideas?<br>
<br>
-- <br>
-Eric<br>
<br>
mailto:<a href="mailto:eric.dejouhanet@gmail.com" target="_blank">eric.dejouhanet@gmail.com</a> -- <a href="https://astronomy.dejouha.net" rel="noreferrer" target="_blank">https://astronomy.dejouha.net</a><br>
<br>
</blockquote></div>