Merged LiFeYPO4 1000Ah Winston prismatic cells and all electric galley...

[beckett]

Originally Posted by CatNewBee

Because they are not needed for the circut, you see the state of the bms already and you can see the state on the solenoids on the push button. No need for another 10mA per solenoid.

I guess I was mistaken ... how does the BMS know that the switching of was successful and latching relay is open or closed? I guess BMS does not care and only the driver cares, right? Thank you!

[CatNewBee]

Originally Posted by beckett

I guess I was mistaken ... how does the BMS know that the switching of was successful and latching relay is open or closed? I guess BMS does not care and only the driver cares, right? Thank you!

Yes, BMS just outputs signals and receives input from the cells, temp sensors and shunt. But this is sufficient information to make the right decisions.

How would the BMS even know there is a latching relay in place, or in my case 2 latching relays on the discharge channel and one on the charging channel, relays on the digital outputs etc. And why would it matter to the BMS?

There are fuses, manual switches and other gear too, you cannot monitor every single connection by the BMS.

The BMS raises signals on programmed parameters, it is up to the system designer to use them wisely.

[s/v Jedi]

Feedback on actual state of solenoid is mandatory imo, even if just a LED or visual movement of solenoid in case switched by hand. For automatic switching, the logic that decides to switch needs to verify success.

A BMS can get this feedback by reading that indicator line on an input; repeat attempts to switch and raise the alarm when failing to do so. Of course this requires software programming.

Looking at a control signal instead of actual state is a mistake but it’s made often and one of the reasons automated systems like BMS can (and do) fail. It’s when things don’t go as expected and this often doubles programming effort so often skipped to save money.

[CatNewBee]

Originally Posted by s/v Jedi

Feedback on actual state of solenoid is mandatory imo, even if just a LED or visual movement of solenoid in case switched by hand. For automatic switching, the logic that decides to switch needs to verify success.

A BMS can get this feedback by reading that indicator line on an input; repeat attempts to switch and raise the alarm when failing to do so. Of course this requires software programming.

Looking at a control signal instead of actual state is a mistake but it’s made often and one of the reasons automated systems like BMS can (and do) fail. It’s when things don’t go as expected and this often doubles programming effort so often skipped to save money.

As a BMS builder you have usually no idea how it would be used, it is a smart switch, galvanically isolated. If you design a whole custom system, you can probe the busses, and do something about it or not. Even IF you could check if the relay has switched by checking the voltage on the output it could be meaningless, there may be a second battery with bms on the system in parallel.

If I switch manually the solenoid, I mean it and I don't want the BMS to freak out and question my decision. Other wise I would assume it a mutiny and would prosecute the BMS instantly.

Really, it sounds great to control everything, but then you have implementation restrictions. A generic system has defined I/O specifications, the downstream gear is not in the spec or in the firmware.

Even if you add a supervisor watchdog on topp you may introduce more complexity and trouble with false positive signals and the like.

There will alwys be a risk not mitigated, just find out if it is acceptable and how probable.

BTW, the BMS only monitors the cells health, it is not in any way responsible for the down stream state. If the battery is critical, the BMS will switch AND raise alarms, Audible at least. No matter if the relays works or not, the alarm will be there if a cell is critical, and no alarm if the cells are OK. It is absolutely OK to disconnect the battery loads or charge bus manually and it is no reason for the BMS to complain or engage.

[s/v Jedi]

Originally Posted by CatNewBee

As a BMS builder you have usually no idea how it would be used, it is a smart switch, galvanically isolated. If you design a whole custom system, you can probe the busses, and do something about it or not. Even IF you could check if the relay has switched by checking the voltage on the output it could be meaningless, there may be a second battery with bms on the system in parallel.

If I switch manually the solenoid, I mean it and I don't want the BMS to freak out and question my decision. Other wise I would assume it a mutiny and would prosecute the BMS instantly.

Really, it sounds great to control everything, but then you have implementation restrictions. A generic system has defined I/O specifications, the downstream gear is not in the spec or in the firmware.

Even if you add a supervisor watchdog on topp you may introduce more complexity and trouble with false positive signals and the like.

