Archived Forum

Hi,

I suppose that i'm alone to use phase-angle control,
that explain i'm alone on that thread.,
I didn't have time to go really deep, but i have tried some tests without success.
The originally sketch is running since few time, and the analysis shows me that 75 to 90% of surplus power is diverted, without import power when the system is running.
Today i have only 1Kwc PV power, so there not lot of surplus power, but (if everything is ok) i will get 2.5Kwc next month.

I continue to learn and trying, i hope to find.

Franck

I think phase angle control is unpopular because expensive filters are likely to be needed to meet the rules concerning the injection of harmonic currents into the public electricity supply.

I cannot remember now, are you trying to convert Robin's later sketch or are you working with his Phase Angle sketch Mk2_PV_phaseAngle?

If you have not tried the phase angle sketch, I suggest you try that and see if and how it works for you, then develop it and change it to suit your needs.

You do know that you need to change the opto-trigger I.C. from the zero-crossing type to the random phase (non-zero crossing) type? (MOC30XX family - probably the MOC 3021, 22 or 23. The difference between the three is the sensitivity, therefore the current needed to drive it and hence the value of the current-limiting resistor between the output pin and the opto-trigger input.)

Hi Robert,

My MK2 is running with phase-angle sketch, but i need to send serial data and checking a temperature sensor. In that sketch, if i  modify the originally sketch, it's cause to much work in the loop and is not efficient anymore.

With Robin advices, the Emontx3_4_as_MK2Router sketch is more suitable, because the options I need, are there.
What i'm trying to do is using that sketch but in phase-angle way.

For the output hardware, I 'm using the moc3021+triac (trigger is active high, because I've made a mistake on my PCB design, but it works fine)
There is also another output which can driver an SSR (D2425), it' like a moc3041+triac.
That give me the possibility to use different ways, (phase-angle control or burst)
but for the moment, only the phase-angle control seems suitable with my import energy meter.

Franck

Hi,

to be sure, i have made new test today in burst mode (with change the moc)
results are the same as before, balancing correctly, but import and export energy meters increment one after the other, it's not the case in phase-angle control.

I have made that tests to be sure i was not mistaken before.
So, the phase-angle control is really the way to do for me.

I must find a way to update a sketch, with temp sensor (for activate an onboard fan) and a sérial datalog for energy diverted....the most important.

I understand that that way of work is not a priority in UK, maybe energy meters are defferents, in my case, it is not a choice.
But i don't have enough competence, so i'm learning.
Franck

I quickly looked at Robin's phase angle sketch. That is not the best place to start. You will find it much better if you start with one of the later burst mode sketches that use interrupts and have the temperature measurements in the main loop and away from the time-critical Interrupt Service Routine (ISR). What needs to be done - confirmed by Robin - is you should take that and remove the burst-mode section and replace it with the phase angle section from the earlier phase-angle sketch.

The serial communications also needs to go in the main loop.

Franck, for customers that are using hardware from my Shop , I am generally willing to provide software that has been modified to meet the customer's requirements.  This could include phase-angle control as well as temperature monitoring, RF datalogging, Serial etc. 

All of my code is freely available for forum members to use and modify, but I am not able to produce special versions for the emonTx on request for free.  I'm sure you will understand. 

Yes Robert, it's what i'm trying to do with the Emontx3-4-asMK2 sketch.

Robin, i understand what you mean, of course, but i didn't ask you to write a special sketch for me.
What i need is some advices to start well.

As i said before, i'm not familiar with arduino, but it's motivating.
I will try again this week.

Hi

i've made other tests today, I think that is the algorithm which not work.
I have tried, but i don't understand, whatever i've done ( in this algorithm) and whatever power avaible, it did divert around 666W/h ....(is it the devil in my MK2)

In originally Phase_Angle control, there is also this Data "firstLoopOfHalfCycle" which i could have not placed properly. It may cause troubles.

