Date: Sun, 31 Aug 2014 12:34:57 -0700 Subject: Re: [sdss3-25mlog 1870] Re: 2.5m obslog 20140830 (MJD 56900) From: Constance Rockosi --089e013a032e42824e0501f1fbde Content-Type: text/plain; charset=UTF-8 I'll look at the flush failures. Let me see if I can pull that out from the other errors. --Connie On Sun, Aug 31, 2014 at 11:46 AM, John K. Parejko wrote: > On 31Aug 2014, at 10:16, Kaike Pan wrote: > > > Hi John, > > > > Can you give me more information on reading out issue? Should we add > "boss exposure readout" > > to netburner problem procedure? is there a way we can prevent it? > thanks > > The problem that occurred with the doMangaDither command was a bug in SOP: > I created a testcase for it last night that confirms the problem, and just > checked in a fix. I'll install it and test on the telescope later today; > this particular problem should not re-occur. See the ticket for more: > > https://trac.sdss3.org/ticket/2107 > > Note that the BOSS state "LEGIBLE" means "waiting to be read", not > "crashed" or "broken" or "dead", etc. If BOSS does get stuck in a LEGIBLE > state for more than a second or two (which shouldn't ever happen, baring > bugs like the above), the correct thing to do is to issue "boss exposure > readout", since that's what it's waiting for (this is how SOP handles lamp > warmup/guider dithering during readout). Issuing "recover" will cause the > exposure to be lost, since it hasn't been read out yet and thus there is > nothing to be recovered. > > Issuing "clearExposure" means "forget everything that was going on in the > BOSS cameras." This should only be used if you're *absolutely certain* you > want to throw everything away. > > "reloadControllers" is only necessary if you've lost communication with > some part of BOSS (daqs, cams, mechs). It is very unlikely that you need to > reloadControllers if there is no active critical alert (e.g. heartbeat, > MicrosNotTalking). I don't *think* it will hurt anything in other cases, > but it won't help if all parts of the BOSS ICC are already responding > correctly. > > Problems with BOSS flush failing I'm very uncertain about: Connie? > > The other problems the observers had last night I'm less certain of the > cause of. I'll see if I can recreate the troubles with the doMangaSequence > command. > > John > _____________________________________________________ > Message 1870 of sdss3-25mlog - Logs of nightly APO activities. > > https://trac.sdss3.org/tracmailman/browser/private/sdss3-25mlog/all/1870.html > sdss3-25mlog@sdss3.org > https://sdss3.org/mailman/listinfo/sdss3-25mlog > --089e013a032e42824e0501f1fbde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'll look at the flush failures. =C2=A0Let me see if I= can pull that out from the other errors.--ConnieOn Sun, Aug 31, 2014 a= t 11:46 AM, John K. Parejko wrot= e: On 31Aug 2014, at 10:16, Kaike Pan wrote: > Hi John, > >=C2=A0 Can you give me more information on reading out issue?=C2=A0 Sho= uld we add=C2=A0 "boss exposure readout" > to netburner problem procedure? is=C2=A0 there a way we can prevent it= ?=C2=A0 thanks The problem that occurred with the doMangaDither command was a bug in SOP: = I created a testcase for it last night that confirms the problem, and just = checked in a fix. I'll install it and test on the telescope later today= ; this particular problem should not re-occur. See the ticket for more: https://tr= ac.sdss3.org/ticket/2107 Note that the BOSS state "LEGIBLE" means "waiting to be read= ", not "crashed" or "broken" or "dead", = etc. If BOSS does get stuck in a LEGIBLE state for more than a second or tw= o (which shouldn't ever happen, baring bugs like the above), the correc= t thing to do is to issue "boss exposure readout", since that'= ;s what it's waiting for (this is how SOP handles lamp warmup/guider di= thering during readout). Issuing "recover" will cause the exposur= e to be lost, since it hasn't been read out yet and thus there is nothi= ng to be recovered. Issuing "clearExposure" means "forget everything that was go= ing on in the BOSS cameras." This should only be used if you're *a= bsolutely certain* you want to throw everything away. "reloadControllers" is only necessary if you've lost communic= ation with some part of BOSS (daqs, cams, mechs). It is very unlikely that = you need to reloadControllers if there is no active critical alert (e.g. he= artbeat, MicrosNotTalking). I don't *think* it will hurt anything in ot= her cases, but it won't help if all parts of the BOSS ICC are already r= esponding correctly. Problems with BOSS flush failing I'm very uncertain about: Connie? The other problems the observers had last night I'm less certain of the= cause of. I'll see if I can recreate the troubles with the doMangaSequ= ence command. John _____________________________________________________ Message 1870 of sdss3-25mlog - Logs of nightly APO activities. https://trac.sdss3.org/tracmailman/browser= /private/sdss3-25mlog/all/1870.html sdss3-25mlog@sdss3.org https://sdss3.org/mailman/listinfo/sdss3-25mlog --089e013a032e42824e0501f1fbde--