There will alwys be a risk not mitigated, just find out if it is acceptable and how probable.

BTW, the BMS only monitors the cells health, it is not in any way responsible for the down stream state. If the battery is critical, the BMS will switch AND raise alarms, Audible at least. No matter if the relays works or not, the alarm will be there if a cell is critical, and no alarm if the cells are OK. It is absolutely OK to disconnect the battery loads or charge bus manually and it is no reason for the BMS to complain or engage.

I understand you don’t like this but you know I’m not easy on peoples feelings and just comment from the engineering side. Your setup is like throwing a line to a bollard and turning around before you can see if it went around it or if it missed. That is not how proper engineering works.

The LED you have shows what the BMS wants, not the actual state. You don’t get the actual state from reading the bus voltage because, like you say, there maybe another battery on-line. You check actual state by reading the solenoid status signal; it is exactly the function of that wire.

The most important function of the BMS is to take the battery offline when it is being overcharged or going too far down on SOC or when temperature is out of allowable range. So I think this is it’s primary function.

Also, this is not automating more... that decision was made by going for a BMS which tracks battery/cell status and automatically takes it offline when needed.

Many systems use MOSFET’s in which case it is foolproof. Other systems use a regular solenoid which is also... almost foolproof. Such systems only need periodic manual tests to verify operation. The Blue Sea Systems solenoids are of a latching type, meaning it is controlled by a pulse and locks into the On state without any control input, until another control pulse is sent to release it into the Off state. In your diagram, these pulses are created by sending a steady on or off signal to electrolytic capacitors. This is a cool way to do it, but not foolproof. Also, these capacitors are prone to failure and drying out when aging, especially when cheap brands are used.

The BMS was not designed to control latching solenoids and the capacitors are added to make it work.

From an engineering standpoint, these latching solenoids need to be supported in software, with the control output and the feedback input. For example, to switch the solenoid to On, the software would do:

Set control output High
While feedback is Low
  Do nothing
Set control output Low

This is exactly how these are controlled manually: you press the switch and when the LED comes on, you release the switch

I recommend you report this to the BMS developers and they may be bothered to implement support for these latching solenoids in a future firmware update

[beckett]

Originally Posted by CatNewBee

Yes, BMS just outputs signals and receives input from the cells, temp sensors and shunt. But this is sufficient information to make the right decisions.

How would the BMS even know there is a latching relay in place, or in my case 2 latching relays on the discharge channel and one on the charging channel, relays on the digital outputs etc. And why would it matter to the BMS?

There are fuses, manual switches and other gear too, you cannot monitor every single connection by the BMS.

The BMS raises signals on programmed parameters, it is up to the system designer to use them wisely.

It reminds me of the early days of designing distributed systems architectures... do you remebeber "Two-phase commit protocol"? )))
I am very new to all of this but I would like to make sure my last line of defence, which are my latching relays would work for sure even if my BMS is gone crazy or not available anymore.
Why not have a simple logic built into the latching relays drivers to monitor the messaging from BMS to the relays, make sure that the relays have behaved accordingly and also, may be monitor the battery voltages. A single Arduino board could monitor messaging to 4 relays and also monitor their state independently of the BMS. It could also have a pretty accurate voltage measurements and make its own decision to shutdown the system if something happened to BMS. Am I over thinking this? Is anything like this already exists?

[beckett]

Originally Posted by s/v Jedi

I understand you don’t like this but you know I’m not easy on peoples feelings and just comment from the engineering side. Your setup is like throwing a line to a bollard and turning around before you can see if it went around it or if it missed. That is not how proper engineering works.

The LED you have shows what the BMS wants, not the actual state. You don’t get the actual state from reading the bus voltage because, like you say, there maybe another battery on-line. You check actual state by reading the solenoid status signal; it is exactly the function of that wire.

The most important function of the BMS is to take the battery offline when it is being overcharged or going too far down on SOC or when temperature is out of allowable range. So I think this is it’s primary function.

Also, this is not automating more... that decision was made by going for a BMS which tracks battery/cell status and automatically takes it offline when needed.