What is take my mind is the algorithm :
In the original Phase_Angle sketch, we got :

      if (energyInBucket <= 1300) { firingDelayInMicros = 99999;}
      else  
      if (energyInBucket >= 2300) { firingDelayInMicros = 0;}
      else
      {   
        // complex algorithm which reflects the non-linear nature of phase-angle control.  
        firingDelayInMicros =(asin((-1 * (energyInBucket - 1800) / 500)) + (PI/2)) * (10000/PI);
        if (firingDelayInMicros > 8500) { firingDelayInMicros = 99999;} // never fire

In the later sketches, the "energyInBucket" is became a long, so :

      if (energyInBucket_ long<= 1300L) { firingDelayInMicros = 99999;}
      else  
      if (energyInBucket_long >= 2300L) { firingDelayInMicros = 0;}

I hope that point is correct for for the thresholds! maybe not, but this part, disturb me with the algorithm!

      else
      {   
        // complex algorithm which reflects the non-linear nature of phase-angle control.  
        firingDelayInMicros =(asin((-1 * (energyInBucket_long - 1800) / 500)) + (PI/2)) * (10000/PI);

I've done many way to adapt it, (i mean with (long) or L) nothing has worked properly

I think my problem is at this point.

You may be suffering integer truncation.

If energyInBucket is a float or an integer, (-1 * (energyInBucket - 1800) will be the same type (a float or an integer). However, when you divide that by 500, if it was a float (which it was), it will divide OK, but if it is an integer, then the result of the division will be truncated to an integer (towards zero I think). From there on, you are working with the wrong number so everything is wrong. The easiest way to correct this is to force it to be a float by making it (-1.0 * (energyInBucket - 1800). When you do that, (energyInBucket - 1800) is done as integers but the -1.0, being a float, forces the result of the subtraction to be promoted to a float and the division and the rest of the arithmetic should work as expected.

In the later sketches, the "energyInBucket" is became a long, so :

      if (energyInBucket_ long<= 1300L) { firingDelayInMicros = 99999;}

No, that won't work.  In the later sketches, the value in the energy bucket is not a "float" within the range 0 - 3600.  Instead, it is a much larger "long" value using integer maths on a scale which reflects various factors including powerCal which is different for each hardware platform.

So, you won't want to set the phase-angle operating limit to 1300L.  Instead, you will want to set it to the equivalent value in Integer Energy Units (IEU).  In the code that you're using, a conversion variable will probably have been defined in setup(), something like IEU_per_Joule.  So you would set the limit to 1300 * IEU_per_Joule.

The reason for the complicated maths is because the graph of power against firing angle is an "S"-curve, the object is to straighten out the "S" so that the relationship between power and the energy bucket is closer to linear.

The complicated answer is the changing slope of the "S" represents a change in the loop gain, which could result in instability with operating point oscillating about the desired diverted power.

You need both my change and Robin's.

Thanks you guys, for explanations,

I understand the range problem, so i think i have to adapt it within range of capacity of energy bucket, maybe like that :
if (energyInBucket_ long<= 1300* CYCLES_PER_SECOND * (1/powerCal_grid)) { firingDelayInMicros = 99999;}

The algorithm must be also adapted with the range. Is it correct?

Both changes seems working,
and pass the 60w bulb test (pv simulation)
Test in real power tomorrow, i hope.
If everything is ok for few days, I'll post the code, maybe someone else could be interested.

Thank again , Robin and Robert for your advices which always make me going on good way

After that , i could work on my options, that is another story:
- one of option is reading a 50khz signal from the French energy meters (it's call "Téléinfo") it is a trame which is send to client, the most important are the indexes from the energy meter. So this tool will take the indexes and transmit them to serial datalog.
This hardware input is done with a SFH620.
- drive a fan for the triac heatsink, with the temp sensor (my MK2 is in rail din boxe)
- datalog on temp, indexes, and total energy diverted, so no need to transmit more than one sending per minutes
- maybe, receive data from serial, to activate an output, for example

It is my project, and it's why my hardware is a little different.

Franck

Here is a modified version of emonTxV3_4_as_Mk2Router which operates with phase-angle control.  The relevant code for the p-a control section is exactly as was posted in 2012. 

The p-a logic has been written with floating-point maths, but later versions of my Mk2 PV Router code all use integer maths for speed.  To overcome this mismatch, the content of the energy bucket is re-scaled to Joules before the p-a logic is applied at the start every mains cycle. 

To maximise the sampling rate, the ADC operates in free-running mode.  With 5 analog channels on the go, each set of samples takes approx 5 * 104 us = 520 us to complete.  During each 50 Hz mains cycle, the expected number of sample sets will be 20 ms / 520 us = 38.46.  By monitoring the minimum number of sample sets per mains cycle, any lost loss of data should be detected.  This value, as displayed at the Serial Monitor, has never dropped below 38.

The attached results file shows the system operating with various combinations of load and surplus power.  In unchanging conditions, the energy state is constrained very effectively by the p-a control mechanism, generally to within a range of around 10 Joules.  As conditions vary, the control mechanism finds its own balance point at a new part of the energy profile.  The phase-angle control mechanism operates over an energy range of 1000 Joules.  Beyond this range, the load is either fully on or fully off.  It may be possible for this range to be considerably reduced - I have not tried to do this.

As with the original version, relevant data for power, energy, temperature and Vrms are transmitted by RF every 5 seconds.  These values are also displayed at the Serial Monitor along with the minNoOfSampleSetsPerMC data.  Because most of the action takes place within the ISR and its helper functions, Serial statements may only be used in a few sections of this code.  Loop() is always a safe place for Serial statements.

When operating in p-a mode, there is a slight buzzing sound from the load, just as with a dimmable light.  Suitable filtering is recommended.

For supply meters that have minimal tolerance to reciprocating flows of energy, the phase-angle control version may have advantages over burst-mode alternatives.  I would be very interested to hear of any situations where only the p-a control version is suitable for diverting surplus power.

Happy to see your new sketch, Robin. Thank for your interest.
It could help someone else, like me, when the burst mode is not suitable with the meters.

Mine has well done yesterday ( today too) and seems work better than the original old one.
I'll test your's, this week-end, it 's very similar.
In my case, there is only 2 CT, so i had cut this part, but i had not cut the burst mode yet.
The algorithm part is in "checkProgress", before the triac driving, and i let it " long". (with the Robert change)
I have now my good point to start, the most important is done.
Thank again,
Franck

Franck,

If you wish to test my phase-angle Mk2 code and report your results, do please run the sketch without making any changes.  With CT4 around either of the 'live' supply wires and an output stage connected as described in the header, this sketch should work on an emonTx V3.4 without needing any changes.  If it doesn't, let me know!

Thanks, Robin
 

Ok, Robin,

i didn't have Emontx but,

i'll try it without changes, my CT (150R burden), the output stage is a moc3021 with BTA, so no problem, i think.

On mine, i'll try to reduce the range to see what is happening and i got a little surplus power between 10-20%, so i'll try to arrange that better.
Anyway, i'll give the results.

I'm not be able to check with your sketch, my hardware seems not working with it. It is crashing the atmega.
The problem is certainly caused by the i/o , because i'm using the D10 for the trigger, and it seems to me that it's used for the RF. (or other problem like that)
So, to do the test, I'll have to cut the rf part, like i had done on on my sketch..
I hope someone else could do that test on an Emontx, with all abilities.

On my side, i'm testing with sweet zone reduced to 3000, it's seems not affect the import meter, but reduce a little the surplus power, with a result approaching of 92% energy diverted.
During my MK2 was working today, the results of different meters are:
- import energy meter 56Wh
- export energy meter 70Wh
- diverted energy meter 886Wh

Further tests now will be with more PV power in august.

Franck

Franck,

I am sorry that this latest sketch is not of use to you.  I thought it was exactly as you had requested.  The sketch works well for me on an emonTx v3.4, including all features (RF, Serial, temperature)

The concept of a "sweet zone" is only really helpful for a burst-mode diverter.  As your meter will only work with a phase-angle controlled diverter, its "sweet zone" would appear to be very small.  It is certainly very much less than 3000 Joules.

While you are trying to get a diverter to work properly alongside your meter, it may be best for the processor to only be doing this one task rather than asking it to do RF datalogging as well.  Then you will have no difficulties with the IO port allocations.

I do hope you will get some more sun between now and August :)

Robin,
i'm sure your sketch work properly, no doubt.

I had followed your advices to adapt the emontx_3_4_asMK2 sketch in phase-angle control. That works well. My hardware is just different of Emontx, no RF and different i/o, (only 2 CT). So, I'm sure, if i cut the RF part, your latest sketch will work on my MK2.

Today, my PV power is poor (only 1Kwp south), so the surplus power is very little and for testing the MK2 part, i have to turn off some consumers in the house.
Next weeks, i'll have to install more PV power, (it will be 1KWp east+ 500Wp south+1KWp west)
That will be ready in august, so more PV power, more surplus power, and a new heater tank (2000w) spécialy for that.

My MK2 is ready to use in its first function, then, I 'll have to send once per minute some data on the serial port:
- total energy diverted
- temp heater tank
- (temp triac maybe)
- index of a power energy meter / or pulses counting
That's the project.

I do not understand why only phase_Angle control works well with my energy meters.
Franck

"I do not understand why only phase_Angle control works well with my energy meters."

The simple answer is your energy meter is designed to work in that way.

The more complicated answer is some electronic energy meters are designed to closely replicate the behaviour of a mechanical Ferraris meter, where the reverse rotation of the disc is prevented by a ratchet mechanism, and some are like yours. We have tried to explain this in the Building Blocks article Energy Meters.

In your case, the "Energy packet" must be very small, very much smaller than the 3600 J of most energy meters, and maybe only big enough for the energy transferred in one mains cycle.

hi,
here again,
more PV installed in august, but the the load got a problem in that time.
The heater resistor has been broken.

Anyway, the system is now running properly. The phase angle control suit to me.
Thank again Robin and Robert to have helped a novice.

please post the sketch you are using.thank you.

Hi dansir

The Sketch for Emontx V3.4 is allready in this page, by Robin

Mine is different, because my hardware is different, but works in same way.

hi,for this reason i ask to you to atach the sketch.i am using arduino uno board.thanks.

The Mk2 Router sketch with phase-angle control for use with an Arduino Uno is included on my Summary Page.  The relevant section is:

Mk2_PV_phaseAngle.  A phase-angle controlled variant.  This requires a trigger which acts immediately rather than a zero-crossing one.    Originally posted, with full supporting information, on 01/11/12 at http://openenergymonitor.org/emon/node/841, this code is available at
http://openenergymonitor.org/emon/sites/default/files/Mk2_PV_phaseAngle....

(the links may not work here, but they should be OK in the Summary Page version)

thank you

Hi,

i'm still using the phase-angle control,

there is a problem in my datalog, the "divertedEnergyTotal_Wh" stays to 0.

In the Robin's results.txt, the "WH@CT3", it seems staying 0.
I don't really need this value now, but i'm wondering why that part seems not working.

i could need later for monitoring.

there is a problem in my datalog, the "divertedEnergyTotal_Wh" stays to 0.

Do you have CT3 clipped around one core of the diverted power cable in the correct orientation?  Any current-carrying cable could be used to test and calibrate this part of your system. 

In the Robin's results.txt, the "WH@CT3", it seems staying 0.
I don't really need this value now, but i'm wondering why that part seems not working.

The most likely explanation is that I did not have a CT3 in place when I ran that test.  I would expect the CT3 sensor to support measurement of real power in exactly the same way as the original (burst-mode) version does.

as you know Robin, i'm using a different hardware.
(closer than yours, without display, and with other in/out)

The sketch in use is still mine, so it is probably the problem....
i will looking, but it it's not easy for me.

In my sketch, the burst mode still running (without effect, not wired),
only the phase angle is in used and works perfectly.

The datalog is as i want to, "grid power" "Vrms" "temp" are ok, just missing the total energy diverted.
I think, i have just missing something in the sketch, and maybe it's working in the burst mode and not in phase-angle. I don't know.
It 's maybe simple. But i still not be able to find.
(arduiono codes , it's like my english, i'm learning)

happyf, you enquired on this public forum why the results file that Robin had posted contains '0' for all the diverted power values.  The answer to this question is that I did not have a CT3 sensor in place at the time.  The main purpose of those results was to demonstrate the operation of my phase-angle control algorithm when running on an emonTx V3.4.  For that purpose, only CT4 was needed.

If you are running your own version of my software on some other hardware, please do not post your findings on this thread which is clearly intended for the emonTx v3.4.  Thanks.

Robin,

The answer to this question is that I did not have a CT3 sensor in place at the time. 

yes, of course, i didn't thought at that when i asked, it's silly.

When I started that thread with that title, it's simply for staying public on the forum with hardware for most.
I know, my hardware is different, and the sketch too. But the it's really the same way to use.
I don't want open a specific thread for myself, i prefer that staying for all, the phase angle control is already specific.
I will work on my sketch, it's the only part that's not work, and it's probably just a little mistake between the burst mode and phase angle control. I will try to find. As i'm not good on that, not sure.

Sorry that it's feel out of the thread.
Franck