Subject: Re: [sloan-25mlog 3139] 2.5m obslog 20161006 (SJD 57668) From: Kaike Pan Date: Fri, 7 Oct 2016 13:28:15 -0600 --Apple-Mail=_31030D3E-D9A7-4016-A68F-A42EAB64785C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 7, 2016, at 1:00 PM, John Downey wrote: >=20 > To clarify this problem a little: >=20 > The data structure to which Kaike is referring here is that of the = mcpFiducials-57668.dat log file. The last two columns in that file are = labeled as encoder error but generally do not produce the same result = you get when subtracting the actual encoder counts from the expected = encoder counts at any given AZ fiducial crossing. The errors listed are = of an approximately correct order of magnitude, but do not reflect the = sign of the error and are listed as zeros when slewing with the MCP. = All I can come up with in terms of speculation is that there is some = timing problem between whatever is calculating these error values and = the actual fiducial crossings as recorded by the MCP. Is the TCC = calculating these errors? Its not a big deal as we do not seem to use = them for anything, just a nagging curiosity. I don=E2=80=99t know how the last two numbers (for encoder-erorr in the = data structure) was generated. but they both list as zeros when we have a big error on one encoder. Below are two sections of = mcpFidcuial log. As you can see, error 1 should be ~ -21000, error 2 = should be ~100. But they are both zeros in the mcpFiduical log.=20 In the first row of second section, the difference between position and = true are 75 and 82, they are listed as -275 and -296. All these slews are via tcc not mcp.=20 So looks like that zero error on BOTH encoderss are recorded when there = is a big fiducial error on either one encoder even when a slew is via = tcc. Because manual calculated errors are different from what are in = mcpfiducaial log, which one are actually applied to the axes = corrections? is is possible that wrong corrections are applied?=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D AZ_FIDUCIAL 1475823326 17 12141746 12146943 12120576 12146999 = 47.191 -513686 0 0 AZ_FIDUCIAL 1475823333 16 8283965 8291845 8262860 8291966 = 32.171 -513686 0 0 AZ_FIDUCIAL 1475823348 14 574615 587959 553650 588220 = 2.156 -508131 0 0 =E2=80=A6 AZ_FIDUCIAL 1475827457 13 -3284995 -3269011 -3284920 -3268929 = -12.790 -513686 -275 -296 AZ_FIDUCIAL 1475827465 12 -7138528 -7119908 -7138451 -7119816 = -27.793 -467812 -350 -378 >=20 > Basically the problem last night was a non-problem, it was the usual = case of the encoder capstan running over a moth. The problem was not = hardware even though early on the new STUI script appeared to show that = both encoders agreed in the error. I suspect there is something = fundamentally wrong with how the new script calculates its error values. >=20 > John >=20 >=20 >>=20 >>=20 >> 2. The cartridge bay door makes loud noise when open/close, sounds = like one >> chain is out of the position. JohnD is aware of that. We leave the = door open in >> the morning for day. >>=20 >> 3. We had fiducial errors of ~21000 ticks. The problem caused a time = lost of ~45 >> minutes. During the problem trouble shooting, we found that: >> 1). According to the data structure, the last two items are errors on = encoder 1 >> and encoder 2, but they are not.=20 >> 2). The current fiducial monitor script reports errors on encoder 1 = as error 2, >> and we don't what error 1 is.=20 >> 3). Kaike added one item to observing tips page on how to calculate = fiducial >> errors on the two AZ encoders.=20 >>=20 >> 4. We had out-of-close-loop on AZ and Alt, each once. >>=20 >>=20 >> 07:05Z loadCart: ct=3D6, pl=3D8657. >> We had 21000 ticket fiducial error on gotoField. Since fiducial = monitor script >> reports the same big errors on encoder 1 and encoder 2, we thought it = is not >> really error because it's hard to image that both encoders run into = moths at the >> same time, and generate the same errors. If a non-real fiducial error = is >> accepted, the telescope will lose tracking on where the real position = is, and >> mess up the pointing model. So we called in JohnD. When waiting for = JohnD to >> come in, we tried to find stars by offset telescope around the field, = no luck. >> Then, we slew the telescope away from the field, and slew back to the = field, we >> found that encoder 1 errors are within 600 ticks while errors on = encoder 2 are >> still about 21000. This confused us because MCP uses only errors on = encoder 1. >> If this error is within 600 ticks we should be fine. With JohnD, we = found that >> the real error on encoder 1 is 21000 while errors on encoder 2 are = within 600 >> ticks. So we accept the fiducial error and moved to the next = cartridge at 7:50Z. >> So, about 45Z minutes was lost due to the problem. During this = period, the sky >> was cloudy, and seeing was over 2.0". So even things work, data taken = will not >> be able to make into sets, just like the data we taken on the next = cartridge. >>=20 >> During the problem trouble shooting, we found that: >> 1) According to the data structure, the last two items are errors on = encoder 1 >> and encoder 2, but they are not.=20 >> 2) The current fiducial monitor script reports errors on encoder 1 as = error 2, >> and we don't what error 1 is.=20 >> 08:10Z loadCart: ct=3D1, pl=3D8154;SOGTF. >> 08:16:55 sp1.motor.move=3D -1760, -1765, -1761 >> 08:17:02 sp2.motor.move=3D -2365, -2363, -2365 >> 08:17:02 Hartmann collimate output on cart #1 >> sp1: offset: r=3D -1979 (Out of focus); b=3D 4.8 (Out of focus)=20 >> sp2: offset: r=3D -2209 (Out of focus); b=3D 7.9 (Out of focus)=20 >> sp1: pred. move: spAverageMove=3D -1760 >> sp2: pred. move: spAverageMove=3D -2365 >> sp1: pred. resid: r=3D -218, b=3D -0.7, txt=3D OK, spTemp =3D 9.3 >> sp2: pred. resid: r=3D 156, b=3D 0.5, txt=3D OK, spTemp =3D 9.1 >> 08:26Z started science exposures. Cloudy, guider seeing 2.1 - 2.5". >> 7 MaNGA dither exposures and 7 pairs of APOGEE data were taken. But = none of the >> MaNGA exposure makes into a set.=20 >>=20 >=20 --Apple-Mail=_31030D3E-D9A7-4016-A68F-A42EAB64785C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Oct 7, 2016, at 1:00 PM, John Downey wrote:To clarify this = problem a little:The data structure to = which Kaike is referring here is that of the mcpFiducials-57668.dat log = file. The last two columns in that file are labeled as encoder = error but generally do not produce the same result you get when = subtracting the actual encoder counts from the expected encoder counts = at any given AZ fiducial crossing. The errors listed are of an = approximately correct order of magnitude, but do not reflect the sign of = the error and are listed as zeros when slewing with the MCP. All I = can come up with in terms of speculation is that there is some timing = problem between whatever is calculating these error values and the = actual fiducial crossings as recorded by the MCP. Is the TCC = calculating these errors? Its not a big deal as we do not seem to = use them for anything, just a nagging = curiosity.I don=E2=80=99= t know how the last two numbers (for encoder-erorr in the data = structure) was generated. but they both list as zeros whenwe = have a big error on one encoder. Below are two sections of = mcpFidcuial log. As you can see, error 1 should be ~ -21000, error 2 = shouldbe ~100. But they are both zeros in the mcpFiduical = log. In the first row of = second section, the difference between position and true are 75 = and 82, they are listed as -275 and -296. All these slewsare = via tcc not mcp. So looks like = that zero error on BOTH encoderss are recorded when there is a big = fiducial error on either one encoder even when a slew is via = tcc.Because manual calculated = errors are different from what are in mcpfiducaial log, which one are = actually applied to the axes corrections?is is possible that = wrong corrections are applied? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DAZ_FIDUCIAL 1475823326 17 12141746 = 12146943 12120576 12146999 47.191 = -513686 0 0AZ_FIDUCIAL 1475823333 16 = 8283965 8291845 8262860 8291966 = 32.171 -513686 0 0AZ_FIDUCIAL 1475823348 = 14 574615 587959 = 553650 588220 2.156 -508131 0 = 0=E2=80=A6AZ_FIDUCIAL 1475827457 13 -3284995 = -3269011 -3284920 -3268929 -12.790 = -513686 -275 -296AZ_FIDUCIAL 1475827465 12 -7138528 = -7119908 -7138451 -7119816 -27.793 = -467812 -350 -378Basically the = problem last night was a non-problem, it was the usual case of the = encoder capstan running over a moth. The problem was not hardware = even though early on the new STUI script appeared to show that both = encoders agreed in the error. I suspect there is something = fundamentally wrong with how the new script calculates its error = values.John2. The cartridge bay door makes loud noise when open/close, = sounds like onechain is out of the position. JohnD is = aware of that. We leave the door open inthe morning for = day.3. We had fiducial errors of ~21000 = ticks. The problem caused a time lost of ~45minutes. = During the problem trouble shooting, we found that:1). = According to the data structure, the last two items are errors on = encoder 1and encoder 2, but they are not. 2). The current fiducial monitor script reports errors on = encoder 1 as error 2,and we don't what error 1 is. 3). Kaike added one item to observing tips page on how to = calculate fiducialerrors on the two AZ encoders. 4. We had out-of-close-loop on AZ and Alt, = each once.07:05Z = loadCart: ct=3D6, pl=3D8657.We had 21000 ticket = fiducial error on gotoField. Since fiducial monitor scriptreports the same big errors on encoder 1 and encoder 2, we = thought it is notreally error because it's hard to image = that both encoders run into moths at thesame time, and = generate the same errors. If a non-real fiducial error isaccepted, the telescope will lose tracking on where the real = position is, andmess up the pointing model. So we called = in JohnD. When waiting for JohnD tocome in, we tried to = find stars by offset telescope around the field, no luck.Then, we slew the telescope away from the field, and slew = back to the field, wefound that encoder 1 errors are = within 600 ticks while errors on encoder 2 arestill about = 21000. This confused us because MCP uses only errors on encoder 1.If this error is within 600 ticks we should be fine. With = JohnD, we found thatthe real error on encoder 1 is 21000 = while errors on encoder 2 are within 600ticks. So we = accept the fiducial error and moved to the next cartridge at 7:50Z.So, about 45Z minutes was lost due to the problem. During = this period, the skywas cloudy, and seeing was over 2.0". = So even things work, data taken will notbe able to make = into sets, just like the data we taken on the next cartridge.During the problem trouble shooting, we found = that:1) According to the data structure, the last two = items are errors on encoder 1and encoder 2, but they are = not. 2) The current fiducial monitor script reports = errors on encoder 1 as error 2,and we don't what error 1 = is. 08:10Z loadCart: ct=3D1, pl=3D8154;SOGTF.08:16:55 sp1.motor.move=3D -1760, -1765, -176108:17:02 sp2.motor.move=3D -2365, -2363, -236508:17:02 Hartmann collimate output on cart #1 = sp1: offset: r=3D -1979 (Out of focus); b=3D 4.8 (Out of = focus) sp2: offset: r=3D -2209 (Out of focus); = b=3D 7.9 (Out of focus) sp1: pred. move: = spAverageMove=3D -1760 sp2: pred. move: = spAverageMove=3D -2365 sp1: pred. resid: r=3D -218, = b=3D -0.7, txt=3D OK, spTemp =3D 9.3 sp2: pred. = resid: r=3D 156, b=3D 0.5, txt=3D OK, spTemp =3D 9.108:26Z = started science exposures. Cloudy, guider seeing 2.1 - 2.5".7 MaNGA dither exposures and 7 pairs of APOGEE data were = taken. But none of theMaNGA exposure makes into a set. = = --Apple-Mail=_31030D3E-D9A7-4016-A68F-A42EAB64785C--