Many systems use MOSFET’s in which case it is foolproof. Other systems use a regular solenoid which is also... almost foolproof. Such systems only need periodic manual tests to verify operation. The Blue Sea Systems solenoids are of a latching type, meaning it is controlled by a pulse and locks into the On state without any control input, until another control pulse is sent to release it into the Off state. In your diagram, these pulses are created by sending a steady on or off signal to electrolytic capacitors. This is a cool way to do it, but not foolproof. Also, these capacitors are prone to failure and drying out when aging, especially when cheap brands are used.

The BMS was not designed to control latching solenoids and the capacitors are added to make it work.

From an engineering standpoint, these latching solenoids need to be supported in software, with the control output and the feedback input. For example, to switch the solenoid to On, the software would do:

Set control output High
While feedback is Low
  Do nothing
Set control output Low

This is exactly how these are controlled manually: you press the switch and when the LED comes on, you release the switch

I recommend you report this to the BMS developers and they may be bothered to implement support for these latching solenoids in a future firmware update

I am sorry s/v Jedi and CatNewBee but I just posted something before reading your latest 2 posts. I do not have an EE degree so my point of view might be very naive to regards of design a bulletproof BMS system... however, the software world has faced these questions for a very long time and solved it differently every few years. We moved from a highly centralized model with highly strict protocols and messaging systems, with messaging watchdogs and watchdogs of watchdogs to the highly decentralized system where anyone can make their own decisions but still listen to the outsiders.
OK, now I am going go back and read what you had to say about this. )))

[newhaul]

Originally Posted by s/v Jedi

I understand you don’t like this but you know I’m not easy on peoples feelings and just comment from the engineering side. Your setup is like throwing a line to a bollard and turning around before you can see if it went around it or if it missed. That is not how proper engineering works.

The LED you have shows what the BMS wants, not the actual state. You don’t get the actual state from reading the bus voltage because, like you say, there maybe another battery on-line. You check actual state by reading the solenoid status signal; it is exactly the function of that wire.

The most important function of the BMS is to take the battery offline when it is being overcharged or going too far down on SOC or when temperature is out of allowable range. So I think this is it’s primary function.

Also, this is not automating more... that decision was made by going for a BMS which tracks battery/cell status and automatically takes it offline when needed.

Many systems use MOSFET’s in which case it is foolproof. Other systems use a regular solenoid which is also... almost foolproof. Such systems only need periodic manual tests to verify operation. The Blue Sea Systems solenoids are of a latching type, meaning it is controlled by a pulse and locks into the On state without any control input, until another control pulse is sent to release it into the Off state. In your diagram, these pulses are created by sending a steady on or off signal to electrolytic capacitors. This is a cool way to do it, but not foolproof. Also, these capacitors are prone to failure and drying out when aging, especially when cheap brands are used.

The BMS was not designed to control latching solenoids and the capacitors are added to make it work.

From an engineering standpoint, these latching solenoids need to be supported in software, with the control output and the feedback input. For example, to switch the solenoid to On, the software would do:

Set control output High
While feedback is Low
  Do nothing
Set control output Low

This is exactly how these are controlled manually: you press the switch and when the LED comes on, you release the switch

I recommend you report this to the BMS developers and they may be bothered to implement support for these latching solenoids in a future firmware update

could you post the specifications and design drawings as well as schematics of the system you currently have installed ? A few pictures of how you actually installed the system and did your cable runs ? I am in the late stages of design and acquisition . Now its time for me to install all of it . A small 250ah bank, a 200 amp in and out bms with passive balance. As well as my generic battery monitor with 350 amp shunt.

[s/v Jedi]

Originally Posted by beckett

I am sorry s/v Jedi and CatNewBee but I just posted something before reading your latest 2 posts. I do not have an EE degree so my point of view might be very naive to regards of design a bulletproof BMS system... however, the software world has faced these questions for a very long time and solved it differently every few years. We moved from a highly centralized model with highly strict protocols and messaging systems, with messaging watchdogs and watchdogs of watchdogs to the highly decentralized system where anyone can make their own decisions but still listen to the outsiders.
OK, now I am going go back and read what you had to say about this. )))

