[RE-wrenches] String Level Monitoring in Combiners

Matt Lafferty gilligan06 at gmail.com
Mon Nov 15 11:35:36 PST 2010


Hola Wrenches,
 
The topic of string level monitoring keeps coming up in my circles.
Personally, i think it's dumb in most non-R&D applications. Dumb is actually
a little weak for how i really feel about it, but that's the word i'll use
today. For the purpose of keeping it straight, i'm talking about real
strings. Not to be confused with re-combiner inputs. i advocate mapping and
monitoring all re-combiner inputs in central-inverter applications.
 
Part of my perspective comes from the fact that monitoring string data
inherently assumes that you are monitoring the system-level outputs anyway,
and know how to evaluate that data. Any "benefit" of string-level monitoring
must be over and above the benefits of monitoring without it. System outputs
are what matter, right? So why focus on strings? What are you waiting for?
Expecting something wierd to happen? Are you looking for binary information
(On/Off) or comparative data from one string to the next? How do you account
for instrumentation accuracy tolerances compared to module tolerances? Are
you looking for trends, such as seasonal shading from one string to another?
Or trends such as decreasing current in strings over time? Are you really
gonna make a point of going back and normalizing point-in-time current
measurements to point-in-time environmental conditions overlayed with
point-in-time soiling data and comparing them? Really? And then what? 
 
"Gee, there's a 7% difference in normalized String 5 from the same 15-minute
interval last year, George. Ya think we should go out and see if there's
something wrong?" 
 
The real answer is, no. You and yours are not gonna go out there for that
unless you are gluttons for punishment and don't have anything better to do.
Or simply don't know better. Here' why: Unless there is some other sign of
system output being off, it's not worth chasing the wild goose. 
 
If the system output is down from what it should be, you gotta go out and
find the problem anyway. When you get there, you will follow these steps:
 
A)  Visual observation 
B)  Data gathering from meters and displays
C)  Compare field observations and data to monitored data
D)  Determine whether or not there is actually a performance problem and
begin troubleshooting if necessary
E)  Troubleshooting Step 1: Clamp individual string inputs at the combiner
and compare to others.
 
You gotta go thru these steps anyway. Whether or not you have string
monitoring. So string monitoring doesn't save you a danged thing here.
 
Now, i know you youngsters trust that monitoring thing, and are ready to
jump right in the middle of String 5 and skip all that troubleshooting
nonsense... Hey, your i-phoidberry said it was String 5, right? You go right
ahead. Let me know how that works out for ya... Over time. No, silly... Not
"overtime"... Two words. Over. Time. Actually, when it comes right down to
it, i don't really care how it works out for you as much as i care how it
works out for the customer and your boss. You're getting paid whether it
works out or not. At least for awhile. The customer and your boss are most
likely NOT getting paid if it doesn't work out... Keep that in mind.
 
"Are you sure that's String 5? I thought String 5 was this one... Dang! We
didn't actually number the strings on the modules, did we?. I guess we gotta
open up that combiner anyway...."
 
And what are you gonna do to String 5 anyway? Pull it all apart and... What?
Without checking it side-by-side with the others in the combiner first?
Really? What's that gonna get you? A pile of modules about one string high
and no answers. That's what.
 
Ever had to have a test instrument calibrated? Ever heard of a thing called
"drift"? Measurement accuracy tolerance? Improper use of a calculator? How
about just being too uptight and data-centric to see the big picture? Ever
heard of any of these? I've already seen thousands of dollars wasted in
truck-rolls to "fix a string", only to find out that a channel on string
level monitoring board failed and there wasn't really a performance problem
after all. Unless you count the monitoring board's lack of performance as a
problem.
 
i can certainly see where having string level monitoring could be handy as a
reference. Assuming that it's working correctly and all. But only in a very
limited number of circumstances. For example, just before going out to do
maintenance on a system, you take a look across the graphs and see if there
are any problem-children out there so you can take an extra good look at
some part of the array when you are out there. Current, in this application,
is real-time and not cumulative. It's not like you're doing amp-hour
calculations... Which might have value in a
pocket-protector-basement-of-the-science-building sort of way... IF you were
doing high-resolution sampling and data parsing and actually still have a
pocket protector and reside in the basement of the science building. 
 
i advocate doing a clamp-compare-test, on each string in string inverters
and each re-combiner input for central inverters, as part of the periodic
maintenance and any diagnostic testing. Look, it's only gonna take a couple
minutes to do that anyway. 
 
>From a performance monitoring standpoint, i think string-level monitoring is
a waste of time and money. It introduces additional layers of reliability
and data management problems that, in my estimation, will be net losses over
the life of most PV systems. 
For me, the cons outweigh the pros. Am i all wet on this? What do you think?
 
i would like to get feedback from other Wrenches on this topic. Some
questions to get your contemplative juices going... 
 
Have you installed one or more systems with string level monitoring?
Have you specified one or more systems with string level monitoring?
Are you currently specifying and/or installing systems with string level
monitoring?
Have you had any seriously negative experiences with equipment of this type?
Have you had any seriously positive experiences with equipment of this type?
Please describe.
What do you see as the best feature associated with string level monitoring?
What do you see as the worst feature associated with string level
monitoring?
When that current sensor board fails at year 12, are you really gonna
replace it?
If string level monitoring is so spiffy, why not? 
 
Really looking forward to others' opinions on this topic.
 
Thanks in advance,
 
Solar Janitor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.re-wrenches.org/pipermail/re-wrenches-re-wrenches.org/attachments/20101115/47b3eddf/attachment-0002.html>


More information about the RE-wrenches mailing list