Talk:BCC Read Range Tester
From PTAGISWiki
Contents |
Testing performed 10/14/2008
Test 1 No Flex
- The antenna was tuned up dry and a scope connected to the FDXB measurement.
- The baseline FDXB measurement was ~ .310V.
- The drive and screw were placed as close to the river railing and downstream railing as possible.
- No change in the baseline FDXB measurement.
- The unit was powered up.
- The baseline increased to .320V - .330V.
- The HMI was unplugged.
- No change.
- The unit was ran using the Automation Function (175K pulse/sec).
- Spikes up to .700V were witnessed when the unit started, stopped or changed direction. Once the unit was up to speed the noise averaged around .360V.
- The stainless steel box was placed over the drive.
- No significant change in any condition.
- The last 3 sensor were disconnected and the terminal strip was placed inside the SS enclosure.
- No significant change in any condition.
- Three different circuits inside the pittag room were tried as the AC power supply to the unit.
- No significant change in any condition.
- The HMI/PLC enclosure was moved outside the pittag room.
- No significant change in any condition.
- The HMI/PLC enclosure was moved into the Mechanical building.
- No significant change in any condition.
Test 2 Flex
- The unit was unwired at the HMI/PLC enclosure, one cable was eliminated and the rest were pulled through 3/4" flex conduit. All shields were floated at the Drive/Screw terminal strip and landed on the HMI/PLC enclosure terminal strip. The flex could not be hooked up to the Drive/Screw shield box so it was pulled inside the box, the inner metallic band and ground were vice gripped to a post on the box. Aluminum foil was place in all openings.
- The baseline FDXB measurement was ~ .280V.
- The drive and screw were placed as close to the river railing and downstream railing as possible.
- No change in the base line.
- The unit was powered up.
- The baseline increased to .290V - .310V.
- The unit was ran in Manual at 10K pulse/sec.
- Spikes up to .650V were witnessed when the unit started, stopped or changed direction. Once the unit was up to speed the noise averaged around .330V.
- A ground wire was ran from the HMI/PLC terminal strip and vice gripped to the the ground bus in the pittag room.
- The baseline FDXB measurement was ~ .280V.
- The drive and screw were placed as close to the river railing and downstream railing as possible.
- No change in the base line.
- The unit was powered up.
- The baseline increased to .290V - .310V.
- The unit was ran in Manual at 10K pulse/sec.
- No spikes were witnessed when the unit started, stopped or changed direction. Once the unit was up to speed the noise averaged around .340V.
Test 3 Read Range
- The read range was tested with a stick on the grating at the usual location.
- With the unit OFF -3".
- With the unit ON -8".
- With the unit Running @ 10K pulse/sec. -11".
Test 4 Flex Routing/Unit Relocation
Several different things were tried to increase the read range, none of which had a significant affect.
It should be noted that the majority of 'running' tests were conducted at 10K pulse/sec at this point as Automation was not available due to the removal of some of the sensors.
- The flex was taken all the way to the railing.
- No significant change in read range, but the noise dropped slightly.
- The flex was taped to the top of the railing.
- No significant change in read range, but the noise dropped slightly.
- The flex was routed at an angle towards the shield.
- No significant change in read range, but the noise dropped slightly.
- The unit was moved to the pittag side and there.
- A slight increase in read range and decrease in noise.
- The Drive and Shield box were moved under the shield.
- A significant change in read range(in the negative direction)and the noise increased dramatically.
Possible Solutions
Shielding
- Contact Jim Simmonson and see if he would be willing to build a shield box for the drive end of the unit.
- The shield box should be attached to the base plate so it is portable with the screw, be big enough to install a terminal strip and allow for flex/EMT/Rigid connections.
Cabling
- Try braided shielded cable (Juvenile Antenna Cable.
- Try ferrite beads.
Location/Orientation
- Try different distances from the parallel cable to the face of the antenna.
- Try different angles of the cable to the face of the antenna.
Issues to resolve
- What type of antenna will we use in the lab for testing.
- What type of transceiver will we use in the lab for testing.
- Does the pulse/sec have an effect on the transceiver?
Unit Stall Troubleshooting
Back Ground on the issue
The unit was found to be stalling on the way out when it was first installed in the field. It was found that reducing the speed in stopped the stalling condition on the way in. It was then found that the unit was stalling on the way out. This was not being monitored at the time it was discovered. I was on sight when this was discovered. While I was loosening the lid to investigate why this was happening the unit stopped stalling. It was determined that the lid may have been causing the unit to bind with temperature swings. The holes were opened up on the lid during the final installation and this appeared to eliminate the problem, the unit ran for more than one week with out an OT. Shortly after a visit to install the test tag in the unit the OT's started to occur on the way out again.
The following is a list of some of the things I've tried to eliminate the problem since the problem started again.
- I've put in time traps to capture the first time it does this and the latest.
- I've also set up the webport to email me when an OT occurs.
- This has proved to be the most helpful as far as troubleshooting is concerned.
There does not appear to be anything obvious that may be causing these Over Travels to occur.
Future Troubleshooting
I'd like to do the following in the following order in an attempt to solve this problem.
- Call Olympus Control or Kerk Motion to find out if there is a lubricant we can put on the screw.
- Troy 14:07, 19 February 2009 (PST) Not receiving any feed back from either.
- Put in a slight delay before sending the unit home.
- Troy 14:07, 19 February 2009 (PST) I put in a 10mSec delay and still received OT out alarms when set to go at every min(periodic alarms). Changed to every 20 sec and ran for 80 cycles and received no alarms. Put back to 60 seconds.
Troy 16:10, 19 February 2009 (PST)Just witnessed 5 sec delay not being enough. Put delay at .25 sec.
- Changed the OT threshold from .25 to .5 when the unit is traveling home.
- Take another look at the Accelerate speeds.
- Vist the site
- Remove the lids
- Ensure the grating clamps are tight
- Loosen the bolts at the drive end and the screw end and re-tighten.
- Re-install the lids and run the unit repeatedly to see if it will fail.
- Have Jim build additional supports to try and keep the unit from twisting with temperature.
Daily Documentation
2-20-2009
The unit OT'ed 68 times between 15:45 and 22:49 02/19/2009 and has not as of 0700 02/20/2009.
Troy 08:33, 20 February 2009 (PST)Ran a Read Range test and the unit stalled on the way home. The unit the started to stall more often than not on it regular 60 second travel interval. Changed the accel time from 500 to 50 on the Home command. OT's were at 59 when the change was made.
Troy 12:19, 20 February 2009 (PST) Found that the difference between 50 and 2000 for accel on Home was ~ 1 sec. 6.99sec at 50 vs 5.84sec at 2000. In speed and home speed at 120k. With accel set at 100 unit is inside the shield 6.4 sec. If I change the in speed and the home speed to 130k and leave the accel at 100 the time in shield is 6.03 sec. I ran a quick test to see how fast I could go so I set the in speed and home speed to 150k with an accel of 100 and it was 5.43sec.
Troy 14:57, 20 February 2009 (PST)Unit had an over travel during a read range test. Unsure why or where at in it's travel that it stalled. 8 min's later 2 more alarms. Reduced home accel time to 100 from 150.
2-23-2009
Troy 07:22, 23 February 2009 (PST)The unit ran all weekend long with no over travels. Traveling to site today to find out why bzz computer isn't sending in files. Unit is set up for 130k in and home with an accel of 100 for the home. Total time in the shield is 6.03 sec. Running in every 60 sec's.
On site testing
Upon arrival the unit was running great. It had ran over 4000 times with out an OT. The parameters were as follows:
| Test Date | Home Speed | Home Accel | Home Decel | In Speed | In Accel | In Decel | Test Freq | Tests Ran | Failures | Time In Field |
| 2-20-2008 | 130k | 100 | 1000 | 130k | 1000 | 2000 | 60 sec | 4000 | 0 | 6.03 sec |
I did some testing on site and was able to greatly increase the speed. I was able to get the time in the field down to 4.80 seconds. In order to run and the higher speeds I had to move the Home Proximity switch further away from the Home switch. This allowed the unit to slowly home. This move requires the user to pay more attention to the Home Decel time. If the Decel count is too high it will stop the unit rather quickly and take a long time to Home. If the Decel count is too low it won't slow down in time to properly Home and will appruptly stop when it reaches the Home switch. I left the unit to run over night.
2-24-2009
The unit didn't fair well overnight, in fact it had an over travel induce I_stop that didn't clear it's self. I addressed that issue in the logic and I also added a parameter in the web port so that the position the unit is at when an OT occurs will be sent with the OT alarm. I started to experiment with different parameters and the results are as follows:
| Test | Home Speed | Home Accel | Home Decel | In Speed | In Accel | In Decel | Test Freq | Tests Ran | Failures | Time In Field |
| 1 | 225k | 100 | 1500 | 225k | 250 | 750 | 60 sec | 630 | 120 | 4.80 sec |
| 2 | 200k | 100 | 1250 | 200k | 250 | 750 | 30 sec | 96 | 1 | 5.08 sec |
| 3 | 175k | 100 | 900 | 175k | 250 | 750 | 30 sec | 30 | 3 | 5.09 sec |
| 4 | 150k | 100 | 600 | 150k | 250 | 750 | 30 sec | 130 | 0 | 5.46 sec |
| 5 | 150k | 100 | 600 | 150k | 250 | 1200 | 30 sec | 300 | 3 | 5.34 sec |
| 6 | 150k | 80 | 600 | 150k | 250 | 1200 | 30 sec | 100 | 1 | 5.54 sec |
| 7 | 140k | 100 | 600 | 140k | 250 | 1200 | 30 sec | 90 | 2 | 5.61 sec |
| 8 | 130k | 100 | 425 | 175k | 250 | 1500 | 30 sec | 2060 | 11 | 5.34 sec |
| 8 | 130k | 75 | 425 | 185k | 175 | 1500 | 30 sec | 1060 | 1 | 5.48 sec |
| 9 | 130k | 75 | 425 | 185k | 150 | 1500 | 60 sec | 7000 | 0 | 5.48 sec |
| 10 | 130k | 75 | 425 | 185k | 150 | 1500 | 3600 sec | 7000 | 0 | 5.48 sec |
Note: On test 6 the unit failed while performing a read range test. It continued to fail after that so the speed was reduced. I also put in some time traps so I can tell if the decel on Home is set correctly. A time of ~ 2-3 seconds is good(f8:26).
2-25-2009
Unit failed over night (Test 7) so adjustments were made (Test 8). Unit ran with out failure until 16:20 and it failed once. An adjustment was made(Test 9)
2-26-2009
Troy 07:50, 26 February 2009 (PST)Unit ran overnight with out failing.
03-02-2009
At the site to check on the unit. The unit has ran 7000 tests (once/min)with out a failure. Switch the time between tests to 1 hour to see how it performs. See above chart for test results.
03-24-9009
Since the last update several tests have been ran. There was a failure on the 12th of March where the unit would not come out of the field (wouldn't home) That was most likely caused by me while testing remotely. I was updating the RedLion HMI so that it would be easier for office personnel to perform manual read range tests. I had the unit ran out to ~ 60" and was testing to make sure a 'move to big' would show up if the user was trying to move the unit too far when it OT'ed. I believe my attempts to get it to home faster caused it to get confused and I had no way of turning the unit off and then back on. I had Dean Ballinger turn the unit on then off but I didn't wait long enough for the unit to get home and assumed there was bigger problems so I had Dean turn the unit off.
I traveled to the site the next day. When I arrived at the site I turned on the system power and the unit started to home like it should. I tried several times to get the unit to fail in the same manner was not successful. I then installed a relay in line with the unit power. This relay can be toggled from the B2CC PLC if power is ever needed to be cycled. Below are the test results following my trip down there.
| Test | Home Speed | Home Accel | Home Decel | In Speed | In Accel | In Decel | Test Freq | Tests Ran | Failures In | Failures Out | Time In Field |
| 11 | 130k | 75 | 425 | 185k | 150 | 1500 | 15 sec | 3231 | 600 | 28 | 5.48 sec |
| 12 | 130k | 75 | 425 | 150k | 150 | 1500 | 15 sec | 2920 | 0 | 0 | 5.79 sec |
| 13 | 130k | 75 | 425 | 150k | 150 | 1500 | 30 sec | 11450 | 0 | 0 | 5.79 sec |
| 14 | 130k | 75 | 425 | 150k | 150 | 1500 | 60 sec | 7252 | 3 | 1 | 5.79 sec |
03-31-2009
The unit has ran a test every hour for a week with a few power outages. Curiously yesterday the unit was at home but the encoder said it was .1" from home. There are 22 OT while moving in to the field but I received no emails....? The unit also OT'ed while trying to send it home during a RR test but did not receive a OT Out count.
| Test | Home Speed | Home Accel | Home Decel | In Speed | In Accel | In Decel | Test Freq | Tests Ran | Failures In | Failures Out | Time In Field |
| 15 | 130k | 75 | 425 | 185k | 150 | 1500 | 1 Hour | 107 | 22 | 0 | 5.79 sec |
5-01-2009
All the equipment that was on the grating was removed and returned to the Kennewick lab. Attempts to solve the problems will continue.
