Hi Matt:
If it were inexpensive and reliable, then it would be a good thing. Until
it is, the clamp-on meter works for me.
This ties into the conversations about burned up modules, which I
frequently
see on projects that I service. I find that most of the module failures occur
due to overheating at the j-boxes. The failure of these contacts will often
begin as an intermittent contact, and result to a melt down or burn out. These
failures are causing such heat, that the glass frequently shatters. I have
felt
the glass getting as hot as a stove top, you could cook on it! Often times,
these faillures will take out the whole string.
These types of failures, or partial shading issues, can more quickly be
spotted and addressed with string level monitoring. I have installed many
Enphase systems, and I love being able to check all my projects outputs from my
desk. I recently saw that one of my customer's modules wasn't producing power,
I called him up, and he walked out to his ground mounted array. I asked if any
weeds were shading the module, and he said, "Yes." He pulled the grass out,
and
the output of the modules returned to full power on the monitor. Those types
of
issues will go one for ever in systems with less detailed monitoring.
Nick Soleil
Project Manager
Advanced Alternative Energy Solutions, LLC
PO Box 657
Petaluma, CA 94953
Cell: 707-321-2937
Office: 707-789-9537
Fax: 707-769-9037
________________________________
From: Matt Lafferty <gilliga...@gmail.com>
To: RE-wrenches <re-wrenches@lists.re-wrenches.org>
Sent: Mon, November 15, 2010 11:35:36 AM
Subject: [RE-wrenches] String Level Monitoring in Combiners
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
_______________________________________________
List sponsored by Home Power magazine
List Address: RE-wrenches@lists.re-wrenches.org
Options & settings:
http://lists.re-wrenches.org/options.cgi/re-wrenches-re-wrenches.org
List-Archive: http://lists.re-wrenches.org/pipermail/re-wrenches-re-wrenches.org
List rules & etiquette:
www.re-wrenches.org/etiquette.htm
Check out participant bios:
www.members.re-wrenches.org
