A different sort of cycling - faulty Legionella protection programme

On a slightly different topic, I've discovered a completely different sort of rapid cycling.

The VRC430f includes an anti-Legionella programme. Legionella can lead to the fatal Legionnaire's disease, and is a problem that can arise when water is kept within the bacteria's growth range of about 20-50C. I set my hot water temperature to 48C, since that's as hot as it needs to be for our hot water needs. But that means that the system is at risk of a Legionella infection, so I decided to try a once-weekly anti-Legionella programme.

It's supposed to heat the cylinder to 70C for one hour to kill the bacteria. However, it doesn't work as advertised. It uses a flow temperature of 85C and just tries to keep going at that temperature, despite the cylinder temperature (green) exceeding 70C:

As soon as the cylinder temperature is above about 70C, the difference between flow and return is not high enough for continuous firing. The result is that the boiler cycles rapidly for about two hours, with the cylinder temperature gradually rising to 85C. The jagged lines in flow temperature (red) and state number (light blue) represent cycling. Just as with microfiring, the boiler does not stay ignited for more than a few seconds before it turns off again, and then it tries again shortly afterwards. I'm not convinced that it's doing my pumps a whole lot of good to be too hot to touch, and it's definitely not a good thing for fuel efficiency or boiler longevity to be short cycling like this.

This is all with the boiler's flow temperature for cylinder charging (parameter d.78) set at 70C (orange), so the VRC430f must be over-riding that. The central heating demand in the graph starts at 6am (as you can see from the HC1_QuickVetoTemp), and is not affecting matters.

So not even the Legionella programme works correctly. Another software problem with the VRC430f, it seems.

Effect of d.2 on microfiring

Recent posts have described the d.2 parameter and the d.67 parameter, and the relationship they have to the period that the boiler waits before it tries to re-start.

One of the commenters (MikeH) reports having obtained good results with preventing microfiring by increasing d.2. Although my data suggested that this would not work in my case, I had not tried it. I now have, and indeed it does not help. Given my data, I'm not sure how it manages to make any difference for Mike.

Here are two graphs that show the period when I increased d.2. The first is just to show what was going in - the first two thirds or so, until about 5pm, shows a period of microfiring. There is then a transition to continuous burn when the target flow temperature goes up to 42C.

Now the same period, showing when d.2 was increased (from the default value of 20min to 60min) and what the countdown timer (d.67, in purple) was doing.

As expected, d.67 now starts at a much higher value - see the table in a previous post for how the actual starting value relates to the new maximum of 60min. But this has no discernible effect on microfiring, and certainly does not seem to have been the trigger for switching to continuous firing.

d.2 (via d.67) can be seen having its intended effect later in the day, at the end of the continuous burn. Then there is enough heat in the house, so the system needs to cool before the boiler can try again to maintain the desired flow. You can see in the following graph that d.67 does a full countdown from about 38min. This is what it should do, with these settings. But when the boiler tries to re-fire, it goes into an extended period of microfiring. This is what is should not do, and the high value of d.2 has not stopped it.

New owner's info provided

Many thanks to MikeH, who has filled out the form giving information on his set-up. It can be accessed on the "Info from owners with the problem" page.

Let's get some more examples up there - at the moment, combing through various posts and comments here and on diynot.com can reveal some detail about people's systems, but it would be much more convenient (and forceful, with respect to Vaillant) to have it all in one place.

Mike says that he made a formal complaint to Vaillant, with no useful outcome. As to what he thinks of their customer service:

"Poor.  I believe they know the issues and are "managing" the problem with minimum transparency.  Clearly they are modifying the boiler in the background but saying nothing to minimise costs and hassle.  No useful information provided."

Vaillant, must do better. Much better.

d.67 - the countdown to boiler re-start

Here's an example of what I take to be d.67, which is the countdown referred to in the last post. In my vrDialog data, I think it must be the parameter called RemainingBurnerblocktime_DK, which is in red in the graph below.

The graph shows a transition (at about 17:00) from micro firing to short firing. Note that the micro firing period does not show all the detail of what happens on a timescale of less than about a minute, so it is missing many periods of boiler status S.4 (i.e. ignited) and many of the short-lived peaks in flow temperature.

This begins to answer some of my questions from the last post. In particular, note that d.67 starts to count down when the boiler goes to state S.7, not when it goes to state S.8. However, I have noticed that it only does so when it is going to go to S.8 next (unless it decides it can re-fire first, as in the micro firing region). Somehow it must already know when it goes to S.7 that it is going to go to S.8 (which it certainly does not always do). The only example in this particular graph is at about 18:44, when it goes to S.7 but not then to S.8 - it did not start the d.67 countdown when it went to S.7, so it must have known it was going to do something different next.

As for which row of the d.2 table my boiler is using (a 438 installed in March 2011), it seems to be as shown in the table - at least when there is a requested flow temperature. See e.g. the second peak in each of the saw tooths, at about 17:30 and 18:12. The target flow temperature is 43C. If we're supposed to round down to the nearest multiple of 5, we should be using the 40C row. My d.2 is the default max of 20min, so the table gives a blocking time of 13min, which is what we see on the graph.