No worries, I saw that we were both posting

What you propose is basically what CNB has in the diagram: adapt what the BMS can do to what the latching solenoid needs, except you would do it with a microcontroller using a proper method with feedback. That would be just fine but I have a feeling that the BMS in question will have some available digital input pins and memory for a couple lines of code.

I come with all this because I’m writing code for my own BMS so just did this with the same latching solenoids

[CatNewBee]

The BMS has no other inputs then the described. It is a Black Box, 4 cell sensors, one current sensor and 2 temp sensors. It has internal logic to check the inputs and the smart fuses on them,

the outputs are completely galvanically isolated, what means no way the BMS sees anything going on there.

The relays are 3 contact bistable relays (COM, NO/NC) and the digital outputs are darlington optocoupler, so same here, the BMS sees only the "LED" s current, but not what the phototransistor is doing on the other side.

It is what it is. A great system, easy to integrate. You can do what you want to on the other side.

No commercially available BMS system has any digital inputs to verify relay states. Relays can have welded contacts not opening or burned contacts not closing or a coil failure, by no way would a feedback contact be of any help there to fix a relay.

On the other hand FET transistors can be shortcutted or open when damaged by a voltage spike, too high current or polarity issues (turning off high inductive loads, lightning strike...) no way the logic before would recognize this.

Adding a watchdog computer adds in the first place another always on load, that drains the battery. It adds another complex circuit that needs a watchdog and also the probability to mess up. A failed relay with contact issues will not be fixed by this anyway, even ten watchdogs wont make a new contact. There are coomercially produced latching relay drivers available at REC, but even they do not have feedback inputs. They switch on low, so you need 2 more failure prone relays to invert the signal, way more error sources than using just capacitors. You can use a pair of capacitors in parallel if you think a draining capacitor may become an issue.

Make your own fool-proof system from self selected and tested components and adapt it to your environment. But usually any complexity layer adds to the possible failures list.

[beckett]

Originally Posted by CatNewBee

The BMS has no other inputs then the described. It is a Black Box, 4 cell sensors, one current sensor and 2 temp sensors. It has internal logic to check the inputs and the smart fuses on them,

the outputs are completely galvanically isolated, what means no way the BMS sees anything going on there.

The relays are 3 contact bistable relays (COM, NO/NC) and the digital outputs are darlington optocoupler, so same here, the BMS sees only the "LED" s current, but not what the phototransistor is doing on the other side.

It is what it is. A great system, easy to integrate. You can do what you want to on the other side.

No commercially available BMS system has any digital inputs to verify relay states. Relays can have welded contacts not opening or burned contacts not closing or a coil failure, by no way would a feedback contact be of any help there to fix a relay.

On the other hand FET transistors can be shortcutted or open when damaged by a voltage spike, too high current or polarity issues (turning off high inductive loads, lightning strike...) no way the logic before would recognize this.

Adding a watchdog computer adds in the first place another always on load, that drains the battery. It adds another complex circuit that needs a watchdog and also the probability to mess up. A failed relay with contact issues will not be fixed by this anyway, even ten watchdogs wont make a new contact. There are coomercially produced latching relay drivers available at REC, but even they do not have feedback inputs. They switch on low, so you need 2 more failure prone relays to invert the signal, way more error sources than using just capacitors. You can use a pair of capacitors in parallel if you think a draining capacitor may become an issue.

Make your own fool-proof system from self selected and tested components and adapt it to your environment. But usually any complexity layer adds to the possible failures list.

Thank you, CatNewBee. I learn something new from every post you do.

Often we try to fix what not need any fixing but that only could be resolved by testing and data of the individual components we install. I agree that added complexity has a higher probability for failure unless the bulletproof modular system is built and each of the modules has been tested and used in many other projects/systems, etc. Let's take just two modules in your system: 1. the BMS and 2. your driver with Blue Sea latching relays. The BMS is a commercial product and actually looks like a great product. The BMS has been working every day for the past two years so it is clearly working well balancing your cells, managing chargers, and discharging. However, I wonder how many LVC/HVC events have you had in 2 years? I think if we would have some QA data on how your latching relay driver and Blue Sea relays performed over 100,000 simulated LVC/HVC events we could at least estimate the probability of failure and if any additional complexity could be justified. I am NOT asking you to test and I would be happy to do some testing when I start getting my components ))) Cheers!

