Shop Learn
Help with dual axis solar tracker - Page 2 — Parallax Forums

Help with dual axis solar tracker

2»

Comments

  • @Crazzy450z said:

    @DigitalBob said:
    I would remake the relay board, Rly1 and Rly3 are the On/Off relays and Rly2 and Rly4 are the motor reversing relays. All power routing is on the board. Start new and opto the relays. Any picture of the prop1 board

    Hi Bob. We are also considering this option. Sorry, I do not currently have any pictures of the Prop1 board, as we haven't had any issues with it yet. As its -20C

    Hi Bob, Here are some pictures my first solar array's control box. This box houses the CPU (propeller) board with GPS, the crystal display interface and one relay board (for this array). I have three arrays total.

    The arrays (three (3) total) are mounted on fixed posts, with a azimuth rotor with motor, and a framework and vertical (altitude) motor attached. The solar panels are attached to this frame work. This assembly is sleeved (+- 18 tall) onto the post and held in place with 4 large pinch bolts.

    One item I am hoping to have help with is interpreting the program's overnight reset subroutine. Over night each panel zeros itself against the east limit switch (horizontally) and the lowest altitude (vertically). Then resets itself to fixed values. Is there a way to read or find what these fixed values are? This will allow me to accurately set the horizontal to an accurate compass reading.
    During high winds, a whole array can rotate and move slightly. So even with everything working correctly, we may not be accurately tracking the sun.

    Right now my issues are as follows.. My first array is working fine. Tracking the program correctly. My second array is not communicating with the propeller board. We are working on replacing the communication chips. But I can move it using the manual buttons. The third (last) array is currently hard against one of the limit safety switches on the horizontal. This is due to a major wind storm we had a couple weeks ago. I have to get up to the limit switches in order to get it to move and its just too cold and icy to do that right now.

    1024 x 768 - 114K
    1024 x 768 - 142K
    1024 x 744 - 150K
  • evanhevanh Posts: 12,230

    That's some severe weather conditions! It'll be tough to stop water from getting into exposed sensors. I noted the PCB reflection in the stainless housing for the motor PCB.

  • evanhevanh Posts: 12,230
    edited 2022-01-11 22:55

    Okay, with keeping those direction relays (sorry, I wasn't paying enough attention to the circuit) it's a good idea to add the suppression components.

    Use what's known as a TVS. Also goes by names like Transorb and Transil. They're beefed up Zenor diodes. Since the motors run both ways, get yourself an AC (back-to-back) variant. Buy a fat sucker on the list at, say, 30 volts blocking. The voltage isn't critical as long as it's higher than the battery charger will ever go.

    EDIT: Example would be a Littelfuse 5KP30CA. Place one across each pair of motor wires. Easiest place would be the screw terminal plugs at the motor PCBs.

  • Crazzy450zCrazzy450z Posts: 18
    edited 2022-01-11 22:56

    @evanh said:
    That's some severe weather conditions! It'll be tough to stop water from getting into exposed sensors. I noted the PCB reflection in the stainless housing for the motor PCB.

    The wind last week was gusting up to 100km/h or so..

    Control housings are outdoor rated 8"x 8" plastic electrical boxes. The horizontal limit switches are at the top, inside the azimuth head, they get the worst abuse. Those I think I have to replace and come up with a better solution to keep them out of the weather and last longer. The whole system has been in place probably 10 years or so..

  • I've only skimmed over the program but I'm kind of getting it. Use GPS location and time to track the sun throughout the day, shutdown any movement if the wind is too high. I'd add a few sensors to keep panels focused for the most power, adding a watt transducer input and sense for overcast conditons. Now I can see why Cannibal Robotics went out of business.

  • evanhevanh Posts: 12,230
    edited 2022-01-12 01:46

    You wouldn't want to be hunting all the time. It'd wear out the motors and gearboxes much faster. An approximation of sun direction does the job.

    There's bound to be improvements but that's common enough. One I'm expecting to find is ensuring the direction relays always have a delay either side of switching. Even one missing case will be bad for making arcing conditions worse. In theory the two direction relays should never have worn out.

    In my brief look at the sources I wasn't able to see where the relay sequencing occurs. The serial links certainly add layers.

  • jmgjmg Posts: 14,882

    @Crazzy450z said:
    We have had relays (RLY 1 through 4), as well as chips U1 (MCP23017) or U2 (ULN2803A) on schematic RelayV16_Page1 fail. Not usually not more then one item at a time. If the relay board has a chip failure we can still move the motors using SW1 through SW4

    Unfortinatually I do not know exactly what conditions cause them to fail. As I only notice after a few days when the panel has stopped in one position and not moving or zeroing out overnight.

    That's quite a list. Is there any correlation to weather events like lightning strikes ? I'd suspect a lot of injected energy is involved here.
    Did you open up & inspect the relays, and check which pins failed on the ICs ?
    Some more aggressive (nearby) lightning strike management might be a good first step ?

    @Crazzy450z said:
    what was installed and ran for many years (10+).... I have three (3) arrays total.

    Are the failures even across the 3 installs, or is one more prone ?

    @Crazzy450z said:
    The CPC1918 is out of stock at Digi-key. Do you think the CPC1909J work as well? It has a higher load current at 6.5 A.

    As well as those packaged parts, you can roll your own isolated SSR's using standard MOSFETS and voltage-generating opto-couplers ( Digikey call these Output Type : Photovoltaic )
    A family is here : They act like solar cells in a package, giving 8V of gate drive, at some uA, and include an internal discharge resistance to deliver sub ms ton/toff with 1000pF loads.

    https://www3.panasonic.biz/ac/e_download/control/relay/photomos/catalog/semi_eng_apv.pdf

  • evanhevanh Posts: 12,230
    edited 2022-01-12 08:14

    One that avoids the bogus prompts - https://www3.panasonic.biz/ac/e_download/control/relay/photomos/catalog/semi_eng_apv.pdf?via=ok

    JMG,
    They have an AC example wiring ... is that two N-types back to back in series? I suppose current can flow backwards in MOSFETs. I've never contemplated that before ... oh, that's how synchronous rectifiers gain their higher efficiency.

  • @DigitalBob said:
    I've only skimmed over the program but I'm kind of getting it. Use GPS location and time to track the sun throughout the day, shutdown any movement if the wind is too high. I'd add a few sensors to keep panels focused for the most power, adding a watt transducer input and sense for overcast conditons. Now I can see why Cannibal Robotics went out of business.

    Hi Bob,
    We do not have a wind speed or direction sensor. I do see that the programing has allowances for it, but I do not know how we could implement it. This is something I think might be a good idea to add, if it could be done cost effectively.

    Some solar tracking software uses only photo cells to keep the output at its max. This do keep hunting until they have the greatest output. Our output when everything is tracing and aligned properly is quite good. We did have one summer a couple years back where the stars aligned and we had all 3 panels working over the summer.

  • @evanh said:
    You wouldn't want to be hunting all the time. It'd wear out the motors and gearboxes much faster. An approximation of sun direction does the job.

    There's bound to be improvements but that's common enough. One I'm expecting to find is ensuring the direction relays always have a delay either side of switching. Even one missing case will be bad for making arcing conditions worse. In theory the two direction relays should never have worn out.

    In my brief look at the sources I wasn't able to see where the relay sequencing occurs. The serial links certainly add layers.

    If we knew the proper alignment and set up procedure, this would help maximize our output. This is all I'm looking to do, and hopefully make the system less prone to down time.

  • @jmg said:

    @Crazzy450z said:
    We have had relays (RLY 1 through 4), as well as chips U1 (MCP23017) or U2 (ULN2803A) on schematic RelayV16_Page1 fail. Not usually not more then one item at a time. If the relay board has a chip failure we can still move the motors using SW1 through SW4

    Unfortinatually I do not know exactly what conditions cause them to fail. As I only notice after a few days when the panel has stopped in one position and not moving or zeroing out overnight.

    That's quite a list. Is there any correlation to weather events like lightning strikes ? I'd suspect a lot of injected energy is involved here.

    We do not seem to have a lot of really close lightning strikes, but that is something i will start to track. The whole system is heavily grounded.. We do also have a metal barn about 100 ft away form the first array.

    Did you open up & inspect the relays, and check which pins failed on the ICs ?

    No we have not opened the relays or IC's to see where the failures are. I will check with my electronics guy to see if that's possible still.. I'm more of the mechanical side of the repairs around the farm..

    Some more aggressive (nearby) lightning strike management might be a good first step ?

    @Crazzy450z said:
    what was installed and ran for many years (10+).... I have three (3) arrays total.

    Are the failures even across the 3 installs, or is one more prone ?

    Failures of the relays has been spread across all three arrays. As for COM failures, it seems to have only been one case that I'm aware of.

    @Crazzy450z said:
    The CPC1918 is out of stock at Digi-key. Do you think the CPC1909J work as well? It has a higher load current at 6.5 A.

    As well as those packaged parts, you can roll your own isolated SSR's using standard MOSFETS and voltage-generating opto-couplers ( Digikey call these Output Type : Photovoltaic )
    A family is here : They act like solar cells in a package, giving 8V of gate drive, at some uA, and include an internal discharge resistance to deliver sub ms ton/toff with 1000pF loads.

    https://www3.panasonic.biz/ac/e_download/control/relay/photomos/catalog/semi_eng_apv.pdf

  • I see the quick easy fix as follows. Unsolder all four relay from the board. Solder jumper wires to the coil pads where the relays used to be. Buy an opto relay board, 4 or 8 channel under ardiuno section from mpja.com or amazon. Wire jumpers to the opto relay board, you will have to add a small power supply on the relay side to keep it isolated. This way the program stays the same. I was wondering if this is a hot water solar system or an electric PV.

  • evanhevanh Posts: 12,230
    edited 2022-01-13 05:38

    Substituting just the two single pole relays, for SSRs, is a lot simpler. The double pole changeover relays aren't easily done with solid state and shouldn't incur any wear anyway, as long as they are switched without load - Which should be how they are sequenced already.

    A typical SSR with a 5 Amp load is going to generate 15 Watts of heat. The heatsinks get big at such losses and not sizing the heatsink is a recipe for failure. That's where the CPC parts excel. The CPC1909J can deliver 5 Amps with only 250 mW of heating! No added heatsink even needed. Really cool. ;)

    Also, to make SSRs reliable they need to be overrated for switching current. I'd target a peak of 20 Amps for the 5 Amp motor. The CPC1909J has a peak rating of 25 Amps so that's a pass. The CPC1709J is ideal at 40 Amps peak.

  • evanhevanh Posts: 12,230
    edited 2022-01-13 05:55

    Had second look at the source code and think I've identified the relay sequencing part:

    pub MotorON(Array, Axis, Dir)                           '' Turns motor on  Array 0-7, Axis 0 = Horiz, 1=Vert, Dir 0 = Fwd, 1=Rev 
        If Axis == 1                                        ' VH: 1=Vertical 0 = Horizontal
          if Dir == 1                                       ' Dir: 1 = reverse
            MotorBits[Array] := %0000_1000                  ' Set Reversing Relay First 
            MCPoutput(Array,Data(Array))
    
          if Dir == 1                                       
            MotorBits[Array] := %0000_1100                  ' Now Turn on the power relay                                           
          else
            MotorBits[Array] := %0000_0100 
                                                            ' Horizontal motor starts here
        else                                                  ' Here assume horizontal motor
    
          if Dir == 1                                        ' Dir: 1 = reverse
            MotorBits[Array] := %0000_0010                   ' Set Reversing Relay First 
            MCPoutput(Array,Data(Array))
    
          if Dir == 1                                         
            MotorBits[Array] := %0000_0011                                            
          else
            MotorBits[Array] := %0000_0001          
    
        MCPoutput(Array,Data(Array))                        ' Send the final configuration                                                  
        MotorMoving := %1000_0000 | ((Dir << 5 | Axis << 4 | Array))' Set the motor moving byte - This is a flag for other cogs to see what's going on %10dv_0aaa
    
    pub MotorOff(Array)                                     '' Turns array motor off
    
      MotorBits[Array] := MotorBits[Array] & %0000_1010     ' Turn off both power first
      MCPoutput(Array,Data(Array))  
      MotorBits[Array] := 0                                 ' Turn off everything else
      MCPoutput(Array,Data(Array))
      MotorMoving := %0000_0000                             ' Clear the motor moving byte
    

    A little surprisingly, I'm not seeing any indication of explicit delays for accommodating switching times of the relays. There is the implicit serial timings but that won't be enough. It'll be rough on the relays as is.

  • evanhevanh Posts: 12,230
    edited 2022-01-13 06:08

    There's some odd delays in the serial routines:

    Pri MCPoutput(Device,d)                              '' Merges Motor bits and LED bits and sends
          Device := (Device & %0000_0111)<<1
          Outa[CS] := 0                                     ' Chip Select low - active
          SendByte( Device | %0100_0000)                    ' Device OpCode with address
          waitcnt(10_000 + cnt)
          SendByte(%0001_0011)                              ' Register Address for GPIOB $13
          waitcnt(10_000 + cnt)
          SendByte(d)   
                                                            ' AND for conflicts, OR Data together and output
          Outa[CS] := 1                                     ' CS line to HIGH
    

    And also

    PRI SendByte(d)
    
       Repeat 8
          OUTA[CL] := 0                                      ' Clock Down   
          if d & %1000_0000 > 0
            outa[DI] := 1
          else
            outa[DI] := 0
          OUTA[CL] := 1                                     ' Clock up    
          d <<= 1              
    
       outa[DI] := 0                                        ' Leave Data Low
       OUTA[CL] := 0                                        ' Leave Clock Low
    
       waitcnt(CNT + 10_000)
    

    So, each MCPoutput() has a double pause after the two address bytes and a final pause after the data byte is sent. Each pause being 12.5 microsecond. I guess all up including serial bits, maybe 100 us per MCPoutput().

  • evanhevanh Posts: 12,230

    Here's an updated file with what I hope is suitable delays of around 100 ms and 200 ms. They're just a guess at this stage and I'm hoping they don't cause any other complications with the rest of the program.

  • Hi, what I miss in the schematics is a free-running-diode for each of the motors?!
    Perhaps one of these CPC1709J per panel would be enough as only one axis is active at one time? It could perhaps be attached at P7/Anam.
    Only some ideas from many miles away...

  • evanhevanh Posts: 12,230

    You'll note I've crafted a couple of new functions for timing pauses - msPause() and usPause(). So, I've gone through that whole source file and replaced every single occurrence of waitcnt() with one of those two. The old values were done in sysclock ticks and if the clock freq ever got changed, unlikely I know, then each one with need recalculated. A benefit is both routines can run longer times as a result of the coarser granularity. And of course it's easier to understand when using standard units.

  • evanhevanh Posts: 12,230

    @"Christof Eb." said:
    Hi, what I miss in the schematics is a free-running-diode for each of the motors?!

    Already recommended - https://forums.parallax.com/discussion/comment/1533552/#Comment_1533552

  • @evanh said:
    Here's an updated file with what I hope is suitable delays of around 100 ms and 200 ms. They're just a guess at this stage and I'm hoping they don't cause any other complications with the rest of the program.

    Hi Evan, Thank you for looking into that..
    As I've never personally worked with uploading any of this software, do we need to record or save any manually entered data before we upload? I don't want to erase anything accidently.

    So to summarize, these program changes introduce delays in the timing of the relays. This should allow us to keep the regular relays for direction switching and only replace the power switching relays with SSR's and help protect both from spikes. Is that the thought process? How would we identify if these program changes causes any other issues? What should we watch out for?

    Are you able to advise me on my question regarding physically zeroing the actual horizontal head to the program? My hopes are that there is somewhere in the program (or entered data I can look up) a compass heading. I can use this to make sure the panels are facing the correct direction after the software "zeros" itself and resets. After I do this, I plan on marking the head and post to have a quick reference to see if anything has moved and be able to reset it if it has. As it is now we basically eyeball it until its facing the sun. I know, not really scientific or accurate. I figure doing this after the zeroing would be easier then any time during the day, as that would involve the math calculations and could introduce errors on my part.

    Thank you all for all the advice and help with this..

  • evanhevanh Posts: 12,230

    @Crazzy450z said:
    Hi Evan, Thank you for looking into that..
    As I've never personally worked with uploading any of this software, do we need to record or save any manually entered data before we upload? I don't want to erase anything accidently.

    I've not examined any other part of the software. But an update, via the programming tools, should be just like turning the power off and back on. If loss of power requires re-referencing then that'll be the case here too.

    So to summarize, these program changes introduce delays in the timing of the relays. This should allow us to keep the regular relays for direction switching and only replace the power switching relays with SSR's and help protect both from spikes. Is that the thought process?

    Yes. Also, because the change-over relays are staying in place, add those TVS diodes as an extra line of defence. They'll be particularly effective when using the manual buttons.

    How would we identify if these program changes causes any other issues? What should we watch out for?

    I'm just crossing my fingers at this stage. All my advise so far is based on general knowledge of relays being used to power motors. No knowledge of sun trackers sorry.

    Are you able to advise me on my question regarding physically zeroing the actual horizontal head to the program? My hopes are that there is somewhere in the program (or entered data I can look up) a compass heading. I can use this to make sure the panels are facing the correct direction after the software "zeros" itself and resets. After I do this, I plan on marking the head and post to have a quick reference to see if anything has moved and be able to reset it if it has. As it is now we basically eyeball it until its facing the sun. I know, not really scientific or accurate. I figure doing this after the zeroing would be easier then any time during the day, as that would involve the math calculations and could introduce errors on my part.

    Not sure how much help I can be without knowing the system better. I'll have a go at following how the bulk of the program works ...

  • evanhevanh Posts: 12,230

    You could start with just adding the TVS diodes to all units.

    Then work on just the most broken unit. In the hopes that all goes well there before taking the others out of action.

  • evanhevanh Posts: 12,230
    edited 2022-01-13 22:01

    Ah, looking at the photos, I see the programming port, J1, is missing the usual header pins. There was an adaptor, called Prop Clip, that could be used directly with that. But I don't think they're sold any longer. The one for sale these days is the Prop Plug - https://www.parallax.com/product/prop-plug/

    To update the program with the Prop Plug you'll have to add the header pins to J1 on each CPU board.

  • jmgjmg Posts: 14,882

    @Crazzy450z said:
    Are you able to advise me on my question regarding physically zeroing the actual horizontal head to the program? My hopes are that there is somewhere in the program (or entered data I can look up) a compass heading. I can use this to make sure the panels are facing the correct direction after the software "zeros" itself and resets. After I do this, I plan on marking the head and post to have a quick reference to see if anything has moved and be able to reset it if it has. As it is now we basically eyeball it until its facing the sun. I know, not really scientific or accurate. I figure doing this after the zeroing would be easier then any time during the day, as that would involve the math calculations and could introduce errors on my part.

    What you are doing already for alignment must be working ok ?
    Eyeball is going to be ok, as the alignment is 'top of sine curve' tolerant, but you could make a mushroom-sundial type alignment indicator, to check for any long term wander.
    I'd guess a GPS system is jog-differential, so assumes initial correct pointing (via user buttons) and applies corrections to that.
    I can see Hall and Lim tags, so those may be checked to correct for creep ?

  • evanhevanh Posts: 12,230
    edited 2022-01-13 22:59

    Hmm, the comments at the object list says nine cogs needed.

    OBJ                                                     ' Spawns 1 cog
      num           : "Numbers"                             ' No cogs                        
      CF            : "CrystalFontzDrvr"                    ' Spawns 2 cogs - CF driver, FDS
      SPI           : "MCP23s17cog"                         ' Spawns 2 cogs - MCP & FDS
      GPS           : "GPSRawData"                          ' Spawns 3 cogs - GPSMain, FDS, F32
      rom           : "I2C_ROMEngine"                       ' No Cogs, one Lock       
      db            : "FullDuplexSerialExtended"            ' 1 cog for debug
    

    Given there is physically only eight, clearly something isn't as stated.

    EDIT: Solved - There's no FDS in the motor control. It does its own SPI function.

    OBJ                                                     ' Spawns 1 cog
      num           : "Numbers"                             ' No cogs                        
      CF            : "CrystalFontzDrvr"                    ' Spawns 2 cogs - CF driver, FDS
      SPI           : "MCP23s17cog"                         ' Spawns 1 cogs - MCP
      GPS           : "GPSRawData"                          ' Spawns 3 cogs - GPSMain, FDS, F32
      rom           : "I2C_ROMEngine"                       ' No Cogs, one Lock       
      db            : "FullDuplexSerialExtended"            ' 1 cog for debug
    
  • @jmg said:
    What you are doing already for alignment must be working ok ?
    Eyeball is going to be ok, as the alignment is 'top of sine curve' tolerant, but you could make a mushroom-sundial type alignment indicator, to check for any long term wander.

    So I actually found a NOAA web site that you pick your location on the map, tell it the date ad time and it will tell you exactly were the sun is. I can use that to check the alignment..

  • I just noticed there is no header pins on the J1 connector. You'll have to solder some and pickup a prop plug, if you want to reload the program.

  • jmgjmg Posts: 14,882
    edited 2022-01-14 04:48

    @Crazzy450z said:
    As I've never personally worked with uploading any of this software, do we need to record or save any manually entered data before we upload? I don't want to erase anything accidently.

    It's good to be cautious :) - you might also want to confirm the code you have on DISK, actually matches your installed EEPROMs, before any changes are made.

    To download, you can send the code direct to RAM, or EEPROM, which then loads into RAM after RESET.

    Manual:

    In the Prop tool the function key F10 will only load the RAM and leave the EEPROM untouched. F11 will load the RAM and program the EEPROM

    and also this, old, but still seems alive and says can read EEPROM into file.
    https://forums.parallax.com/discussion/106911/yet-another-command-line-loader-unloader-0-07-pre1

Sign In or Register to comment.