EVENT LOG FOR SITE MCJ Most recent activity to be listed first. First line of each entry lists date, time & who is reporting. Subsequent lines of each entry aligned under Time column. Do not use tabs, only spaces. Date Time Who What ---------- ----- -------- ----------------------------------------------- 12/26/2001 13:00 darren@p 62:InputSyncDetect,62:ReaderReset: Alarm was generated by a random reader reset. This problem is being addressed. . 12/13/2001 12:48 Dave Closed Multimon and PTTP program(s) on both computers. All data files have been transferred from McNary. Archived all data. Turned off data polling for MCJ. 12/13/2001 08:45 Dave In their final weekly report, SMP personnel note that "The McNary Juvenile Fish Facility is currently shut down for the season. The facility was put into primary bypass at 0815 hours on December 10." 12/10/2001 14:38 Dave McNary went to primary bypass at 0700h today (12/10/01). They're done for the year. 11/29/2001 15:07 Scott_Li The PTTP client has been restarted on these computers. 11/27/2001 09:08 Scott_Li The PTTP client has been disabled until Thursday , Nov. 29 01. 11/24/2001 12:28 darren@p 82:InputSyncDetect,82:ReaderReset,A1:LowExcCurrent,A2:LowExcCurrent: The reader reset alarm was caused by a random reader reset. The low exciter current alarm is a mystery. It went away I checked the next file and found no alarms. It may have been caused by facility maintenance. I will continue to monitor site for alarm. . 11/21/2001 10:58 Dave As a followup to Darren's posting yesterday, I spoke with Rosanna Tudor today. The site is currently collecting fish for 48 hours prior to transporting. Yesterday, they realized that they didn't know the number of fish collected during the 48 hours prior to 0700h, due to a "bizarre" counter malfunction. Instead of inadvertantly overloading the transportation truck, they released the raceways back to the river. The 48-hour collection included two PIT tags (probably from the sample) that were subsequently detected on the River-2 exit monitor. A total of seven PIT tags have been detected at MCJ since 11/19. 11/20/2001 14:38 Darren_C Brad Eby called and stated that from midnight on 11-18-01 to 07:00 on 11-20-01 fish were collected in the raceways and then released through the river exit monitors. So when viewing counts do not be alarmed by the numbers for MCJ River Exit 1 or 2. 11/19/2001 11:56 darren@p 83:InputSyncDetect: The transceiver did not seem to report that it had lost sync. I was going to check on the next file to see if there was any kind of messaging but it was not uploaded yet the database as of 12:00 pst. I can't see why this alarm was generated. I will check later today or tommorrow for the cause. . 11/16/2001 13:33 darren@p 71:ReaderReset,72:InputSyncDetect,72:InputSyncLost: Alarms were generated by a random reader reset. This problem will be addressed by PTOC personnel during the following pre-season scheduled work. . 11/15/2001 09:30 darren@p A1:ReaderReset,A2:BadOscFreq,A2:InputSyncDetect,A2:InputSyncLost: Alarms were generated by a random reader reset. This problem will be addressed this year. PTOC personnel and Destron-Fearing have come up with a solution (possibly). It will be tried at MCJ this year and will be deployed system wide if there are no more failures. . 10/29/2001 14:40 Dave_Mar All Multimon installations reacted to the end of Daylight Savings Time, even though the DST option was deselected in the Win98 Clock dialog box. All sites running Multimon closed their data files at 2:00AM on 10/28 (after generating four time stamps for 02:00:00), and have been generating files on an accelerated 3-hr schedule ever since (2:00, 5:00, 8:00, and 11:00 AM and PM). This occurred with all Multimon V7.04 sites, and with the V8.0 installation at MCJ. PTTP Uploader was also affected by the OS time shift, and has also been sending files one hour earlier than expected since 2:00AM. It's obvious that Win98 is "adjusting" the internal clock time even though, by deselecting the DST check box, we've told the OS to ignore displaying that change. We might try "fixing" this behavior by using the "Arizona" time zone setting, or modify the timers to use display times rather than the OS' internal timers. 10/22/2001 09:04 Darren_C I PCA'd into the site and set the Timer Tag on coil A1 back to fire every 60 Min. 10/22/2001 08:05 darren@p 23:InputSyncDetect,23:ReaderReset: Alarm was generated by a random reader reset. This situation is being addressed by PTOC personnel and Destron- Fearing. 10/19/2001 08:21 Darren_C I was unable to turn the test "OFF" but I did set it to fire only once a day. We will watch this over the weekend and see if any alarms occur. 10/19/2001 08:04 Darren_C I turned the test tag for coil A1 "OFF". We are testing the TASS panel to see if detects that the test tag did not fire. I will turn it back on at 2:30 p.m. today. 10/13/2001 17:14 darren@p 42:InputSyncDetect,42:ReaderReset: Alarm was generated by a random reader reset. This is being investigated by PTOC personnel and Destron-Fearing. 09/29/2001 19:57 dlwarf@p B4:InputSyncDetect,B4:ReaderReset: Ongoing problem. 09/28/2001 11:48 Dave Here's the fallout from the power outage on 9/27. We lost power between 08:07 and 16:58 (PST). According to Rosanna Tudor, the facility didn't switch to primary bypass until ~9:15 (PST), so it's possible there were tagged fish in the flumes for up to 75 minutes after the outage started that didn't get detected. After power was restored, according to the Multimon dataset, the facility switched from primary to secondary bypass at 18:45 (PST). Bottom line -- between 8:07 and 18:45, there may have been PIT tags and no power or power and no fish (including PIT tags) at MCJ. After checking that the clocks on the two PCs were in synch, I took the post-outage data from PC2 (MCJ01270.204-206), then stopped Multimon data collection, brought the clock back within 2 seconds of world time, and restarted collection. From PC1, I stopped (not closed) Multimon, synced the clock, restarted Multimon, grabbed the truncated file (MCJ01270.103) and today's files so far, and then put PTTP in auto mode. I also modified the properties on the PC1 Desktop PTTP shortcut so it does NOT start in auto mode. Locally, I appended a CLOSE tag to the truncated file and remailed it to intdata. 09/28/2001 10:03 Darren_C Rosanna Tudor called our office this morning to inform us that power was restored to the JFF. At 19:40 on 9-27-01 they switched back to secondary bypass. I will also be going down to look at the slide gate on the A separator. Bobby asked us to come down and check on it. 09/27/2001 16:15 Dave Rosanna called to notify us that the power was cut to the entire JFF at 9:05 am today. The problem is severe, and it may be days before the facility operates again. MCJ went to primary bypass at 10:15 am (PDT). Between 9:05 and 10:15, any fish dropping down the B-side were routed by the (open) sample gate into the sample tank. Rosanna will let me know when power is restored, when the system is switched to secondary bypass, and the disposition of any fish being held in the sample or transportation raceways between 7:00 and 10:15 today. 09/13/2001 11:29 Dave Responded to file disruption due to ~10 min. power outage at MCJ. MM was on (duplicate) MCJ01265.101. Resync'd on MCJ01265.105. Renamed duplicate MCJ01265.101 to MCJ01265.901 inside and out. Manually PTTP'd files 104 and 901 to Gladstone. Will append CLOSE tag to 104 after it posts this afternoon, and then resubmit it. Noted that clock on PC1 is 6:40 fast. Left PC1 with PTTP in auto mode, and MM in full screen. Logged into PC2 to verify operations there. Restored MM to full screen. Noted that clock on PC2 is 6:30 fast. Clocks between machines are within 30 seconds of each other, per our standard, but the clocks on both machines are more than five minutes "off" from real time, and should be adjusted on the next site visit to bring them back within our standard tolerance. 09/13/2001 10:02 Don_Warf Site personnel report that a power outage will occur this morning at 10:30. It is uncertain how long it will last. 09/10/2001 08:02 dlwarf@p 92:InputSyncDetect,92:ReaderReset: Ongoing problem. 09/06/2001 08:15 Darren_C A site maintenance check was performed. Test sticks were passed over the slide gates to check timing. No problems were found. 09/05/2001 10:52 Dave A power outage occurred at 3:00:02 am (PST), right at the beginning of the 002 file, and lasted ~10 minutes. Since the machines shut down before the 001 was transferred to Gladstone, there was no disruption or renumbering of the data files, other than the truncation of MCJ01248.002. I pcA'd that file to my machine, manually appended the CLOSE tag, and then submitted the file to the intdata loading queue. I then restarted PTTP on PC1, manually archived the 002 file, and manually transferred and archived the other outstanding files (001, 003, and 004). PTTP is now running in auto mode on PC1. I also pcA'd into PC2, and moved all but the current data file to the archive directory. Noted that both machines are running about 8 minutes fast. 09/05/2001 08:18 Darren_C As we probably found out by the load status the power outage was on the 5th and not on the 4th. I was mistaken on the date. The outage did occur and I will PCA into the platform and retrieve the files and start PTTP. 09/04/2001 13:19 Darren_C We were informed of a scheduled power outage at McNary for 9-4-01 at about 06:00 to 06:30 and is scheduled to last about 20 minutes. We will fix files remotely after power has been restored. 09/02/2001 08:57 darren@p 31:ReaderReset,32:InputSyncDetect,32:InputSyncLost: Alarm was generated by a random reader reset. This is an ongoing situation that is being addressed by PTOC personnel and Destron-Fearing. 08/31/2001 08:12 darren@p 61:ReaderReset,62:InputSyncDetect,62:InputSyncLost: Alarms on coil 62 were generated by a random reader reset from coil 61. This is still being investigated by PTOC Personnel and Destron-Fearing. 08/27/2001 08:06 darren@p 61:ReaderReset,62:InputSyncDetect,62:InputSyncLost,B2:InputSyncDetect,B2:R eaderReset: Alarm was generated by a random reader reset. This ongoing situation is being addressed by PTOC personnel and Destron-Fearing. 08/12/2001 19:20 dlwarf@p 83:InputSyncLost,84:InputSyncDetect,84:InputSyncLost,93:InputSyncLost: Ongoing problem. 07/25/2001 08:17 Darren_C A general site maintenance check was performed. No problems were found. I also spoke with WDFW site personnel about the tagging that has been going on. They will stop tagging either on Friday the 27th or Tuesday the 31st. This will depend on the amount that are sampled for tagging between now and then. Either way they will be done by the end of the month. We should expect to see the River 1 Exit monitor return to normal efficiencies. 07/13/2001 08:05 darren@p 21:ReaderReset,22:InputSyncDetect,22:InputSyncLost: Alarm was generated by a random reader reset. This has been an ongiong event and is being addressed by Destron-Fearing and PTOC personnel. 07/12/2001 09:43 Darren_C A General Site maintenance check was performed. No problems were found. 07/11/2001 11:36 Carter_S [Fwd: River 1 Exit Efficiencies] -------- Original Message -------- From: Darren Chase Subject: River 1 Exit Efficiencies To: Don Warf CC: scott livingston , Carter Stein ,Sean Casey Hi All, Last week when Scott and I were at MCJ I spoke with some personnel from WDFW about the releases from the raceway by NMFS. It was explained to me that they are tagging fish and then splitting them into 2 groups 1 group is transported and the other is being released from the raceway. The raceway is split into 2 raceways. The fish are crowded and the valve is opened, it does open slowly, but the fish will have a tendency to hang out until the water level drops and then they are leaving in groups. This is what is causing the low efficiencies on the River 1 Exit monitor that we are seeing about every other day. There is a possibility of this continuing until the end of July. It doesn't sound like there is anything that can be done to try and get some separation of fish. This is going to effect are overall efficiencies for the year and should be taken into consideration at the end of the year. If I get anymore information I will pass it along to you all. Thanks, D.Chase 07/11/2001 07:55 darren@p SLC500:CommsFailure: No technical explanation for alarm. The pittag in question was diverted and no further failures occured. We will monitor the site for further alarms. 07/09/2001 08:33 darren@p 83:InputSyncDetect,83:InputSyncLost: I cannot find any technical explanation for the failure. But the unit seems to working fine now. I will monitor the site for further failures. 07/08/2001 10:42 scottl@p 84:InputSyncDetect,84:InputSyncLost: ongoing problem 07/06/2001 11:12 Scott_Li PCA into MCJPC1 and manually submitted current data files successfully. 07/06/2001 09:55 Scott_Li Error in that posting... Files submitted were NOT day 187 file but rather 186. 07/06/2001 09:51 Scott_Li Noticed that pc1 had not submitted data since 7/5/01 File # 186.106(last file that was successfully sent to PTAGIS.) An appearent power outage at the faciltiy was from 20:39:40 7/5/01 to 22:46:40 7/5/01. PTTP is no longer in the Start group hence no auto upload after power outage.. Retrieved files 01187.207 and 208 and will submit to intdata@ptagis.org. Tried to manually submit data with PTTP uploader via PCA but was unsuccessful on both PC1 and PC2. History log in PTTP indicated the following. Client: STOR MCJ01187c.zip.mul Error submitting file: #20142, Cant build data connection, operation allready in progress. Tried restarting PTTP and still got the same error. Will follow up with the situation and try to remidy. 07/03/2001 08:09 darren@p SLC500:CommsFailure: Alarm may have been caused by the information traffic at the time. The pittag was diverted and everything after was diverted properly after. We will monitor this site for further alarms. 06/29/2001 22:56 darren@p 42:TestTagFailure,92:TestTagFailure: Both alarms were caused by the test tag firing when a pittag was in the feild. The test tags are firing on time. 06/29/2001 22:50 Darren_C A general site maintenance check was performed. No problems were found. I also retrieved the data for Sandy on the Oregon ladder and Washington ladder. 06/27/2001 09:14 Darren_C It appears that NMFS is tagging fish at the site. This would explain the low efficiencies on River Exit 1. Here are the tags per minute to show when the raceway was released. 26-jun-2001 06:51:25 109.09 |***** 99.99 |----------------------------|======O| 26-jun-2001 06:51:13 240.00 |***** 99.99 |----------------------------|======O| 26-jun-2001 06:51:08 400.00 |***** 94.88 |----------------------------O-------| 26-jun-2001 06:51:05 240.00 |***** 86.06 |----------------O===========|-------| 26-jun-2001 06:51:00 52.17 |**** 83.62 |-------------O==============|-------| 26-jun-2001 06:50:37 400.00 |***** 98.25 |----------------------------|====O--| 26-jun-2001 06:50:33 600.00 |***** 97.98 |----------------------------|====O--| 26-jun-2001 06:50:31 400.00 |***** 94.80 |----------------------------O-------| 26-jun-2001 06:50:28 600.00 |***** 83.62 |-------------O==============|-------| 26-jun-2001 06:50:26 600.00 |***** 90.92 |-----------------------O====|-------| 26-jun-2001 06:50:24 600.00 |***** 89.41 |---------------------O======|-------| 26-jun-2001 06:50:21 300.00 |***** 79.53 |-------O====================|-------| 26-jun-2001 06:50:17 300.00 |***** 85.96 |----------------O===========|-------| 26-jun-2001 06:50:13 600.00 |***** 80.31 |--------O===================|-------| 26-jun-2001 06:50:10 240.00 |***** 85.18 |---------------O============|-------| 26-jun-2001 06:50:05 300.00 |***** 98.35 |----------------------------|====O--| 26-jun-2001 06:50:01 100.00 |***** 99.96 06/23/2001 11:13 Don_Warf Coil efficiency low on River 1 Exit due to grouping. Will talk to site Bio. on Monday. Note tags per minute below. From Tass: MCNARY DAM JUVENILE (MCJ) Monitor Nbr: 5 -- RIVER-1 EXIT 0.37 tag/min Coil: 81 Mean (M) = 62.70% Std Dev (S) = 22.52% +--------------------+-------------+-------------------------------------- -------+ | End Time | Tags | Coil Efficiency | + Of | Per +------+--------------------------------------+ | Detection Interval | Minute | % |+- M-3S Mean(|) 100% -+| +--------------------+-------------+------+| |+ 22-jun-2001 10:20:52 0.10 | 100.00 |----------------------|=============B 22-jun-2001 06:51:38 80.00 |**** 90.00 |----------------------|=========O---| 22-jun-2001 06:51:23 400.00 |***** 70.00 |----------------------|==O----------| 22-jun-2001 06:51:20 400.00 |***** 40.00 |--------------O=======|-------------| 22-jun-2001 06:51:16 44.44 |*** 25.00 |--------O=============|-------------| 22-jun-2001 06:50:48 300.00 |***** 30.00 |----------O===========|-------------| 22-jun-2001 06:50:44 600.00 |***** 35.00 |------------O=========|-------------| 22-jun-2001 06:50:42 200.00 |***** 70.00 |----------------------|==O----------| 22-jun-2001 06:50:36 400.00 |***** 45.00 |----------------O=====|-------------| 22-jun-2001 06:50:33 400.00 |***** 65.00 |----------------------|O------------| 22-jun-2001 06:50:30 100.00 |***** 85.00 |----------------------|=======O-----| 22-jun-2001 06:50:18 0.00 | 95.00 |----------------------|== 06/12/2001 16:52 Dave This morning I received a list of 74,246 PIT tags implanted in Lyons Ferry fall chinook and released in the Snake River at various points above Lower Granite Dam. NMFS had previously requested use of Multimon SbyC capabilities to identify and transport 100% of these fish encountered in the JFFs at Lower Granite, Little Goose, Lower Monumental, and McNary dams. I assigned these tags an Action Code of "86" and an ID label of "LYFEFC". I then generated new Multimon database (.db) and map (.map) files for each of our interrogation sites at GRJ, GOJ, LMJ, and MCJ, with filenames of "grj01163", "goj01163", "lmj01163", and "mcj01163", respectively. The files were deployed, upstream to downstream, between 2:40pm and 3:30pm PST. The map files at all four sites utilize a Separation Protocol setting of SP4 (divert 0 of 1) to defeat the default divert-to-river action at the separator gates, and to generate an action label of "SKIP_86" in the Multimon data file. This "SKIP" action is necessary simply to generate the proper disposition treatment in our Separation by Code Analysis (SBCA) reports. 06/08/2001 21:02 Darren_C The Adult noise monitor on the south end of the ladder was modified so that the data could be easily retrieved. Scott and I moved the data computer down the hill and placed it in a sealed box. We ran fiber optic transmission lines and a power cord from the original enclosure down the hill. This was done because safety issues were brought about climbing up and down the hill to retrieve the data. We will continue to collect all the data for NMFS and e-mail it to Sandy Downing. We also secured the new coil that has been placed outside on the deck of the Washington side ladder. 06/07/2001 08:13 scottl@p A2:InputSyncDetect,A2:ReaderReset,A3:InputSyncDetect,A3:InputSyncLost,A3:R eaderReset: Alarm was generated by PTOC personnel while performing on site maintenance. This was a follow up to a event log posting from 6-1-01. 06/06/2001 08:08 darren@p SLC500:CommsFailure: It appears that while there was a file transfer from Dave M. and PC2 did not have control of the gates yet. I am sure that this problem has been solved. 06/05/2001 15:40 Dave I modified the MCJ Multimon db file with "mcj01156.db". This version contains definitions for ACs 218-220. The modification does not affect the disposition of these AC classes, but enables the SBCA reports to track the appearance and disposition of those groups. The database now contains a complete complement of action codes in the range 181-248, as well as 7979 unallocated CPUD tags (AC110) and 3475 unallocated DPUD tags (AC180). 06/05/2001 08:05 darren@p A3:InputSyncDetect: Alarm has been acknowledged and will be monitored for further frequency. 06/01/2001 08:49 darren@p A3:InputSyncLost: Transceiver appears to not have a valid sync input. It is running proficiently and will be checked on the next site visit. 05/31/2001 07:49 Darren_C A General Site check was performed no problems found. 05/29/2001 07:51 darren@p 31:ReaderReset,32:InputSyncDetect,32:InputSyncLost: Alarm was generated by a random reader reset. This problem is being addressed by PTOC personnel and Destron-Fearing. 05/27/2001 09:17 darren@p A3:InputSyncDetect: Alarm was sent by transceiver but could not find where input sync had been lost. Will monitor site for further alarms. 05/26/2001 08:55 scottl@p 82:InputSyncDetect,82:InputSyncLost: ongoing problem, not a concern 05/26/2001 08:53 scottl@p 81:ReaderReset: Ongoing problem, not a concern. 05/25/2001 16:55 Dave I updated the Multimon db at 3:45 pm (PST) with "mcj01146.db". This database version replaces all action codes in the range 111-179 with action codes 181-249. The lower range of ACs effectively resulted in the transportation of 1 in 4 fish; the upper ACs direct all fish in those groups back to the river. The change was made at the request of Steve Smith, NMFS, who wrote today and said "... water for spill at McNary has become available. Night-time spill on bypass days will begin tonight at 1800h. I have requested that Dave change the action codes for all fish in the sep-by-code system so that no fish will be collected. This change to the database will occur before tomorrow's collection begins." 05/25/2001 10:21 Dave I updated the Multimon db to "mcj01145.db". This version defines ACs 145- 147 and 175-178. 05/23/2001 16:46 Dave I updated the Multimon db file with "mcj01143.db". This version replaces action codes 112 and 166 with 182 and 236. All fish in those action codes will now be diverted away from transportation vessels, rather than transported at a rate of 25%. 05/23/2001 15:15 Darren_C A site maintenance check was performed. No sticks were tested because the air to the gates was shut off. No problems were found. Labels were attached to the platform computers. 05/22/2001 10:44 Dave I updated the MCJ Multimon db with "mcj01142.db". This db version contains definitions for ACs 141-144 and 171-174. 05/22/2001 08:09 darren@p SLC500:CommsFailure: |16 A4 01/05/21 15:43:38 3D9.1BF1058A9E DivertAll| 49300 &SLC500 Comms has failed 01/05/21 15:43:39 *Unit 1, Subsampling, 01/05/21 15:43:39 #Subsample unit 1 = 1.0 percent, 01/05/21 15:43:39 This was probably the cause of the problem. We will monitor the site for further SLC Comms failure. 05/19/2001 08:17 darren@p SLC500:CommsFailure: Acknowledged. Will monitor site for further alarms. 05/18/2001 08:33 Dave I updated the Multimon db file with "mcj01138.db". This db version identifies ACs 135-140 and 167-170. 05/17/2001 08:25 Scott_Li General maintenence check found no problems to report. Revised the MM hardware files to reflect the Primay bypass gate disposition as "Pri.Bypass Inactive", meaning fish are being routed to the separator, and "Pri.Bypass Active", Fish are being diverted away from the separator. Also made the same change to the current hw file mcj01136.hw and copied them to the ftp server for archiving. 05/17/2001 07:04 Dave I updated the Multimon db with "mcj01136.db" just before 7:00am (PDT). This db version replaces the "divert all" Grant Co. PUD ACs with "transport 1/4" ACs, similar to the ACs for Chelan Co, PUD. 05/15/2001 09:43 Dave I updated the Multimon map file with "mcj01135.db". This version contains AC definitions for groups 133, 134, 234, 235, and 236. 05/15/2001 08:43 darren@p SLC500:CommsFailure: Alarm may ahve been generated by an abundance of pittags passing through the monitor. The pittag in question was diverted. We will monitor site for further alarms. 05/14/2001 08:03 darren@p A1:TestTagFailure: After checking the "Raw" File I found that the failure was due to a Pittag passing through the moniotr at the same time as the timer tag firing. The timer tag was and is working fine. 05/11/2001 11:55 Dave I updated the McNary Multimon database file with "mcj01130.db." This file version contains new references for ACs 131, 132, and 229-233. The change was implemented at ~9:30am (PDT). 05/09/2001 15:26 Scott_Li General maintenence chack found no problems to report. Today was a ByPass day so the Slide gates were not operating. No sticks were thrown on the separator gates due to this. Will consult with Don on the issue of throwing sticks thru the diversion gates when the facility is in ByPass.. Not sure if this activity would skew PUD's study. Check A-Diversion trancievers for noise levels due to the low eff. seen in today's reports. No root cause was determined for the low efficiency for C-31. Pushed and poked a little at the PCB's in the tranceiver , though maybe the heat was causing an intermittent open circuit or solder joint to open.. Will monitor situation.. Also, removed PCA from the slealth mode of operation. deleted the D-Word in the registry. By doing this , it will not have any effect on the Multimon operation. Also set the inactivity timers in PCA to 30 min and abnormal program termination for reconnect to 10. 05/09/2001 09:30 Scott_Li Coil 31 was noticed to have very poor efficiency for the previous day during a certain time frame. Below are snippets indicating the ~ time that the problem started and ended.. Coil 33 did not seem to be affected by this unknown.. Coil 32 had low eff. also but the status messages did not indicate high noise problem like C-31. Will stick test today during the General maintenence check if the slide gates are active. Things are good.. MCJ01128.105 01/05/08 09:13:17 $31 MESSAGE: Single-shot test with Test Tag. 01/05/08 10:29:12 |20 31 01/05/08 10:29:12 3D9.0EEEEEE4E8 Ignore| 48692 Things are bad... $31 MESSAGE: Single-shot test with Test Tag. 01/05/08 11:29:12 $31 MESSAGE: Test aborted due to system activity. 01/05/08 11:29:12 Still Bad.... MCJ01128.106 01/05/08 12:00:01 $31 Exciter current: 1.9A Signal level: 88% 01/05/08 12:26:03 $31 MESSAGE: Single-shot test with Test Tag. 01/05/08 13:29:11 $31 MESSAGE: Test aborted due to system activity. 01/05/08 13:29:11 $31 MESSAGE: Single-shot test with Test Tag. 01/05/08 14:29:11 $31 MESSAGE: Test aborted due to system activity. 01/05/08 14:29:11 Good again... MCJ01128.107 01/05/08 15:00:01 $31 Exciter current: 1.9A Signal level: 6% 01/05/08 16:26:0 05/08/2001 11:01 Dave I updated the Multimon database, containing definitions for ACs 126- 130, to "mcj01128.db". 05/05/2001 10:06 dlwarf@p 21:ReaderReset,22:InputSyncDetect,22:InputSyncLost: Acknowledged. 05/05/2001 10:03 dlwarf@p 21:ReaderReset: Acknowledged. 05/04/2001 17:56 Dave Steve Smith contacted me late this afternoon, concerned that Grant County PUD fish identified in action codes 151-158 were being transported. These action codes were provided by Steve earlier in the day, with the intention of simply monitoring the passage of those release groups. Steve and I clarified the method by which he will identify his groups to indicate whether or not they are candidates for transportation. I renumbered those action codes to 221-228, and regenerated an amended Multimon database. I remotely uploaded and implemented that new database, "mcj01125.db", at 5:30pm PDT. I observed that 1000f the fish with action codes 221-228 are being diverted to the river. 05/04/2001 11:44 Dave I updated the Multimon db file to "mcj01124.db". This file version includes new assignments for the following ACs: 121-122, 125, and 151-158. The changes were implemented at 10:30am (PST). 05/03/2001 08:09 darren@p 33:InputSyncDetect,33:ReaderReset,SLC500:CommsFailure: Alarms on coil 33 were generated by a random reader reset. This problem is being investigated by PTOC personnel and Destron-Fearing. The SLC Comms error appears to have happened while PTOC personnel was testing the facility. The site will be monitored for further SLC Comms errors. 05/02/2001 10:26 Dave I made changes to the MCJ MultiMon configuration files necessary to implement the NMFS mid-Columbia SbyC program. I installed a new map file, mcj01121.map. I installed a new database, mcj01121.db. I altered the counter reset value in the hardware files from 00:00 to 06:00, to correspond with the initiation/termination of daily transportation activities at the site. I saved the altered hardware files on PC1 and PC2 as mcj01122.hw1 and mcj01122.hw2, respectively. I also uploaded a replacement generic map file to both PCs, overwriting the original (and incorrect) mcj-gen.map file. I also uploaded minunzip.exe (again?) to both PC platforms, in order to extract the compressed db file. Because the SbyC map file is drastically different from the base/generic file used previously, I had to shut Multimon down, delete the default.cfg file, and restart "bare", then specify the new map file, alter the hardware file, and load the database, before shutting Multimon down again and restarting. This also required copying mcj01122.101 from its archive location back into the working data directory prior to any Multimon manipulations. All operations were accomplished without incident. Data was collected on, and diversion gates were controlled by, PC2 while PC1 was off-line. All changes were made by 06:00 (PST). 04/29/2001 10:53 Dave I noticed today that we were missing MCJ01116.103. I pcA'd into the site and manually 'Uploadered' the file to PTAGIS. 04/27/2001 13:55 Don_Warf Updated the hardware files in PC1 and PC2 in the PLC status message page to print the status of the main bypass gate. 04/27/2001 10:31 Don_Warf Installed limit switch on the main bypass above the separator. This switch will print in the data file: "MAIN BYPASS OPEN" when the bypass is in use and "MAIN BYPASS CLOSED" when the bypass is not in use. 04/17/2001 12:14 Don_Warf Visited site for a general maintenance check and found no problems. 04/16/2001 09:19 Darren_C On Thursday 4-12-01 The site was completely stick tested. All coils were tested except for 81,82,83, and 84 (River exit 1) and 91,92,93 (River Exit 2) with 100 0.000000e+00fficiency. The Efficiency breakdown will be posted at a later date. The gates were timed and adjusted. 04/07/2001 07:32 darren@p 31:ReaderReset,32:InputSyncDetect,32:InputSyncLost: Alarms were generated by a random reader reset on coil A1. This problem is being addressed by PTOC personnel and Destron-Fearing. 04/05/2001 13:18 Don_Warf SMP reports that the site watered back up at 14:30 yesterday. It was reported that the site was watered up and down several times between 9:55 and 14:30. 04/05/2001 06:12 darren@p B2:LowExcCurrent: The cause of the alarm is not apparent at this time but it does seem that the coil has recovered. I know that there was some work being performed on the separator yesterday and giving the time of the alarm there may have been some welding in the area. I will monitor this alarm for further problems. Don will be down there today so I will have him check out the transceiver. 04/04/2001 11:15 Don_Warf Brad Eby reports that they watered down at 9:55 for separator mods. He also reports that the NMFS mods will be random rather than a set schedule of every two days. 04/03/2001 09:34 Don_Warf This message is being written into the data file: #Divert during subsample unit 2, 01/04/03 03:17:44. Please ignore. This is either a Multimon 8.0 error or is a residual error of the About Time program that was removed yesterday. This site does not have Divert During Sample switches. 04/03/2001 08:56 Don_Warf Removed the About Time program on both PCs and set to PST. 04/02/2001 09:17 darren@p A1:TestTagFailure,A2:BadOscFreq,A2:LowExcCurrent,A2:TestTagFailure: Alarm was generated while PTOC Personnel was performing site maintenance on coil A2. The coil was re-wrapped and tuned for optimization. 04/01/2001 12:00 Dave The McNary Juvenile Fish Facility (JFF) was switched from Primary Bypass to Secondary Bypass at noon on Sunday, April 1, 2001. Collection, sampling, PIT tag detection, and transportation (if enabled) only occur when the JFF is in secondary bypass. This will be the normal mode of operation until mid-December. 03/30/2001 15:07 Darren Coil A2 on the separator monitor had to wrapped again. When the site was tuned I was unable to acheive an acceptable signal to noise ratio out of the coil. It has no been tuned for maxium readability. 03/30/2001 06:05 darren@p 32:TestTagFailure,43:TestTagFailure,52:TestTagFailure,62:TestTagFailure,83 :TestTagFailure,84:TestTagFailure,91:TestTagFailure,92:TestTagFailure,93:T estTagFailure,A1:ReaderReset,A1:TestTagFailure,A2:InputSyncDetect,A2:Reade rReset,A3:BadExcFreq,A3:BadOscFreq,A3:InputSyncDetect,A3:LowExcCurrent,A3: ReaderReset,A3:TestTagFailure,A4:InputSyncDetect,A4:InputSyncLost,A4:Reade rReset,B1:TestTagFailure,B2:InputSyncDetect,B2:ReaderReset,B2:TestTagFailu re,B3:TestTagFailure: Alarms were generated by PTOC personnel while performing Pre Season Timing and Tuning of all Detection/Diversion electronics. 03/28/2001 08:04 darren@p B2:InputSyncDetect,B2:ReaderReset: Alarm was generated by a random reader reset. This problem is being addressed by PTOC personnel and Destron- Fearing. 03/16/2001 08:48 darren@p 83:InputSyncDetect,83:InputSyncLost,84:InputSyncDetect,84:InputSyncLost,93 :InputSyncDetect,93:InputSyncLost: Alarms were generated by a random reader reset. This problem is being addressed by PTOC personnel and Destron-Fearing. 03/14/2001 09:19 Scott_Li Loaded Multimon Ver. 8.00 on Primary and backup computers via remote control for continued in-situ testing.Program version is still under evaluation 03/13/2001 14:41 Darren_C 2 Transceivers were replaced on 3-12-01. Transceiver 63 ( A Sample Tank ) was not receiving a good sync signal from Transceiver 62 I thought but after switching cables and doing some testing it turned out that transceiver 63 had a bad SyncIn. Transceiver 43 ( B Diversion ) was in an overrun condition, noise was about 80%, after removing cables and cycling the power the noise went away but the transceiver was replaced anyway. This transceiver will be tested in the lab before it is returned to Destron-Fearing. Transceiver 63 will be returned to Destron-Fearing on 3-13-01. 03/13/2001 09:00 darren@p 41:ReaderReset,42:InputSyncDetect,42:ReaderReset,43:BadExcFreq,43:BadOscFr eq,43:InputSyncDetect,43:LowExcCurrent,43:ReaderReset,43:TestTagFailure,61 :InputSyncDetect,61:ReaderReset,62:InputSyncDetect,62:ReaderReset,63:Input SyncDetect,63:InputSyncLost,63:ReaderReset,A3:InputSyncDetect,A3:InputSync Lost,A4:InputSyncDetect,A4:InputSyncLost: The alarms on coils 41,42,43,61,62, and 63 were generated by PTOC personnel working on transceivers 43 and 63 which were eventually replaced. 63 was replaced because of a bad SyncIn. 43 was replaced and brought back to the lab because it was noisy and was causing overrun conditions. It will be tested in the lab to see if the problem can be duplicated. The alarms on A3,and A4 were caused by a random reader reset. This problem is being addressed by PTOC personnel and Destron-Fearing. 03/12/2001 11:04 darren@p 63:InputSyncDetect,63:InputSyncLost: Alarms was generated by a bad sync input from transceiver 62. This will be solved today (3-12-01). The overrun condition that was appearing on coil 43 will also be taken care of today. 03/11/2001 09:31 darren@p 21:ReaderReset,22:InputSyncDetect,22:InputSyncLost,42:InputSyncDetect,42:R eaderReset: Alarms are being generated by a random reader reset. This problem is being addressed by PTOC personnel and Destron-Fearing. 03/11/2001 09:29 darren@p 63:InputSyncDetect,63:InputSyncLost: This alarms is being caused by a bad sync clock coming from transceiver 62. This problem will be addressed before waterup. 03/09/2001 15:12 scottl@p 43:InputSyncDetect,43:ReaderReset,43:TestTagFailure: ongoing problem , will respond 3/12 03/09/2001 15:11 scottl@p 63:BadOscFreq,63:InputSyncDetect,63:InputSyncLost,63:ReaderReset: Aware of the situation . will respond 3/12. 03/09/2001 15:10 scottl@p 62:InputSyncDetect,62:ReaderReset: Aware of the problem. Will respond to situation 3/12. 03/08/2001 08:52 scottl@p 43:TestTagFailure: Unit is in a constant overrun condition it has been remotely put in standby mode and will be checked out on my return trip home. 03/08/2001 08:49 scottl@p 84:InputSyncDetect,84:ReaderReset: Alarms were generated by a random reader reset. This problem is being addressed by PTOC personnel and Destron-Fearing. 03/08/2001 08:48 scottl@p 63:InputSyncDetect,63:InputSyncLost: Alarms were generated by transceiver 62 not producing a valid clock signal both units were remotely reset and problem seems to have gone away. I will still visiting the site on my return trip home today (3-8-01). 03/07/2001 09:06 darren@p 63:InputSyncDetect,63:InputSyncLost: Alarm is being generated by a faulty clock frquency being generated by transceiver 62. this problem will be addressed by PTOC on thursday 3-8-01. 03/07/2001 08:35 darren@p 43:TestTagFailure: Alarm is being caused by the transceiver in an overrun condition. The status report does not show any noise. This problem will be addressed by PTOC personnel on thursday 3-8-01.; 03/05/2001 08:17 darren@p 11:ReaderReset,12:InputSyncDetect,12:ReaderReset,12:TestTagFailure,13:Inpu tSyncDetect,13:InputSyncLost,13:ReaderReset,13:TestTagFailure,21:ReaderRes et,21:TestTagFailure,22:InputSyncDetect,22:ReaderReset,22:TestTagFailure,2 3:InputSyncDetect,23:ReaderReset,23:TestTagFailure,31:ReaderReset,32:Input SyncDetect,32:InputSyncLost,32:ReaderReset,32:TestTagFailure,33:InputSyncD etect,33:ReaderReset,41:ReaderReset,41:TestTagFailure,42:InputSyncDetect,4 2:ReaderReset,42:TestTagFailure,43:InputSyncDetect,43:ReaderReset,43:TestT agFailure,61:ReaderReset,62:InputSyncDetect,62:ReaderReset,62:TestTagFailu re,63:BadOscFreq,63:InputSyncDetect,63:InputSyncLost,63:LowExcCurrent,63:R eaderReset,63:TestTagFailure,71:ReaderReset,71:TestTagFailure,72:InputSync Detect,72:ReaderReset,72:TestTagFailure,73:InputSyncDetect,73:ReaderReset, 73:TestTagFailure,81:ReaderReset,81:TestTagFailure,82:InputSyncDetect,82:R eaderReset,82:TestTagFailure,83:InputSyncDetect,83:InputSyncLost,83:Reader Reset,83:TestTagFailure,84:In! putSyncDetect,84:InputSyncLost,84:ReaderReset,84:TestTagFailure,91:ReaderR eset,91:TestTagFailure,92:InputSyncDetect,92:ReaderReset,92:TestTagFailure ,93:InputSyncDetect,93:InputSyncLost,93:ReaderReset,93:TestTagFailure,A1:R eaderReset,A1:TestTagFailure,A2:InputSyncDetect,A2:ReaderReset,A3:InputSyn cDetect,A3:InputSyncLost,A3:ReaderReset,A3:TestTagFailure,A4:InputSyncDete ct,A4:InputSyncLost,A4:ReaderReset,A4:RocketPortNoEOT,B1:ReaderReset,B1:Ro cketPortNoEOT,B1:TestTagFailure,B2:InputSyncDetect,B2:ReaderReset,B2:TestT agFailure,B3:InputSyncDetect,B3:ReaderReset,B3:TestTagFailure,B4:InputSync Detect,B4:ReaderReset,B4:TestTagFailure: Alarms were generated by PTOC personnel doing on site maintenance work. The site was reflashed with firmware version 2.11hex. All transceivers were checked for Noise and Current and were adjusted if neccessary. 03/02/2001 15:49 Don_Warf Site PLC has been modified to control the sample gate timing. Site Bios have been trained to use the Dtam to enter settings. All gates will need to be timed at water up. 03/02/2001 07:58 darren@p 21:TestTagFailure,22:TestTagFailure,23:TestTagFailure,41:TestTagFailure,42 :TestTagFailure,43:TestTagFailure,71:TestTagFailure,72:TestTagFailure,83:T estTagFailure,84:TestTagFailure,B1:TestTagFailure,B2:TestTagFailure: Alarms were generated by a test being conducted by PTOC personnel and Destron-Fearing. 03/01/2001 08:24 darren@p 21:TestTagFailure,22:TestTagFailure,23:TestTagFailure,41:TestTagFailure,42 :TestTagFailure,43:TestTagFailure,71:TestTagFailure,72:TestTagFailure,83:T estTagFailure,84:TestTagFailure,B1:TestTagFailure,B2:TestTagFailure: Alarms were generated by a test being conducted by PTOC personnel and Destron-Fearing. The test is nearing completion. 03/01/2001 08:23 darren@p 92:InputSyncDetect,92:ReaderReset: Alarm was generated by a random reader reset. This problem is being addressed by PTOC personnel and Destron-Fearing. 02/28/2001 08:15 darren@p 21:TestTagFailure,22:TestTagFailure,23:TestTagFailure,41:TestTagFailure,42 :TestTagFailure,43:TestTagFailure,71:TestTagFailure,72:BadExcFreq,72:BadOs cFreq,72:TestTagFailure,73:TestTagFailure,81:TestTagFailure,82:TestTagFail ure,83:TestTagFailure,84:InputSyncDetect,84:InputSyncLost,84:TestTagFailur e,93:InputSyncLost,B1:ReaderReset,B1:TestTagFailure,B2:InputSyncDetect,B2: InputSyncLost,B2:ReaderReset,B2:TestTagFailure,B3:InputSyncDetect,B3:Reade rReset,B3:TestTagFailure,B4:InputSyncDetect,B4:InputSyncLost,B4:ReaderRese t,B4:RocketPortNoEOT,B4:TestTagFailure: Most alarms were generated by a test. The random reader resets on the B separator transceivers was caused by PTOC personnel who were on site doing PLC work. 02/26/2001 13:47 darren@p 21:TestTagFailure,22:TestTagFailure,23:TestTagFailure,41:TestTagFailure,42 :TestTagFailure,43:TestTagFailure,71:TestTagFailure,72:TestTagFailure,73:T estTagFailure,81:TestTagFailure,82:TestTagFailure,83:TestTagFailure,84:Tes tTagFailure,B1:TestTagFailure,B2:TestTagFailure,B3:TestTagFailure,B4:TestT agFailure: Alarms were generated by a test that is being conducted by PTOC personnel and Destron-Fearing. This test is nearing it's completion. 02/26/2001 13:46 darren@p 21:TestTagFailure,22:TestTagFailure,23:TestTagFailure,41:TestTagFailure,42 :TestTagFailure,43:TestTagFailure,71:TestTagFailure,72:TestTagFailure,73:T estTagFailure,81:TestTagFailure,82:TestTagFailure,83:TestTagFailure,84:Tes tTagFailure,B1:TestTagFailure,B2:TestTagFailure,B3:TestTagFailure,B4:TestT agFailure: Alarms were generated by a test being conducted by PTOC personnel and Destron-Fearing. 02/22/2001 08:46 scottl@p 61:ReaderReset: This is an ongoing problem system wide and is being addressed by Destron Fearing 02/22/2001 08:46 scottl@p 62:InputSyncDetect,62:InputSyncLost: This is an ongoing probem system wide and is being addressed by Destron Fearing 02/20/2001 10:25 darren@p 21:TestTagFailure,22:TestTagFailure,23:TestTagFailure,41:TestTagFailure,42 :TestTagFailure,43:TestTagFailure,71:TestTagFailure,72:TestTagFailure,73:T estTagFailure,81:TestTagFailure,82:TestTagFailure,83:TestTagFailure,84:Tes tTagFailure,B1:TestTagFailure,B2:TestTagFailure,B4:TestTagFailure: Alarms were genrated by a test being conducted by PTOC personnel and Destron-Fearing. 02/20/2001 10:23 darren@p B3:BadOscFreq,B3:TestTagFailure: The Bad Osc was caused by the 134.2Khz from coil B2 it does not appear that the sync frequency has returned. Transceiver B2 may have a bad sync output. This will be investigated on wednesday or thursday. The testtag failures are caused by a test being conducted by PTOC personnel and Destron-Fearing. 02/20/2001 10:15 darren@p 61:ReaderReset: Alarm was caused by a random reader reset. 02/20/2001 09:44 darren@p 62:InputSyncDetect,62:InputSyncLost: 62:InputSyncDetect,62:InputSyncLost: Alarm was caused by a random reader reset on coil 61. 02/20/2001 09:43 darren@p 62:InputSyncDetect,62:InputSyncLost: Alarm was caused by a random reader reset on coil 61. 02/14/2001 08:56 darren@p 21:TestTagFailure,22:TestTagFailure,23:TestTagFailure,41:TestTagFailure,42 :TestTagFailure,43:TestTagFailure,71:TestTagFailure,72:TestTagFailure,73:T estTagFailure,81:TestTagFailure,82:TestTagFailure,83:TestTagFailure,84:Tes tTagFailure,B1:TestTagFailure,B2:TestTagFailure,B3:TestTagFailure,B4:TestT agFailure: Alarms were generated by a test being conducted by PTOC personnel and Destron-Fearing. . 02/13/2001 13:11 darren@p 21:TestTagFailure,22:TestTagFailure,23:TestTagFailure,41:TestTagFailure,42 :TestTagFailure,43:TestTagFailure,71:TestTagFailure,73:TestTagFailure,81:T estTagFailure,82:TestTagFailure,83:TestTagFailure,84:TestTagFailure,B1:Tes tTagFailure,B2:TestTagFailure,B3:TestTagFailure,B4:TestTagFailure: Alarms are being generated by a test being conducted by PTOC personnel and Destron-Fearing. 02/13/2001 13:09 darren@p 93:InputSyncDetect,93:ReaderReset: alarm was generated by a random reader reset. This problem is currently under test. 02/13/2001 13:08 darren@p 72:LowExcCurrent,72:TestTagFailure: Timer tag failures are being caused by test being performed by PTOC personnel and Destron-Fearing. The LowExcCurrent looks to be either a blown fuse or a problem with the analog board. This will be investigated on 2-14. 02/08/2001 09:19 darren@p 21:TestTagFailure,22:TestTagFailure,23:TestTagFailure,41:TestTagFailure,42 :TestTagFailure,43:TestTagFailure,71:TestTagFailure,72:TestTagFailure,73:T estTagFailure,81:TestTagFailure,82:TestTagFailure,83:TestTagFailure,84:Tes tTagFailure,B1:TestTagFailure,B2:TestTagFailure,B3:TestTagFailure,B4:TestT agFailure: Alarms were generated by a test being conducted by PTOC personnel and Destron-Fearing. The test is soon to be completed. 02/07/2001 08:58 darren@p 21:TestTagFailure,22:TestTagFailure,23:TestTagFailure,41:TestTagFailure,42 :TestTagFailure,43:TestTagFailure,71:TestTagFailure,72:TestTagFailure,73:T estTagFailure,81:TestTagFailure,82:TestTagFailure,83:TestTagFailure,84:Tes tTagFailure,B1:TestTagFailure,B2:TestTagFailure,B3:TestTagFailure,B4:TestT agFailure: These should have been cleared on the last post. These alarms were generated by a test being conducted by PTOC personnel and Destron-Fearing. 02/03/2001 16:27 darren@p 21:TestTagFailure,22:TestTagFailure,23:TestTagFailure,41:TestTagFailure,42 :TestTagFailure,43:TestTagFailure,71:TestTagFailure,72:TestTagFailure,73:T estTagFailure,81:TestTagFailure,82:TestTagFailure,83:TestTagFailure,84:Tes tTagFailure,B1:TestTagFailure,B2:TestTagFailure,B3:TestTagFailure,B4:TestT agFailure: Alarms are being generated by a test conducted by PTOC personnel and Destron-Fearing. This test is nearing completion. 02/02/2001 08:12 darren@p 21:TestTagFailure,22:TestTagFailure,23:TestTagFailure,41:TestTagFailure,42 :TestTagFailure,43:TestTagFailure,71:TestTagFailure,72:TestTagFailure,73:T estTagFailure,81:TestTagFailure,82:TestTagFailure,83:TestTagFailure,84:Tes tTagFailure,B1:TestTagFailure,B2:TestTagFailure,B3:TestTagFailure,B4:TestT agFailure: Alarms were generated by a test being conducted by PTOC personnel and Destron-Fearing. This test will be concluded soon and the site will be returned to normal operations. 01/31/2001 08:03 darren@p 21:TestTagFailure,22:TestTagFailure,23:TestTagFailure,41:TestTagFailure,42 :TestTagFailure,43:TestTagFailure,71:TestTagFailure,72:TestTagFailure,73:T estTagFailure,81:TestTagFailure,82:TestTagFailure,83:TestTagFailure,84:Tes tTagFailure,B1:TestTagFailure,B2:TestTagFailure,B3:TestTagFailure,B4:TestT agFailure: Alarms generated by tests being performed by PTOC personnel and Destron-Fearing. 01/30/2001 13:11 darren@p 21:TestTagFailure,22:TestTagFailure,23:TestTagFailure,41:TestTagFailure,42 :TestTagFailure,43:TestTagFailure,71:TestTagFailure,72:TestTagFailure,73:T estTagFailure,81:TestTagFailure,82:TestTagFailure,83:TestTagFailure,84:Tes tTagFailure,B1:TestTagFailure,B2:TestTagFailure,B3:TestTagFailure,B4:TestT agFailure: Alarms caused by a test being performed by PTOC personnel and Destron-Fearing. 01/30/2001 13:09 darren@p A4:InputSyncDetect,A4:ReaderReset: Alarm generated by a random reader reset. This problem is under test by ptoc Personnel and Destron-Fearing. 01/26/2001 16:08 Darren_C Site platform was removed and the platform for 2001 was installed. All communications were established and functions tested. Site is operational and sending files. 01/24/2001 08:57 darren@p 21:TestTagFailure,22:TestTagFailure,23:TestTagFailure,41:TestTagFailure,42 :TestTagFailure,43:TestTagFailure,71:TestTagFailure,72:TestTagFailure,73:T estTagFailure,81:TestTagFailure,82:TestTagFailure,83:TestTagFailure,84:Tes tTagFailure,B1:TestTagFailure,B2:TestTagFailure,B3:TestTagFailure,B4:TestT agFailure: Alarms were generated from a test being conducted by PTOC personnel and Destron-Fearing. 01/23/2001 08:48 darren@p 21:TestTagFailure,22:TestTagFailure,23:TestTagFailure,41:TestTagFailure,42 :TestTagFailure,43:TestTagFailure,71:TestTagFailure,72:TestTagFailure,73:T estTagFailure,81:TestTagFailure,82:TestTagFailure,83:TestTagFailure,84:Tes tTagFailure,B1:TestTagFailure,B2:TestTagFailure,B3:TestTagFailure,B4:TestT agFailure: Alarms caused by a test that is being performed by PTOC personnel and Destron-Fearing. 01/19/2001 08:09 darren@p 21:TestTagFailure,22:TestTagFailure,23:TestTagFailure,41:TestTagFailure,42 :TestTagFailure,43:TestTagFailure,71:TestTagFailure,72:TestTagFailure,73:T estTagFailure,81:TestTagFailure,82:TestTagFailure,83:TestTagFailure,84:Tes tTagFailure,B1:TestTagFailure,B2:TestTagFailure,B3:TestTagFailure,B4:TestT agFailure: Alarms are caused by a test that is being performed by PTOC personnel and Destron-Fearing. 01/16/2001 07:57 darren@p 21:TestTagFailure,22:TestTagFailure,23:TestTagFailure,41:TestTagFailure,42 :TestTagFailure,43:TestTagFailure,71:TestTagFailure,72:TestTagFailure,73:T estTagFailure,81:TestTagFailure,82:TestTagFailure,83:TestTagFailure,84:Tes tTagFailure,B1:TestTagFailure,B2:TestTagFailure,B3:TestTagFailure,B4:TestT agFailure: Alarms were generated by an ongoing test being performed by PTOC personnel and Destron-Fearing. 01/12/2001 08:10 darren@p 21:TestTagFailure,22:TestTagFailure,23:TestTagFailure,41:TestTagFailure,42 :TestTagFailure,43:TestTagFailure,71:TestTagFailure,72:TestTagFailure,73:T estTagFailure,81:TestTagFailure,82:TestTagFailure,83:TestTagFailure,84:Tes tTagFailure,B1:TestTagFailure,B2:TestTagFailure,B3:TestTagFailure,B4:TestT agFailure: Alarms were generated by a test being performed by PTOC personnel and Destron-Fearing. 01/09/2001 07:46 darren@p 21:TestTagFailure,22:TestTagFailure,23:TestTagFailure,41:TestTagFailure,42 :TestTagFailure,43:TestTagFailure,71:TestTagFailure,72:TestTagFailure,73:T estTagFailure,81:TestTagFailure,82:TestTagFailure,83:TestTagFailure,84:Tes tTagFailure,B1:TestTagFailure,B2:TestTagFailure,B3:TestTagFailure,B4:TestT agFailure: All alarms were caused by a test that is being conducted by PTOC personnel and Destron-Fearing. 01/07/2001 00:25 darren@p 21:TestTagFailure,22:TestTagFailure,23:TestTagFailure,33:InputSyncDetect,3 3:ReaderReset,41:TestTagFailure,42:TestTagFailure,43:TestTagFailure,71:Tes tTagFailure,72:TestTagFailure,73:TestTagFailure,81:TestTagFailure,82:TestT agFailure,83:TestTagFailure,84:TestTagFailure,B1:TestTagFailure,B2:TestTag Failure,B3:TestTagFailure,B4:TestTagFailure: All alarms except for A- Diversion Coil 33 are a test being performed by PTOC personnel and Destron-Fearing. The alarm on coil 33 was caused by a Random Reader Reset. 01/05/2001 18:00 Dave Manually created new event log for 2001. ####End of Event Log for MCJ###