However, I do not understand what is happening on the first peak of each of the saw tooths (i.e. at about 17:16 and 17:58). This is at the end of a period of firing, when the requested flow temperature drops to zero (although there's no need for it to do so, which is why this is short firing rather than normal cycling). In both cases d.67 goes to 19min. This may be entirely unrelated to d.2. It was at a time when my Pump Delay Time on the VRC430f was set to the default of 15min - if had been set to OFF, I'm sure I would have seen a continuous burn here, without any short firing. But why did d.67 go to 19min? Is it related to the 15min setting of Pump Delay Time? I don't know.

What is happening in the micro firing region? The boiler very rapidly tries refiring, despite the d.67 countdown having barely begun. This is presumably because (once the tiny spurt of heat from the few seconds of firing has dissipated) the flow temperature is back at 27C, which must be low enough for the boiler to think it can have another go. But when it does, it immediately exceeds the target flow temperature and cuts off. I'm therefore still not convinced that increasing d.2 will help at all with micro firing, but I shall certainly try when the weather warms up again and micro firing reappears.

Frustratingly my vrDialog data does not appear to include the parameter that corresponds to d.41 (i.e. return temperature), which would enable me to see what the difference is between d.40 and d.41, despite the boiler being capable of displaying d.41 on its screen. The only candidate appears to be ReturnTemperature_DK.Temperature, but it always returns a reading of -1.8 (indicating it is non-functional, which is presumably what is meant by the next parameter, ReturnTemperature_DK.SensorState, returning a value of "cutoff" - contrast e.g. BMU_FlowTempOrVF_1.SensorState, which returns a value of "Ok").

Anti-cycling mode and the d.2 parameter

Sometimes the boiler enters an anti-cycling mode, which is intended to prevent it from trying to re-start inappropriately quickly. Here I gratefully reproduce UpgradeME's explanation of the d.2 boiler code, which determines how long it waits before re-starting:

"This may also be of some use, which explains how the 'anti-cycle' operates. 

Vaillant d.2 code - Example of operation  

Let's assume d.2 is set at 60, the modulating controller is currently requesting a flow temperature of 40C and the burner has already fired. The boiler upon entering anti-cycle mode starts a timer, counting up from zero, with an initial 'goal' of waiting 38.5 minutes, from the following table:

[Caution - MikeH has recorded in the comments below that for his 415, installed in about 2008, the values he gets are as in the table, except in the row above the one indicated. In other words, for a target flow temperature of 70C, his boiler is using the values that the table gives in the 65C row. A 418 boiler fitted in about late 2010 uses the figures given by table without adjustment.]

If after waiting 20 mins, the room temperature drops, the controller then changes its flow temperature request from 40C to say 60C. The anti-cycle time for 60C is 17 mins, but as the timer has already reached 20 mins, there is no anti-cycle time remaining (it's actually now -3mins) so the boiler then fires the burner again.

[anti-cycle time from table] - [timer] = [time remaining before boiler is allowed to re-start]

Initially that would have been be 38.5-0 = 38.5 min then changed to 17-20=-3mins 

The above example is assuming a modulating controller set in 'analog' mode where the flow temperature demand is dynamic. If set to 'two-point' mode (or using a.n.other room stat), the flow temperature is static and set via the dial on the front of the boiler. As an example for a static flow temperature demand, if the boiler was set at 65C, after it enters anti-cycle mode the boiler will wait 11.5 minutes before firing again with d.2 set at 60, or 4.5mins with d.2 set at its default of 20. Pump is off and zone valve(s) are closed during anti-cycling period."

I've edited this description slightly from UpgradeME's text to make it clearer (and in particular have altered the equation, which seemed to have the two parameters the wrong way round). Let me know if I've got the wrong end of the stick here.

I suspect that the way the timer is described as working (counting up) is not strictly accurate, since parameter d.67 is "remaining burner anti cycling time" (i.e. a count down). I had already noticed what appeared to be a countdown as one of the vrDialog-recorded bits of data on my system, but had not worked out exactly where it came from or what it was doing. I shall post some graphs of how d.67 looks when I have time.

The way the ecoTEC manual describes this process is:

"The burner is electronically locked for a specific time after each time it is switched off ("re-start interlock") to avoid frequent switching on and off of the burner (energy losses).
The burner anti-cycle time is only activated for the heating operation. Hot water operation during a burner anti-cycle time does not affect the timer.
The individual anti-cycle time can be matched to the hydraulic and thermal properties of the heating installation. In the factory the burner anti-cycle time is set to a value of 20 minutes. It can be varied under diagnosis point "d.02" within the range 2 minutes to 60 minutes. The individual effective anti-cycle time is calculated from the momentary target feed temperature and the set maximum burner anti-cycle time.
The timer can be reset or cancelled by actuating the appliance main switch. The remaining burner anti-cycle time left after switching off by the controller in heating operation can be called up under diagnosis point "d.67". The individually effective burner anti-cycle times with respect to the feed temperature and the maximum set burner anti-cycle time can be taken from Table 7.2"

It does sound from this as though d.2 could be relevant to micro firing, since "avoid[ing] frequent switching on and off of the burner" is exactly what we aim to do. However, I cannot presently see that the d.2 setting can be the (sole) cause of micro firing in my system, for instance. I have not changed it from the factory setting of 20 min. I routinely see micro firing at a target flow temperature of 40C, which the table indicates as corresponding to an anti cycling time of 13 min. But the boiler often tries to re-start immediately (within seconds), rather than waiting anything like 13 min. The sorts of timescales indicated by the table look more like what is controlling the interval between periods of short firing.

Can anyone explain to me when the boiler does enter anti cycling mode? That is status code S.8. Sometimes when the boiler switches off, it goes to S.7 (pump over run, which presumably means that it keeps pumping for a period determined by parameter d.1)  but not to S.8. But sometimes it goes to S.8. For instance, see the status code graph during a few minutes of micro firing that is on the page called "The problem" - there it never enters S.8, so can d.2 be relevant at all during this period? Perhaps it ought to be going to S.8, since it would then wait a respectable length of time before re-firing instead of doing so straight away.