[cruisin]

Hello all,

About 3 years ago (ish. It's been a while) my father and I began converting a '95 Probe GT to electric. It went through some necessary changes (read: newer controller when we blew up the first one) and we've now had it to the point where it drives for most of the summer. It's got an auto, annoyingly, but having found all the threads on here detailing ways to keep pressure, that shouldn't be an issue (though I myself would have preferred a manual). Recently, I began finishing all the little bits, making power cables, doing the little bits of wiring, etc.

Most of the info is in the garage: http://www.diyelectriccar.com/garage/cars/341

Anyway, we're running 48 groups of 3 cells each, HiPower LiFePo4s, with an Electromotus EMUS BMS and a TC Charger 3kW (previously these were apparently called "Elcon" and before that, "Chinoz"). The BMS is designed to take complete control of the charger via CAN, but this is where the problem happens:

The two units WILL. NOT. COMMUNICATE.

According to every wiring diagram I've found (including both the charger AND the BMS') and others that have similar setups, the CAN L and CAN H of each device simply need to be tied together to the respective pins (which is hard enough, since the charger's CAN module has NO markings as to which is which) with 1 (or 2) 120Ω resistors to kill echoes. Still both the charger and BMS say there's no comm. I have measured the voltages at the BMS with the charger on and off, and they do rise/drop, each by half a volt.

The only thing I could come up with was that the charger and BMS need to share a common ground. Grounding the charger's AC side to the frame did nothing. There is a ground pin in the 7-pin connector on the charger itself, but that connector is already attached to the CAN module TC Charger supplies, and there's no way to add a ground wire.

I do plan on getting ahold of TC/Elcon/Chinoz/whatever and asking them about this, but I was hoping someone here might have experience with CAN or this combo. This is the last thing preventing us from getting the car on the road, and we'd really like to do so before snow.

Get a hold of the distributor and repair agency for Elcon in Sacramento, CA and they will help you.

 

[Brute Force]

As chance has it, I came across this as I was reading yesterday:

"The engineers at ElCon designed a CAN engine in software and used the RS232 lines to drive a CAN buffer. The result is a CAN implementation that works, but only if there are no messages on the CAN bus other that the ones it expects. The presence of more than one CAN message per second on the CAN bus will freeze the charger's CAN engine."

Footnote 3, Page 196, Battery Management Systems by Davide Andrea

 

[MindMil]

Hi,

I am one of the designers of Emus BMS and we are investigating this issue. A suggested possible interim solution with new software version was provided to Hydrochloric in private.

We are ready to discuss this issue to resolve it.

Best Regards,
Mindaugas Milasauskas

 

[PhantomPholly]

Nothing like the internet to bring about better customer service!

 

[hydrochloric]

Well, new issue (both with the BMS and the board here). I have attempted to reply to MindMil's PM, but the system seems to not be working, as there is never a new message in my sent box. I can post my message here, if it is not actually sending.

 

[hydrochloric]

Get a hold of the distributor and repair agency for Elcon in Sacramento, CA and they will help you.

I also tried this. They were... unwilling to help. Something about they hate dealing with End-users, for this very reason. I have since tried going through our source for purchasing, but am getting no response.

 

[DaveAK]

No mention of the baud rate for either charger or BMS. Have you checked they're both set to the same baud rate?

 

[hydrochloric]

Well, I'd love to play around with it, but at the moment, the car is dead. The problem is, the modules failed and started discharging the pack across the balance resistors, and due to the way we constructed the pack, we had to partially disassemble it to disconnect the modules (and cease the discharging).

Right now, we have three separate cells that have dropped to 1.5V. Hopefully we'll be able to recover these separately.

Strangely, even after the removal of the cell modules' power, when they are re-connected, they immediately begin discharging the cells again, and the red (presumably "Error") LED comes back on.

So currently, the car is dead, and the BMS is not functioning. I have sent an email to Elektromotus (since I can't seem to get a PM to send here). Once this issue is resolved, I'll go back to trying to get the charger online.

EDIT: I am currently discussing this issue through email.

 

[DaveAK]

Not sure if it relates to your particular problem or not, but you do mention it in the OP. It's my understanding that CAN Bus does require a common ground.

 

[hydrochloric]

Not sure if it relates to your particular problem or not, but you do mention it in the OP. It's my understanding that CAN Bus does require a common ground.

I had the same understanding (though I never found anything that said it HAD to be so). However, the way the CAN connects more or less prevents grounding the charger's communication port. Basically, these chargers have a 7-pin connector, which can be wired up to a contactor and other bits. That's the basic system, wherein the BMS turns the contactor on and off.

The other way, and the way our charger is hooked up, is that 7-pin connector goes to a pre-made module that has two pins: CAN-H and CAN-L. I would link a manual, but I can't find any that have the pins and control scheme layout. So if the connector needs to be grounded, it will be VERY difficult to extract the wires (especially since the interior of the module has been covered in... epoxy, I guess). I did find some info from the eLithion BMS, where there's a wiring diagram for the charger. http://lithiumate.elithion.com/php/elcon.php Way down at the bottom of the page. Weirdly though, the only reason THEY extract the wires is to activate a relay telling the BMS the charger is working, not to ground the unit.

There is some additional info on the eLithion page, like our charger, which is older, can only handle 2 messages/second, and at a speed of 250kHz. I can't try changing the BMS CAN speed, however, because of the BMS issue.

The BMS issue was partially fixed. The newer software caused the cells to automatically start balancing. I haven't had a chance to further diagnose to see if it's a software issue, or a user error. The BMS is currently running the old software, but that doesn't allow any control over the CAN interface (and removes the hopefully very convenient feature that shunts CAN messages to the USB output).

I'm in school from 8-3 most days, and here in NY, while we are still enjoying (absurdly warm) 50-60 degree weather, the actual time that can be spent in an unheated barn is about 11-3 (though I usually get too absorbed and end up coming in at about 7, completely frozen ). Basically, I'm having a hell of a time having time to diagnose it.

I think the next step will be to try to get the charger communicating sans battery pack, then dealing with the dead cells, and charging it all finally. Hopefully I'll be able to work on it tomorrow. Otherwise I don't think I'll have a chance to work on it until the weekend.

 

[Elithion]

I did find some info from the eLithion BMS, where there's a wiring diagram for the charger. http://lithiumate.elithion.com/php/elcon.php

Well, it makes us feel good when users of other BMSs end up looking for tech support on our website .

Weirdly though, the only reason THEY extract the wires is to activate a relay telling the BMS the charger is working, not to ground the unit.

It's not to tell whether the charger is working.
It's to power the BMS whenever the EV is plugged in.

Indeed, technically CAN is a 2-wire bus, meaning that ground is not required; thought, in practice, is it is usually connected.

 

[hydrochloric]

Well, it makes us feel good when users of other BMSs end up looking for tech support on our website .

Your site is a Godsend for info on the ElCon charger. Their site doesn't even have a complete manual, and their support is... brusque, at best.

It's not to tell whether the charger is working.
It's to power the BMS whenever the EV is plugged in.

Indeed, technically CAN is a 2-wire bus, meaning that ground is not required; thought, in practice, is it is usually connected.

Ah. Not knowing the pinout, it was a guess that the wire enabled the charger, not the other way around.

That's more or less what I had discovered (and inferred). Since there's a Low and a High, the potential is the bias across them, not to ground.

I managed to fix the battery drain issue, it was in fact my own error. The max charge voltage had been set to 2V, so the modules were doing what they were supposed to- draining the cells to 2V.

It still hasn't fixed the charger issue. I've fiddled with the settings to no avail, so the next step is to get a CAN to USB hookup, see what the bus is actually seeing. Also, haven't had a chance to see if the dead cells have recovered far enough for the main charger to charge them (>2.2V).

 

[Elithion]

It still hasn't fixed the charger issue.

Again, from Elithion's site, here's a troubleshooting guide for CAN bus issues.
It is geared to people with just a voltmeter / ohmmeter.

 

[Coulomb]

If you want to debug the CAN circuitry and/or protocol yourself, you may find the following pages helpful:

Elcon charger RS232 experiments and partial CAN box circuit; using Driver Controls to send and receive CAN packets; using a CRO; 74C04 based converter (circuits here and here); how CAN IDs are constructed.

I hope I got those links right.
http://forums.aeva.asn.au/forum_posts.asp?TID=980&PID=27016#27016

 

[hydrochloric]

If you want to debug the CAN circuitry and/or protocol yourself, you may find the following pages helpful:

Elcon charger RS232 experiments and partial CAN box circuit; using Driver Controls to send and receive CAN packets; using a CRO; 74C04 based converter (circuits here and here); how CAN IDs are constructed.

I hope I got those links right.
http://forums.aeva.asn.au/forum_posts.asp?TID=980&PID=27016#27016

I had found your Miata project on AEVA before I even posted here, when I was searching around about charger information, but I never saw these pages! The amount of information is mind-boggling, and I fear my very limited hardware knowledge will present a large impediment. I only got to basic digital circuits before I switched from EE to ME...

Part of the issue is that I've been having trouble finding basic info on CAN busses, everything I've found seems to assume that I already know how to setup a network, and understand all the data. ...which I don't.

So, from what I've read, the CAN data that the BMS sends out needs to have the same ID as the charger's CAN module (in my case, 0X 18 06 E5 F4 - this is written on the case of the charger CAN module)? I have configured the BMS to use 250kbps speed, and Extended 29bit IDs. I didn't set the ID to the above number, I wasn't aware that should matter.

One of the other things I noticed you had done was viewed the charger's 7-pin output via RS232? It had been decided to get a CAN>USB adaptor, but this would make it seem that's not necessary? The BMS has an option to "Send to RS232/USB", but this doesn't appear to be working (I think it needs to have a confirmed connection before the forwarding occurs). I know you have a different BMS, so that's probably not helpful.

In a previous post, Elithion linked to a bit of troubleshooting without a scope. The bus measured at 80Ω, IIRC, with 2 120Ω resistors. The voltmeter section had this:

Voltmeter testing

Power up all the devices on the CAN bus
Measure the voltage of the 2 CAN bus lines.
The voltage should be about 2.5 V to ground, on both lines
If a line is sitting at 0 V, it is shorted to ground, or there is no connection to it
If a line is at 4 V or so, a CAN driver on the bus is broken, or various devices on the CAN bus are set for different data rates
The voltage of the CANH line should be more positive than the voltage on the CANL line (on the order of 100 mV, depending on how much data is on the bus)
If the other way around, the CAN bus lines are reversed
If no difference in the voltages, there is no CAN communication, or the 2 lines are shorted to each other

When just the BMS is powered, the voltages read at 2.6 and 2.4 (or thereabouts). When the charger is powered on, the voltages change significantly- Low ends up at about 1.7, High at about 3. This is from memory, and before I changed the BMS bus speed, so it's not totally accurate, but it still seems to point to an issue with the charger's CAN, correct?

 

[DJBecker]

CAN bus uses a differential pair. Transceiver chips can handle a significant offset (difference in local ground potential), some over 40V of offset. But an offset degrades reliability and noise immunity.

This ability is mostly useful in an industrial installation. In an automotive system there isn't any good reason to have more than an incidental offset (a volt or two) from frame ground. You certainly don't want to rely on the differential pair to establish the common ground.

Debugging CAN messages doesn't require expensive equipment, just a $20 bluetooth or USB OBD2 reader from FleaBay. Keep in mind that CAN bus is a little quirky in that it requires at least two active nodes. A sending node needs at least one active listener to send a single bit ACK at the end of the message, or it thinks the transmission didn't work. And most code readers don't act as an active listener -- they don't send the ACK bit.

 

[hydrochloric]

So the CAN devices SHOULD share a common ground? This has been one of the most difficult things to find an answer to. From what I found, the data is transferred by the difference across the High and Low, not referenced to ground. Do all the devices need to be referenced to ground just to have a voltage on High/Low at all?

The nodes might be the main issue- I don't think both are active. I do have a WiFi OBD2 reader (PLX Kiwi WiFi), but I don't know of any way to hook that up to a computer in any useful way (nor any way to use it as a monitor device, since it is set up specifically for OBD codes).

What software would one use for such a device? A straight serial port viewer?

 

[Coulomb]

So the CAN devices SHOULD share a common ground? This has been one of the most difficult things to find an answer to.

I think so. The electronics on the charger is connected to the negative of the pack, but they seem to use an isolating CAN chip, so the CAN wires (CAN-HI, CAN-LO, and CAN-GND) are all isolated from the pack. So connect CAN-GND from the charger to CAN-GND of the BMS. (Also CAN-HI and CAN-LOW need to connect, obviously).

From what I found, the data is transferred by the difference across the High and Low, not referenced to ground. Do all the devices need to be referenced to ground just to have a voltage on High/Low at all?

My recollection is that the bus normally has about two volts on it, I forget where that comes from, and for an active, bit, the two ends are "shorted" together. In order for the electronics to be able to pull the two pins together, they can't be hundreds of volts different from the CAN-GND that the chips are referenced to.

[ Edit: My recollection wasn't very good. The absolute voltage of CANH and CANL doesn't matter, within limits. Most of the time (with no messages on the bus), the bus will be in a "recessive" state, where the difference between the two signals is less than about 0.4 V. When (I think) a zero is being transmitted, the voltage difference is at least 0.9 V. If you are measuring a bus where there is nothing acknowledging the messages, they will be re-transmitted over and over with no gap, so it's quite possible to see about 2V more on one wire than the other, as averaged by a multimeter. ]

Remember that while I'm using the CAN version of the charger, I'm not using an actual CAN bus, just the RS232 that I reverse engineered. So I'm not familiar with the details of the actual CAN bus. We're not using the separate CAN box, just the cable.

What software would one use for such a device? A straight serial port viewer?

You could, if you built up the simple circuit I was using, and set the straight serial viewer to 2400 bps. That's assuming that they haven't changed the RS232 details; since it's not published, they are free to change how it works internally. Be aware that if you build the simplest of circuits like I did, then that circuitry will be connected to the negative output of the charger. It would not be hard to use a circuit that did opto isolation as well. With my early circuits, I was just wanting to talk to the charger at all.

 

[Coulomb]

So, from what I've read, the CAN data that the BMS sends out needs to have the same ID as the charger's CAN module (in my case, 0X 18 06 E5 F4 - this is written on the case of the charger CAN module)?

Yes, this is necessary. Actually, there are two magic numbers, that's only one of them. This is the ID that the charger is looking for to accept voltage and current commands. The other will be the ID that the charger outputs present voltage and present current (I didn't say current current ) which the BMS should be looking for, unless it has access to the battery voltage and charge current already. I was assuming that the BMS was all set up for talking to this exact charger - a few of them are, since the Elcon is fairly common. Oh, the ID the charger outputs on seems to be 0x18FF50E5. So you might have to configure the BMS to listen for that number, too.

I have configured the BMS to use 250kbps speed, and Extended 29bit IDs.

Good. That's important.

I didn't set the ID to the above number, I wasn't aware that should matter.

Well, maybe the addresses are fairly standard... but I'd certainly check. If you can see what the charger and BMS are putting out, then you can see what they are sending, but you can't explicitly see what they are listening for. I guess that's why the listening number is on the side of the CAN box.

One of the other things I noticed you had done was viewed the charger's 7-pin output via RS232?

Yes, since at least the old models didn't support a "real" CAN bus, and we were using RS-485 anyway for the BMS, we figured it was easier to not use the CAN box at all. Fortunately, the protocol was very easy to figure out, once I got past a few issues (such as blowing up an opto in the charger... sigh.)

The BMS has an option to "Send to RS232/USB", but this doesn't appear to be working

Well, maybe it's worth pursuing that. I would exect to see the BMS sending out packets, even if the charger isn't responding to them. But you may be right.