Who's On First

What SHOULD happen is that the inverter/charger should be able to charge a dead battery by booting its charger section up from AC/GRID when it is connected.

This is what we used to do with certain 12V inverter/chargers that we made.

boB

The inverter/charger on-hand will do that, but there has to some voltage sensed before it'll attempt it.(xantrex)This may be an attempt no not overvolt connected system electronics with a constant current overvoltage surge, when a battery is missing. Haven't actually tried this BMS on other inverter/chargers. Previous work (samlex etc), had the BMS controlling a physical relay, typically placed in the +rail.Decision to close the switch could always be overiden, though this need rarely occurs, from testing here or feedback received, to date.

Due to physical characteristics of the semiconductors used, the electronic switch has been placed in the negative line, and there's no obvious way to bypass it's electronic control. Aim is to replace the relatively low cost relays, above 100A service.

It may be possible to get things started here by making the switch leaky, with a parallel resistor. There's a timing issue where the charger trickles current into the apparently low-voltage node.

Would be easier if the BMS would just turn on by itself, into a simple load. I'd call that a basic function.

RL

Maybe... Or might just be they didn't think batteries would go so dead that they would be zero volts. The charger should at least try to charge and if the voltage does not rise at all, maybe it's voltage sense is kaput. If it measures some current draw, then maybe it can decide thee voltage sense IS bad and stop there with an error. If the voltage rises and no current is measured, that is probably OK for a while since a real dead lead acid battery may not actually draw current until it starts to reform or whatever it takes to start actually putting a charge into it. Not sure which Xantrex charger/inverter this is though... One of the Chinese ones or.... I worked for Xantrex when they took over the company I had worked for for 6 years and they were somewhat weird but OK.

Switches in the negative line can work OK. Positive line drive can cost more of course but it all depends on the system needs. Common negatives and things like that. Not sure about this particular unit. Samlex is an OK company. They're headquartered in British Columbia I think.

Sometimes they don't know the market or how it should work but these 2 companies are fairly decent. Don't know who owns who anymore though so bean counters may stifle proper design of newer products.

boB

<snip>

No beef with the chargers. If they're programmed for the right chemistry, they're pretty predictable.

If I could get com going with the Daly BMS, I might be happier, but their USB coms driver isn't happy in Windows and vice versa. The Daly BMS Monitor software is also buggy - can't get com ports lined up, even after drivers are present for their CH340 interface.

North America is really too small a market for them to bother, I suppose.

Bluetooth relies on a smart phone app and won't access limit programming, which is probably a safety/security feature.

RL

On Fri, 19 Nov 2021 13:41:44 -0500, legg snipped-for-privacy@nospam.magma.ca> wrote: <snip>

Managed to get a com line working in an XP lab machine - worked for about 14 minutes around 4pm, long enough to read, write and readback the parameters, before the Daly program froze the machine - had to task-manager it off.

Not a peep out of it since. A 'long button-push' is supposed to turn it off and on, according to the GUI panel settings. You think that worked?

In the DIY solar forums, there was a reference to 'rebooting' the BMS. yeah . . yeah . . . .

RL

RL

???

Most BMS's I am aware of are using RS485 and MODBUS I think...

Then again, CANBUS may be the next poplular format.

But USB can work too. Not sure which one of the 3 would be more reliable with groind bounce or common mode noise they would be susceptible to.

boB

<snip>

That's the right forum. No end of complaints, though most tend to be from first installers trying to get com running and settings in a non-self-destruct state. Much confusion due to model and I/O hardware variations.

The Daly products come with USB and/or BlueTooth dongles. There are two different software packages for higher and lower voltages systems (cutoff being 5S or about 18V). I/O hardware has been / is changing at an alarming rate.

As this BMS cuts off the negative battery terminal, and there might be other com/measurement leak paths on that line, in this test set-up (other $$ isolated tools doing datalogging on the battery terminals, reference shunt and inverter/charger). I've been using a USB isolator on the Daly com line, in this work.

The isolator has never been responsible for a com issue elsewhere and was present during the brief time that the BMS was talking normally.

Comms with Daly (the company) are not good, so far, through local distribution.

If I had some kind of state-machine diagram, it might be useful. Some users report methods of waking the thing up that don't actually rely on a high current terminal disconnect, which might also be useful. I hope that the 'reboot' reference was just a case of loose lips.

RL

After obtaining a ~functional comm line between the installed BMS and a bench WXP PC, there are a number of issues that affect the reliability of this comm link. None are obvious.

from:

After a number of trials at quiescent ( 0 and 2A charging), charging (80-90A)and discharging (100-120A) states, a pattern of Daly BMS to PC comms beginsto form.

These are illustrated in two charts.

Both show the time-stamped 'BMS Life' reporting intervals listed in the logs of the trial periods, before reporting comm either ceased entirely and/or the DalyBMSMonitor program crashed.

The reporting interval generally increases with time. In the 211125 plot, this interval actually went off the scale of the graph (>200 BMS Life cycles), reaching the 500-600 count.

As previously stated, the DalyBMSMonitor program uses a lot of this PC's microprocessor's capacity (P4 2800/MHz). It starts at 20% and rises pretty quickly (<1hr) to ~80%. If other programs running simultaneously are terminated, it can rise further.

Another interesting point to note:

The log files carry a date-stamp that identifies the last recording time or log entry.

Of the five logs present at the end of testing, 2 crashed within minutes of 3PM and 3 crashed within minutes of 9PM. This may reflect or amplify the relevance of reports of BMS units repeatedly ceasing to function normally at a specific time of day.

This system install is located at GMT-5. and no equipment in the test bed has an internet connection, or wireless comm. Clock times reported are those of the PC.

Reports of other users experiencing anomalies at certain times of day are present on at least one other thread (8S, PV and bluetooth comms).

[Beside the point; the logs developed by the DalyBMS-v1.1.6, in .xlsx format, have the SOC and current column headers swapped over. I don't know if this reflects possible problems in actual comm/BMS processing/activity.]

I'll be trying to run the software and comms from a different machine with more recent OS and hardware (W7 Pentium P6200), to see if this stink follows.

RL