@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.
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.
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.
@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.
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.
@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.
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.
@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.
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.
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.
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.
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().
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...
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.
@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..
@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 ...
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.
@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 ?
@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..
@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
Comments
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.
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.
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.
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.
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.
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 ?
Are the failures even across the 3 installs, or is one more prone ?
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
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.
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.
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.
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.
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..
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.
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.
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.
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 byteA 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.
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 HIGHAnd 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 perMCPoutput().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...
You'll note I've crafted a couple of new functions for timing pauses -
msPause()andusPause(). So, I've gone through that whole source file and replaced every single occurrence ofwaitcnt()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.Already recommended - https://forums.parallax.com/discussion/comment/1533552/#Comment_1533552
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..
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.
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.
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.
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 ...
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.
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.
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 ?
Hmm, the comments at the object list says nine cogs needed.
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.
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.
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:
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