[CatNewBee]

I have done 3 reboots in the last 3 years when I found an error or minor issues with the BMS, contacted Tine and received the firmware updates. The BMS always turned the solenoids off and on properly. Also I did test the new firmware if it switches upon the settings as expected. Of course I did not push the battety over the shoulders, I rather reduced the switching setting and checked the function, so add 3 more switches per solenoid. You can test the function by turning off the BMS by it's remote switch at any time, then all solenoids will turn off. When you power it up again, the BMS will perform the self test and turn on the solenoids. This switching goes only via the interface and is a good test.

I also have bench tested my interface along with the ML RBS solenoids with different voltages using a lab power supply before putting everything on the boat. I am pretty convinced, my interface will live as long as the other components.

I'm not saying, it is for everyone, if someone is uncomfortable with DIY and electronics, there are other options, including an professional install of an integrated complete Victron or Mastervolt system among others, it may cost 3 times more for the same capacity as turn key solution, but you have a one year warranty, and you dont need to figure out how to do it.

Recently I met some fellow cruisers on a big Privilege cat, all Victron LFP, 2 x 5000VA Quattro inverters in parallel operations. They had several trouble with the installation and after a lot of try and error repairs from the pros, they had replaced finally both Quattros, because of erratic errors, FW updates did not help, and the Victron certified installer gave finally up, they missed a lot of sailing that season, because of warranty claims and staying around in marinas and making schedules for repairs and fixing.

At the moment their system is working and they are finally happy...

[s/v Jedi]

Originally Posted by newhaul

could you post the specifications and design drawings as well as schematics of the system you currently have installed ? A few pictures of how you actually installed the system and did your cable runs ? I am in the late stages of design and acquisition . Now its time for me to install all of it . A small 250ah bank, a 200 amp in and out bms with passive balance. As well as my generic battery monitor with 350 amp shunt.

I have a thread here on the forum that includes software source. The project has been put on hold though because when Covid shutdowns hit we took the opportunity to do some rather big projects that included tearing half the galley apart.

When I’m on the project again, I will start updating it. I believeyou will find the thread by searching for yaBMS

[s/v Jedi]

I had a look at the product pages of the BMS and indeed it appears they did not put any addition I/O pins on the external connector.

In that case the microcontroller adaptor as proposed by Beckett seems the best solution. You scan for the BMS’s commands to control a relay and convert that to a proper control of the latching solenoid with feedback control to make sure all is well.

This is a big step for those not familiar with microcontrollers and programming them. In that case I recommend to look at the schematic from CNB and make sure those capacitors are from 1st tier manufacturers. Panasonic would be my choice but there is a list: https://www.tomshardware.com/reviews...01,4193-5.html
The importance is that the value of the capacitor defines the pulse send to the latching relay and this does not tolerate wild varying capacitance (these are not so precise to start with), drying out, leaking etc. which will actually lead to a failure to switch the solenoid, not just some hum from a speaker like when used in a power supply.
Pretty easy to make sure quality components are put in.

Beckett: you will have fun playing with these solenoids. I could make them jump from the table

[CatNewBee]

47μF will work, 100μF is safe, 1000μF, 2200μF will work too, it takes just longer to discharge. Impulse length is not critical, only minimal length is important. Use 25V rated capacitors, not the 16V rated for safety, 16V would work without issues, but 25V gives you peace of mind.

If you are crazy about capacitor failures (very unlikely at this application), take two 100μF in parallel, if one fails, the other will work, if capacity gets lost, no problem, you double the capacity by using in parallel and you have already 2 times more than necessary, so 4 times safety. But it is really not necessary, the capacitors don't get warm, they are once charged or discharged and remain in that state for centuries, because your system never switches when set up properly.