[RE-wrenches] String Level Monitoring in Combiners

[Nick Soleil]

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 <gilligan06 at gmail.com>
To: RE-wrenches <re-wrenches at 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


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.re-wrenches.org/pipermail/re-wrenches-re-wrenches.org/attachments/20101115/f250b457/attachment-0004.html>