Do not allow queuing of filter which is not in the filter wheel

[dsand]

Right now, it appears that you can queue observations in a filter that is not currently in the filter wheel. In that case, RTS2 appears to take an image in the filter currently in the beam, so one gets data they did not request.

I think there should be some validation step that does not allow queuing of observations of a filter not in the wheel.

[pndaly]

AORP cannot possibly know what the current filters are! Just sayin'. So, it seems to me that this should be caught by RTS2 and it should reject the submission.

[dsand]

Well, hold on. Observations are being queued from AORP. Where should the validation take place? Lets think through the architecture.
Imagine a queue observer, at 3 in the morning, accidently queueing an observation in a filter that is not in the wheel. Should they be told at the point of request that their request is not possible? It should not just go into the aether, and there is no traceback about why an observation did not happen.

Now, I totally agree that this should also be rejected by RTS. It should not take an image in the wrong filter.

[pndaly]

Observations queued by AORP use the rts2solib wrapper. Since big61filters is part of that package, it should be handled there? The problem then is - as you saw last night - we rarely mess with rts2solib as it tends to cause unknown side-effects later on. I think this is what happened yesterday when "python3 setup.py" was executed in the rts2solib git-clone repository and the rts2_config path(s) hadn't been changed back from the hot fix. I could be wrong on that. I suspect the rts2solib clone used by AORP is not the same as the one on bigartn.