PolishookDavid / LAST_OCS

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

Unit.takeExposure in the slave session does update the object #4

Open noralinn opened 1 year ago

noralinn commented 1 year ago

When slewing and getting more observations in the slave, the object and filename will correspond to the previous coordinates (before slewing).

EastEriq commented 1 year ago

I checked on 01w and don't see it happening. Are you sure? In any case, running commands directly from slaves should be considered a way of debugging, not something to be supported on the long term (slaves are bound to be replaced someday by the webAPI). Anyway, whatever report is good for pinpointing potential bugs.

Master:

>> P.Mount.goTo(90,40,'ha')
>> P.Mount.goTo(70,60,'ha')

Slave 4:

>> P.takeExposure(4,1)
>> {obs.unitCS} Writing image /last01w/data2/archive/LAST.01.01.04/new/LAST.01.01.04_20230115.110631.976_clear_226+40_001_001_001_sci_raw_Image_1.fits to disk
{inst.QHYccd} New image available (1/1) from camera 01_1_4
>> P.takeExposure(4,1)
>> {obs.unitCS} Writing image /last01w/data2/archive/LAST.01.01.04/new/LAST.01.01.04_20230115.111131.211_clear_248+60_001_001_001_sci_raw_Image_1.fits to disk
{inst.QHYccd} New image available (1/1) from camera 01_1_4

FILENAME and OBJECT in the FITS file are consistent

noralinn commented 1 year ago

I checked again and the command that doesn't update the object and filename is:

P.Camera{1}.takeExposure(5)

So maybe that isn't the intended usage? I'm using it only in a script that takes defocused images for testing, so not in an actual function.

EastEriq commented 1 year ago

Then there is no bug. obs.camera.takeExposure is a method of the camera object, and as such it cannot know properties of the mount. You should use in this case P.takeExposure(1,5) which uses the obs.unitCS method, which accidentally has the same name, but is different. There is something in your point though, because off the head obs.camera.takeExposure generates an event when a new value of .LastImage is filled, and this triggers the callback obs.unitCS.treatNewImage, which saves the image. I assumed that it queries the mount in any case, getting the new coordinates, but have to check it. That's a corner case, but better to make sure what is going on.

EastEriq commented 1 year ago

There is definitely a catch here, because unitCS.takeExposure allows the option of setting Object explicitely (line https://github.com/PolishookDavid/LAST_OCS/blob/e674a29cc4f0e5cbe933858a4da71a3d6748e92a/%2Bobs/%40unitCS/takeExposure.m#L69) [I think it is @EranOfek's addition], perused for instance by https://github.com/PolishookDavid/LAST_OCS/blob/e674a29cc4f0e5cbe933858a4da71a3d6748e92a/%2Bobs/%2Butil/%2Balign/pointingModel.m#L57. This violates the assumption, elsewhere, that the mount should be queried only at the moment of saving, at the end of the exposure. Otherwise I'd add this query in @unitCS/private/treatNewImage.m. I think the simplest course of action is simply to ignore the problem and its consequences.