search

PolishookDavid / LAST_OCS

Code controling the LAST project Observatory
0 stars 0 forks source link

misuse of inputname [`Unit.UnitHeader` not updated in slaves when taking flats (gledmagicwater)] #21

Open EastEriq opened 4 months ago

EastEriq commented 4 months ago

whereas it is correctly updated by calling simply Unit.takeExposure in the master. Probably because it is separately sent via Slave.Responder, and thus it s queued. Check the messenger behavior depending on wheter the command is issued in the interactive master or via a superunit, with Listener or Messenger type communication, and devise possible solutions.

EastEriq commented 4 months ago

No, it is because of the wrong assumption about inputname in .takeExposure, which retrieves 'UnitObj' if takeExposure is called from takeTwilightFlats, vs. 'Unit' when called directly from prompt. See https://github.com/PolishookDavid/LAST_OCS/commit/e796c1968b70fa7941e1513f6d6a3d333590e0eb

Think well if it is worth to allow the unit object to have a free name (in which case there should be a robust and economical way to determine its name), or just to fix that it must be called Unit.

EastEriq commented 4 months ago

Beware, I abused of inputname in several places:

LAST_OCS/+obs/@unitCS/connect.m:68:    SlaveUnitName=inputname(1);
LAST_OCS/+obs/@unitCS/abort.m:6:            %  inputname()
LAST_OCS/+obs/@unitCS/abort.m:7:            UnitName=inputname(1);
LAST_OCS/+obs/@unitCS/connectSlave.m:12:    SlaveUnitName=inputname(1);
LAST_OCS/+obs/@unitCS/operateUnit.m:51:UnitName=inputname(1);
LAST_OCS/+obs/@unitCS/focusTel.m:76:    UnitName=inputname(1);
LAST_OCS/+obs/@unitCS/obsByPriority2.m:71:    UnitName=inputname(1);
LAST_OCS/+obs/@unitCS/checkWholeUnit.m:67:            % this IS tricky, because connectSlave uses inputname()
LAST_OCS/+obs/@unitCS/checkWholeUnit.m:69:            evalin('caller',sprintf('%s.connectSlave(%d)',inputname(1),i));
LAST_OCS/+obs/@unitCS/takeExposure.m:168:    UnitName=inputname(1);
EastEriq commented 1 month ago

Deferring this one to a new milestone, because I want to move on with https://github.com/EastEriq/LAST_SuperunitMonitoring/issues/5