@plonkster i also asked that guy in the Victron community that had fixed it using ESS & he replied with 

thread there - https://community.victronenergy.com/comments/50458/view.html

 

I went & loaded dummy in VE config & gone thru loading ESS & it ended up looking to set up this way

 

 

That look normal ? Then after that is loaded i must go find where is the setting for "keep Batteries charged" maybe in the ess settings part of the terminal rather?

In the setup of ESS it wanted Ah so i entered 150 for 3 x 3000b's & i think that is how its led to wanting to raise the absorption + float voltages as currently they are set at 52.0V + 51.0V

For the other settings i followed what is listed under ESS settings here

https://www.victronenergy.com/live/battery_compatibility:pylontech_phantom

 

Am i looking ok to proceed with that out of dummy mode?

Dvcc is already setup

Edited May 25, 20206 yr by 2una

8 minutes ago, 2una said:

That look normal ? Then after that is loaded i must go find where is the setting for "keep Batteries charged" maybe in the ess settings part of the terminal rather?

First, I would modify the default settings in the ESS assistant config for the 15s config. The default voltages are for 16s and are too high. These voltages are actually not used, it's overriden elsewhere, but it is good to set the correctly in case you ever restart the Multi with the BMS unplugged.

Secondly, the moment you add the ESS assistant (and I assume you have DVCC enabled), the GX will notice this and start using the charge voltage sent by the BMS (53.2V)... but because we already know that voltage is a tad too high the GX also caps this at 52V (in a future version it will be using 52.4V).

So basically you have no control over the voltage that is used. That is decided by other factors.

However... the reason why adding the ESS assistant fixes it is because now it runs grid-parallel. Whenever a load starts on the output, there is a short period of time where power is drawn from the battery (a couple hundred joules at most) before the control loop stops it and puts it back. This means your loads now cause just enough movement on the battery to avoid it going completely idle. So the voltages actually have nothing to do with it, you're just allowing the loads to slightly perturb the battery state 🙂

 

56 minutes ago, plonkster said:

First, I would modify the default settings in the ESS assistant config for the 15s config. The default voltages are for 16s and are too high. These voltages are actually not used, it's overriden elsewhere, but it is good to set the correctly in case you ever restart the Multi with the BMS unplugged.

I just go back to the charger tab & put the absorption/float back to 52.0/51.0 before loading the ESS assistant to correct that right?

 

56 minutes ago, plonkster said:

Secondly, the moment you add the ESS assistant (and I assume you have DVCC enabled), the GX will notice this and start using the charge voltage sent by the BMS (53.2V)... but because we already know that voltage is a tad too high the GX also caps this at 52V (in a future version it will be using 52.4V).

So basically you have no control over the voltage that is used. That is decided by other factors.

Understood - Yes DVCC is already loaded i'm just looking to add this ESS to get rid of that alarming nothing else.

 

56 minutes ago, plonkster said:

However... the reason why adding the ESS assistant fixes it is because now it runs grid-parallel. Whenever a load starts on the output, there is a short period of time where power is drawn from the battery (a couple hundred joules at most) before the control loop stops it and puts it back. This means your loads now cause just enough movement on the battery to avoid it going completely idle. So the voltages actually have nothing to do with it, you're just allowing the loads to slightly perturb the battery state

 

Ok thank you very much sir

& the setting for "keep battery charged" will that be found over in the remote console once i load the ESS via the ve config?

Edited May 25, 20206 yr by 2una

1 hour ago, 2una said:

I just go back to the charger tab & put the absorption/float back to 52.0/51.0 before loading the ESS assistant to correct that right?

Correct.

1 hour ago, 2una said:

& the setting for "keep battery charged" will that be found over in the remote console once i load the ESS via the ve config?

Correct. On the ESS menu.

Done - thanks a ton for your help! - If you eat fish pm me your cell no & after this virus nonsense is done i'll try get some to you.(i have in my head your CTown?)

On 2020/05/12 at 10:26 AM, wolfandy said:

Am using 52.2V and 51.8V - and my system is running without any problems. But I am also cycling my Pylons every night

Only slight oddity that I see every now and then is that the Pylon BMS reports 101% SOC 

 

Hi I'm also seeing 101% SOC every now and again when I give the batteries a full charge.

This is because they have started to lose a little bit of their capacity in the last year and a half and goes above that reduced capacity after a full charge for a short period.

In my case the capacity is 98.8 Ah and after a full charge I will see 100Ah for a while and 101SOC.

This move to using ESS has fixed the error appearing for me,no more errors since doing it

@plonkster

Has the Blue Wizard had any previous dealings with this error at all?

Has only happened twice but now looks like i need to follow up on it.

It only ever came after switching to using ESS which also entailed i switch grid code from none to SA

Multiplus II 48/5000    Firmware 2626 469    UPS only   Venus is on v2.57

 

 

I did find this to read already

https://www.victronenergy.com/live/ve.bus:ve.bus_error_codes#:~:text=Error 11 indicates a failed,failure (eg inoperable relays).

 

both instances a month apart but it takes the power down when it happens till it sorts itself out

 

 

Edited August 10, 20205 yr by 2una

On the GX device it will tell you what part of the test failed.  From the Device List, select the Multi, then Alarm Status, then VE.Bus Error 8/11 report. It will show you which part of the relay test failed.

Usually it is the bonding relay test that fails. It tests that there is a TN bond on the input side (which there usually is), then it tests that there is NOT a TN bond on the output side (which is usually where the problem is), and finally it tests that closing the bonding relay actually establishes a bond (also not usually a problem).

Depending on what step fails, it usually indicates some sort of issue with the installation. Basically, the same sorts of things that causes RCDs to trip or not trip...