| Miniproposals |
| Operators | |
| Session leader(s): | |
| Physics operator(s): | Steve Wolfe |
| Engineering operator(s): | Bill Parkin,Bill Byford,Gary Dekow |
| Engineering Operator Run Comment |
| C-MOD start up |
| Session Leader Plans |
| Physics Operators Plans |
| Entered: Jul 8 2009 04:08:27:477PM |
| Author: Steve Wolfe |
Physics Operator Plan and Engineering Setup for Thurs July 9, 2009 MP#298a: C-Mod startup and conditioning SL: ? PO: wolfe ----------------- Engineering Setup ----------------- Run begins at 09:00 and ends at 17:00 Power systems as on: 1090708001 Acoil: +Dtop -Dbot -Jtop +Jbot (standard) Hybrid Enabled Gas setup: Fill B-Top with 6 psi D2 Hybrid enabled (PG4) fill B-side lower with 1 psi Ar Hybrid enabled (PG1) leave B-side upper as is Hybrid DISABLED (PG2) fill B-main (C-side) with 40 psi D2 Hybrid enabled (PG3) leave NINJA as is DISABLED Enable gatevalves and shutters: ECE, Z-bolo Torvac gatevalve toggle (yes/no): no Boronization(yes/no): no Overnight ECDC (yes/no): yes ICRF(yes/no): no LH(yes/no): no DNB(yes/no): no Cryopump (yes/no): no Vessel temperature: 35/35/35 ------------------------------ ECDC Parameters (if requested) ------------------------------ gas and pressure: D2 at 2e-4 Torr sweep: 44/45/103 cm scan: 20/120 s ------------------------------------------- PhysOp Plan Load dpcs from a suitable shot such as 1090708027, 0.9MA, LSN Proceed with cleanup discharges, monitoring RGA (if available) and HtoD Things to try: 1) Reduce program density (not too far) to see how much wall fueling we're doing. If I get locked modes, try turning off the A-coil and see if the intrinsic threshold is higher or lower (count a few shots toward MP#555). 2) Run upper null and/or inner wall limiter discharges to aid cleaning of those surfaces. 3) Increase current back to 1MA and see if the cleanup/hydrocarbon generation rate is still non-linear in the current. 4) If I get really bored, try running pure helium discharges (including pre-puff). Call it development for the helium H-mode experiments (MP's to be written). Expect to allow cell access for diagnostic shakedown, as requested. |
| Session Leader Summaries |
| Physics Operator Summaries |
| Entered: Jul 9 2009 06:34:05:913PM |
| Author: Steve Wolfe |
Physop Summary for Thursday July 9, 2009
MP#298a: C-Mod startup and conditioning
SL?
PO: wolfe
EO: Parkin, Byford, Dekow
The run went relatively smoothly except for a SNAFU with the
dpcs init action software (see below). We spent most of the day
running vanilla LSN 900kA discharges. Brian and Dan used these to do some
cleaning up of the scanning probes, but they were plagued by triggering
problems on their cpci digitizers, so only a few WASP and FSP scans
were done. The same problem prevented the heat profile data from
being collected, except for a few shots. I decreased the target
density down to 6e19, and more or less succeeded in getting down to
this level without turning off the feedback. Didn't try to go lower.
After Brian finished/gave up, on shot#24-28 I changed to USN (using
seg3). These ran pretty well, and didn't show any major change in
H or hydrocarbon evolution, although the mass 28 increase was larger
than in the LSN discharges. Again, got down to a target of nl04=6e19.
No sign of a locked mode in either upper or lower null. I didn't try
turning off the a-coil, leave MP555 for another day.
Shot#29 I went back to seg2 and programmed for inner wall limited,
but only got marginally limited, bouncing around lower null still.
The camera view and the EFIT reconstructions seemed to be consistent,
with light on the inner wall near the midplane and in the lower
divertor.
For shot#30 I programmed for more strongly limited (clearin
from -.015 to -.02) and, at Earl's urging, increased Ip to 1MA.
This one ran well-limited, with loop voltage around 1.8V, and
ended up railing OH1 near 1.3sec, and disrupted at 1.44sec with
just over 800kA. The disruption raised the hydrocarbon peaks by
about an order of magnitude, but wasn't nearly as dramatic as
1MA disruptions of last week.
The H/D levels in the plasma rose through the day (although there
wasn't enough light to register in the USN shots until rampdown).
The limiter case got up to H/D~0.5. M3/M4 on the RGA also rose
through the day, indicating we were doing some good in liberating
H to be pumped away.
Startup was quite reliable today, and almost all the plasmas
lasted full length until the disruption on shot#30. I fiddled
with the startup continuously, mostly to try to deal with runaways,
pretty successfully. There was one strange super-fizzle on shot#7,
on which the zcur position ran rapidly up. This seemed to be due
to a change in BR0, rather than Zcur feedback error. There seemed to
be no magnetics errors or power supply problems. I adjusted
BR_0 by 0.5mT and made a gas tweak and the next shot was fine. There
was another fizzle later in the day (#22) that may have been similar,
but didn't get as far; I again tweaked BR_0 more negative and adjusted
the gas and got plasma back. BR_0 ended the day at .0005, which may
be too negative, but worked.
The following long description is of interest only to
DPCS and software people (me and Tom&Josh).
The short story is that a problem occurred and has
been patched. You may now skip to the end.
*********************************************************
BEGIN LONG, BORING ACCOUNT OF DPCS SOFTWARE ISSUE
*********************************************************
On shot#4 the cycle hung up because pcdaqdpcs3 rebooted between
INIT and CHECK. We took a no-power shot, which did not record
data and did not advance the shot number. Tom and Josh concluded
that a network glitch had caused the reboot. This has happened before,
at least once. However, this time there was more than the usual fallout.
On the next shot cycle, also numbered #4, we got a report of
a critical init action failure on the dpcs_init action. In fact,
as shown by the logfile, the dpcs_init action had completed normally,
but the server received a report of an error status (!err=-5,
which translates to
MDSVALUE: %TREE-E-TreeNODATA, No data available for this node)
This symptom has been seen before in test scripts run on
pcdaqdpcs4 since a reboot in May or June, but had not previously been
reported as an action failure by the mdsip server to the dispatcher.
Some software that got updated on the reboot must have changed this
behavior.
After the second time this happened, following a restart of the
dispatcher and cycle, I verified that
1) the dpcs_init had in fact completed normally as indicated in
the pcdaqdpcs3-dpcs.log file and
2) all the outputs and subsequent actions and waveforms during the
no-power shot were normal.
Based on this, I instructed the operators to bypass the critical
init failure warning STATE and proceed with the shots while T&J
investigated the cause of the spurious messages. We ran this way,
without incident, for shots#5-8.
After shot#8, Tom and Josh had determined that the init action
failure was due to the presence of the IDL error state, and that
this was due to an mdsvalue error someplace in the dpcs_init code.
They didn't and still don't understand why this had never mattered
before and was now mattering, but we started working on a workaround.
Josh put a new line into the dpcs_init procedure in
/usr/local/cmod/idl/dpcs2/dpcs_startup.pro to do a help,/str,!error_state
just after the call to the user_init_procedure. (I think he also
uploaded to CVS; need to check). I stuck a
message,/reset into the end of the dpcs_fizzle_init.pro routine,
since a message from that routine was showing up in the logfile. However,
on a test shot we found that this did not get rid of the -5 error
condition. Looking deeper into dpcs2_init_procedure.pro we found that
the setup of the V waveforms involved a loop over vnodes[1:32] which
used mdsvalue(,/quiet,stat=stat) and checked the stat return. In
fact, a lot of these do fail because PCS only fills in the first 16,
and not all of the second group are defined. I stuck
in an else clause that printed the status on failure and then
did a message,/reset to clear !error_state. This succeeded in
removing the error condition, and subsequently allowed the shots to
proceed without further critical init failures.
However, Tom pointed out that the fifo_serve code that is reporting
the status to the mdsip server is in fact sending the value of the
obsolete sysvar !err, rather than !error_state.code, and message,/reset
does not set the value of !err to 0 (a pseudo-bug in IDL, since
the !err is obsolete but the documentation claims it should still work
as previously. It turns out, amazingly enough, that doing a
help,/str,!error_state seems to reset the value of !err to that
of !error_state.code, and therefore the diagnostic statement that Josh
inserted (at Tom's suggestion) into dpcs_init was in fact necessary to
make the patch of the dpcs2_init_procedure code succeed.
Josh will change the fifo_serve code to use the !error_state.code
variable instead of the deprecated !err, and hopefully change
anything else of the cycle-related software that uses this obsolete
sysvar. Probably this will happen on Monday? Meanwhile, we still don't
know why the presence of this rather benign error state is now being
considered evidence of failure, when it never was before. This seems
wrong, since lots of code must encounter mdsvalue errors without clearing
the state, but nevertheless finishing gracefully and successfully. This
behavior should be tracked down and reconsidered.
**************************************************
END of explanation of DPCS software issue
**************************************************
Scorecard:
No Power shots: 2 (but one didn't advance the shot counter)
Duds : 0
Fizzles : 2 (one got to 90kA, so Ian's routine calls it plasma)
Plasmas :27
--------- --
Shots 31 (but only 30 got counted)
|
| Session Leader Comments |
| Physics Operator Comments | |||
| Jul 9 2009 07:47:15:630AM | 1090709001 | Steve Wolfe |
Setting PCS up for first shot
Load from 1090708031
Seg1:
RCUR offset from 2000 to 1500 (reduce early bzdot,maybe help fizz,
maybe make runaways worse?)
BR_0 from .001 to .0015 (looked a little negative yesterday)
IC_EF4U from -1290 to -1280 (increase starting bz, maybe help runaway?)
PG4 leave at 15msec
PG3 increase to 60V at .034,.046; 30V@.058 (maybe help runaway)
Seg2: Reduce rate of density rise before .5sec, trying to get rid of marfe
Load at 9-Jul-2009 07:40:48.00
Open tree /home/wolfe/pcs_scratch -1
Open tree done
|
| Jul 9 2009 09:07:56:473AM | 1090709001 | Steve Wolfe | Shot#1: plasma full length Still have a marfe at .18 to .25 sec or so. Also still have hards, which dump around the time of the marfe. looks like an injection around 0.15, small bite out of Ip good bd time, no obvious bounce, decent burnout. H/D~.15 Next: Increase seg1 pg3 puff. |
| Jul 9 2009 09:16:30:207AM | 1090709001 | Steve Wolfe | Shot#2: Increase seg1 pg3 puff, decrease pg4 from 15 to 13ms ITG at INIT=1.7e-6, 1.5 in check plasma full length No marfe, no hards. Strong limiter interaction (?) on CIII, D-alpha at35msec. Fast burnout on zmeter, Dalpha bp20_jk reporting baseline offset, high chisq in that region on efit. (not used in DPCS) Bob will zap bp20_jk before the next shot. |
| Jul 9 2009 09:44:26:863AM | 1090709001 | Steve Wolfe | Shot#4: repeat (no DPCS changes) IGT@INIT=2.0e-6 Actmon hung in init, cleared after 2: Tom claims dpcs3 rebooted, it completed init, I see no reboot messages in the log file, but it's only been up for 2minutes. The dpcs job is there and running. |
| Jul 9 2009 09:50:09:270AM | 1090709002 | Steve Wolfe | Shot#2: Increase seg1 pg3 puff, decrease pg4 from 15 to 13ms ITG at INIT=1.7e-6, 1.5 in check plasma full length No marfe, no hards. Strong limiter interaction (?) on CIII, D-alpha at35msec. Fast burnout on zmeter, Dalpha bp20_jk reporting baseline offset, high chisq in that region on efit. (not used in DPCS) H/D ~ 0.18; M3/M4 rising between shots, M16 ratcheting up Bob will zap bp20_jk before the next shot. Next: Increase early seg2 current rise |
| Jul 9 2009 09:50:32:473AM | 1090709003 | Steve Wolfe | Shot#3: Increase early seg2 current rise (point at .282 from 750 to 800kA) IGT @INIT=1.6e-6 plasma full length. No hards, no marfe. NL04 feedback is calling for gas from about 0.3sec to 1.3sec when the demand target goes negative. Density rises slightly during pulse, basically at target value of 0.9e20. M3/M4 seems to be coming back down, peaked at .55 before shot. M16 still ratcheting up, H/D up to ~0.2 Heat footpring diagnostic is having timing problems, so display is showing cool everywhere. Wide1 video (and others?) have been otl all day, wide2 is there (tilted view). Next: repeat (no DPCS changes) |
| Jul 9 2009 09:53:13:427AM | 1090709004 | Steve Wolfe | Shot#4: repeat (no DPCS changes) IGT@INIT=2.0e-6 Actmon hung in init, cleared after 2: Tom claims dpcs3 rebooted, it completed init, I see no reboot messages in the log file, but it's only been up for 2minutes. The dpcs job is there and running. Restart message in the logfile showed up very late, but it's there now. There is also a message from dpcs_realtime that the variable STRLEN: Variable is undefined: USER_RT_PROCEDURE (DPCS_PARAMS). which makes sense since the init was done before the reboot. Should be ok for next shot. Need to understand why the reboot happened, eventually. Took a dpcs test s\hot - looks good to go. |
| Jul 9 2009 10:10:18:583AM | 1090709004 | Steve Wolfe | Shot#4 (second edition): repeat of 3 (no DPCS changes) IGT@INIT=9.5e-7 Got a critical failure on dpcs2 init. Need to see what's going on now. Take another no power The dpcs3 logfile indicates that the init completed fine but the actmon claims something called CMOD::top.hardware.dpcs:dpcs2 init action failed. It's dpcs2 server not dpcs3. Apparently this is the FFT? Why is it in cmod instead of RF? It isn't. This was DPCS_SERVER error and it is for the dpcs system. |
| Jul 9 2009 10:14:08:850AM | 1090709004 | Steve Wolfe | Shot#4: The log file indicates that the dpcs completed normally. However, the action monitor really did say that it had a critical error on the DPCS_SERVER on the dpcs2 init. Note that this refers to the device type dpcs2 not to pcdaqdpcs2 and has nothing to do with rf or fft. Josh is apparently checking into why it claimed a failure. He wants cycle restarted. |
| Jul 9 2009 10:36:50:113AM | 1090709005 | Steve Wolfe | Shot#5: repeat of shot#3 I hope. Again a crit init failure on init of dpcs but log file says it's ok. Bypass and go Note that I got the same error on the test_init_dpcs2 test shot 1090709101, as I have been for a qhile. plasma disrupts at 1.78 sec in rampdown. No marfe no hards. good startup. M3/M4 hanging at .55, M16 still ratcheting up. H/D~0.21 Next: I'm going to start dropping the density target. |
| Jul 9 2009 10:50:50:787AM | 1090709006 | Steve Wolfe | Shot#6: Reduce nl04 from 9e19 to 8e19 T&J still looking at why we're getting critical failure DPCS init is fine in logfile, bypass and go plasma full length density rising as gas drops after 1sec, ends up at 9.2e19 by EOF. We're still running off the wall, I guess. M3/M4 rising again after #5, now up to 0.66 H/D between .25 and .2, down and up and down during shot Startup still looks good, Ip/Bz increasing a little Next: Decrease nl04 demand to 7e19 |
| Jul 9 2009 11:11:20:583AM | 1090709007 | Steve Wolfe | Shot#7: Decrease nl04 demand to 7e19 ITG@INIT=? wasn't looking fizzle. fast current rise to nearly 90kA, moving up fast. And it knows it, no magnetics error messages Looks like the oh2's are trying to compensate, they are following the demand. Don't understand what happened, and I want to before the next shot |
| Jul 9 2009 11:24:11:693AM | 1090709007 | Steve Wolfe | Shot#7: I see no magnetics errors. The zcur is moving up before the zcur gain comes on at .02sec so it isn't the zcur feedback. The Br0 is going positive, starting at .01sec, and it's not clear why. Feedback seems to be trying and failing to compensate. Index looks possibly too high. Next: decrease br0, increase pg4, cross fingers |
| Jul 9 2009 11:58:40:980AM | 1090709008 | Steve Wolfe | Shot#8: decrease br0 from .0015 to .001, increase pg4 from 13 to 15, cross fingers plasma full length again density starts up at 0.85sec We are trying to track down why the dpcs init software is suddenly throwing spurious errors, after the reboot. I have edited dpcs_fizzle_init so that it clears the !error_state at the bottom, because Josh thinks that may be it. He's editing /usr/local/cmod/idl/dpcs2/dpcs_startup |
| Jul 9 2009 12:31:45:883PM | 1090709009 | Steve Wolfe | Shot#9: Just a repeat, no dpcs changes to shot, several changes to dpcs software. plasma full length Density is still rising after 0.85sec, halpha goes up too. What's it interacting with? That's about when EFIT says the outer strike comes off the floor onto the plate. OK, raise ZXL earlier. |
| Jul 9 2009 12:43:03:180PM | 1090709010 | Steve Wolfe | Shot#10: raise zxl from -.015 to -.005 plasma full length Now the density is flat at 7.2e19, and the gas is puffing weakly throughout. I seem to have moved away from where it was sourcing? I expected the opposite response, but... Next: repeat. Brian will poke probes |
| Jul 9 2009 01:11:28:947PM | 1090709011 | Steve Wolfe | Shot#11: repeat. Brian will poke probes plasma full length |
| Jul 9 2009 01:20:53:853PM | 1090709012 | Steve Wolfe | Shot#12: repeat. Brian will poke probes plasma full length H/D dropping from .35 to .22 during pulse |
| Jul 9 2009 01:27:25:367PM | 1090709013 | Steve Wolfe | Shot#13: Decrease nl04 from 7 to 6e19 Brian still poking. plasma full length Density flat at 6.6e19, gas puff hovering near zero for most of pulse. M3/M4 up to .9, H/D between .25 and .3 during flattop Startup still looks good, but Ip/Bz is pretty high and the zmeter burnout is fast. I'm thinking of increasing pg4 again. |
| Jul 9 2009 01:42:53:820PM | 1090709014 | Steve Wolfe | Shot#14: Repeat, no dpcs changes plasma full length nl04 still at 6.6e19, H/D around .3, M3/M4~0.9, M16 not ratcheting as much as earlier, typically <4e-9 before pulse Next: another repeat, the BLAB and Dan will go to cell to check trigger cables. |
| Jul 9 2009 01:51:42:790PM | 1090709015 | Steve Wolfe | Shot#15: Repeat, no dpcs changes plasma full length M3/M4 climbing between pulses again, was at 1.0 before 15; I guess this means it's bringing out the H. H/D between .3 and .35 in flattop, rising in rampdown Next: Repeat after cell access |
| Jul 9 2009 02:11:08:070PM | 1090709016 | Steve Wolfe | Shot#16: Repeat, no dpcs changes plasma full length. Just chugging along. Brian's stuff is working on this shot (except for one module he removed fromt the cell whose overcurrent light was on continuously). The heat footprint display updated, shows 50C rise on the outer plate near/above the efit strike; limiters look pretty cool, ~10C near midplane of GH. M3/M4 still around 1, H/D~0.3 Next: repeat, let BLAB clean probes. |
| Jul 9 2009 02:26:05:760PM | 1090709017 | Steve Wolfe | Shot#17: repeat, let BLAB clean probes. Plasma full length. FSP poked this time. Starting to pick up a few hards and an incipient marfe. Brian's cpci is less fixed than it appeared; worked for one shot, not this one. Next: increase pg4 |
| Jul 9 2009 02:40:20:383PM | 1090709018 | Steve Wolfe | Shot#18: increase pg4 from 15 to 17 plasma full length, no fsp this time Still some hards (10^12 scale), less sign of a marfe. M3/M4 climbing again, up to 1.15, hydrocarbon peaks pretty stable. H/D between .3 and .35 Next: take pg4 up to 20msec |
| Jul 9 2009 02:50:50:133PM | 1090709019 | Steve Wolfe | Shot#19: increase pg4 from 17 to 20msec plasma full length Neuts_hards back down to 10^11 range Early Ip/Bz back on scale (barely) in the init scope. H/D~0.35 Next: repeat |
| Jul 9 2009 03:15:19:587PM | 1090709021 | Steve Wolfe | Shot#21: Start rxl at +.005 instead of 0. IGT@INIT=2.0e-6 plasma full length Even less hards than last time, and the injection seems gone or at least smaller. However the startup is developing a hesitation around 15msec and then a surge around 18-22msec. H/D .3 to .35 Next: drop pg4 by 1msec |
| Jul 9 2009 03:26:00:273PM | 1090709022 | Steve Wolfe | Shot#22: drop pg4 from 20 to 19msec fizzle. This one seems to have been running up again, although not as far as on shot 7. Next: raise pg4 back to 20 and drop Br0 |
| Jul 9 2009 03:35:37:820PM | 1090709023 | Steve Wolfe | Shot#23: raise pg4 from 19msec to 20ms Br0 from .001 to .0005 (probably a bad idea) plasma full length, but the hards are back, high 10^12 scale. Next: Go for upper null |
| Jul 9 2009 03:57:45:633PM | 1090709024 | Steve Wolfe | Shot#24: Go for upper null Seg 2 off, seg3 on Drop nl04 target from 8e19 to 7e19. raise pg4 in seg1 again from 20 to 22msec Did a build_all, no errors or warnings. Spot check the mag predictors it looks like they've been called since the btor-pickup update. Load it Load at 9-Jul-2009 15:42:57.00 Open tree /home/wolfe/pcs_scratch -1 Open tree done Expect a fizzle (blame it on the pg4 increase) plasma to 1.87sec, big marfe at 1.3, tci jumps in rampdown (fin?) Neuts_hards in the mid 10^11 range. Looks like a reasonable upper null, big right gap (2cm) ssep~+2cm, rxu seems to move in around the time of the marfe. Bigger increase of M28 during this shot, M3/M4 down after to ~1 Next: change programming that calls for rxu to sweep in during flattop |
| Jul 9 2009 04:08:59:523PM | 1090709025 | Steve Wolfe | Shot#25: Hold RXU at -.025 from 1.1sec to 2sec plasma full length, same late flattop marfe, a little later this shot. Startup has a bit of hesitation, better drop the fill again. No H/D reading until the rampdown marfe because of low signal. M28 has a big peak again, M3/M4 rose to 1.15 before pulse down to .95 after Next: keep Zxu flat instead of rising, drop pg4 |
| Jul 9 2009 04:16:22:493PM | 1090709026 | Steve Wolfe | Shot#26: keep Zxu flat at +.005 instead of rising, drop pg4 from 22 to 20msec change Ref9-12 in seg 3 from Ip to 10, since there are no Ip referenced wires in this seg and B21_PROJ on wire 9 should be 10-based, although since it's zero it doesn't matter. plasma full length. Still getting a rampdown marfe in the lower divertor, but only in rampdown this time, and shorter. Startup hesitation is getting a little worse. Next: Decrease target density from 7 to 6e19. |
| Jul 9 2009 04:34:25:570PM | 1090709027 | Steve Wolfe | Shot#27: Decrease target density from 7 to 6e19. Drop pg4 from 20 to 18msec plasma full length No hards, late rampdown marfe is there at 1.7sec startup hesitation a little better Density did not come down, still at 7.2e19. Next: repeat, and see if we can get the density down. |
| Jul 9 2009 04:41:53:180PM | 1090709028 | Steve Wolfe | Shot#28: Reduce pg3 puff in seg3 to let density come down, if it will plasma full length less of a marfe, no hards nl04 down to 6.6e19, so it must have been the pg3 feedforward Next: Now try a couple of inner wall shots. |
| Jul 9 2009 04:55:15:570PM | 1090709029 | Steve Wolfe | Shot#29: Now try a couple of inner wall shots. Seg3 off, seg2 on Clearin from 0. to -.015 (shot#23 had 11mm inner gap) rcur from .658 to .65 plasma full length a few (very few) hards, didn't look limited though. Very marginally limited, should have gone farther. Next: make clearin more negative, go to 1MA (per ESM request) |
| Jul 9 2009 05:18:50:477PM | 1090709030 | Steve Wolfe | Shot#30: clearin from -.015 to -.02, go to 1MA (per ESM request) Leave rcur alone, since there's a big outer gap already. Ip to -1.e6 IGT@INIT=2e-6, maybe should have dropped the fill again? plasma to 1.45sec, disrupts at EOF, Ip had dropped to 850kA. It was definitely limited this time, big marfe before the disruption loop voltage was around 1.8 in flattop, looks like OH1 ran into the rail, density ran up to nl04=1.1e20 (program value was 6e19, gas puff was off for whole shot. M16,M28,M14,M18 all up by about an order of magnitude M3/M4 only up a little, to 1.3 or so. H/D was around .5 during the shot. Ten minutes after the shot the IGT reading is 2.8e-6, high but not humongous as it was on 1MA disruptions last week. Of course, this wasn't really a 1MA disruption thanks to the railed power supply. END OF RUN. |
| Engineering Operator Comments | ||||
| Shot | Time | Type | Status | Comment |
| 1 | 08:57:46:787AM | Plasma | Ok | |
| 2 | 09:10:36:160AM | Plasma | Ok | |
| 3 | 09:26:30:177AM | Plasma | Ok | |
| 4 | 09:39:42:270AM | Plasma | Bad | No Power shot, critical failure during init |
| 5 | 10:27:14:113AM | Plasma | Ok | |
| 6 | 10:42:13:147AM | Plasma | Ok | |
| 7 | 10:56:43:957AM | Plasma | Ok | |
| 8 | 11:26:49:817AM | Plasma | Ok | |
| 9 | 12:24:31:960PM | Plasma | Ok | |
| 10 | 12:37:46:510PM | Plasma | Ok | |
| 11 | 12:50:54:993PM | Plasma | Ok | |
| 12 | 01:03:45:197PM | Plasma | Ok | |
| 13 | 01:18:09:913PM | Plasma | Ok | |
| 14 | 01:30:53:117PM | Plasma | Ok | |
| 15 | 01:43:33:133PM | Plasma | Ok | |
| 16 | 01:59:53:290PM | Plasma | Ok | |
| 17 | 02:12:36:353PM | Plasma | Ok | |
| 18 | 02:29:19:650PM | Plasma | Ok | |
| 19 | 02:41:57:523PM | Plasma | Ok | |
| 20 | 02:54:33:320PM | Plasma | Ok | |
| 21 | 03:07:18:290PM | Plasma | Ok | |
| 22 | 03:19:53:007PM | Plasma | Ok | |
| 23 | 03:32:36:383PM | Plasma | Ok | |
| 24 | 03:45:33:307PM | Plasma | Ok | |
| 25 | 03:58:25:117PM | Plasma | Ok | |
| 26 | 04:11:02:557PM | Plasma | Ok | |
| 27 | 04:25:53:727PM | Plasma | Ok | |
| 28 | 04:38:38:663PM | Plasma | Ok | |
| 29 | 04:51:13:990PM | Plasma | Ok | |
| 30 | 05:04:58:057PM | Plasma | Ok | |
| System Availability | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Jul 9 2009 08:57:20:897AM | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||