Interfacing: model 3 PCS <--> aem EV BMS-18 master

[jokeitch]

Starting a thread to ask some questions, I'll be updating this as things become clearer and hopefully have a full guide one day

First question:
The M3 PCS needs to see the CP and pp pins on the j1772 port, as well as of course see L1, L2, and PE (gnd)

However the bms-18 master also needs to see the status of CP and PP

Will both systems having access to those pins cause some trouble? Will they interfere with each other?

Second question;
Does the PCS need to do a lot a canbus chatter with whatever BMS is present? If so, will I need to look into tweaking the PCs controller firmware to output messages on addresses the AEM VCU200 is expecting? I'm thinking along the lines of the VCU200 seeing the bms-18 is reading all modules as high and done charging, and needing to tell the OBC (the PCs in this case) to quit it.

third question
there's a power switch going from 12v to the PCS control board on the wiring diagram, what actually throws that power switch? would it be some kind of wake signal coming from the vcu200? don't the cp and pp pins control when to "wake up" and start charging when the car's off? Or is that power switch more like an optional cold shutdown switch you can toss in

[Mojave]

The AEM BMS only needs to see the CP and PP pins if the VCU is directly controlling the OBC. If not they can be left disconnected.

[jokeitch]

i got a response back from an AEM tech in relation to a different question about balance charging, and his response seems relevant to this

To start off, the VCU will only command the BMS-18 to balance cells while charging and when conditions defined by VCU BMS logic and user calibration parameters are met to do so. Also, the VCU CAN3/4 network should form a loop that starts at CAN3 and ends at CAN4 with all CAN3/4 devices being not terminated since the Can 3 and 4 ports at the VCU are internally terminated.

You can configure the VCU to only look for 1 BMS cell group (master) and configure the VCU to allow balancing of a single group however, doing this will take a very long time to balance the entire pack since you’ll be doing up to 18 cells at a time and only up to 3 cells per cell group will balance at once. If you had 6 BMS-18 units wired up, the system will balance 3 cells per BMS-18 unit at a time, cutting down the time required since you are now balancing a total of 18 cells at a time if using 6 BMS-18 units.



2- Again, balancing is commanded by the VCU only while J1772 charging. This requires that the BMS is wired to the J1772 port Prox and Pilot lines. This requires that a VCU compatible CAN controlled OBC is wired to the VCU CAN3/4 network, HV, and J1772 port along with charging related VCU calibration parameters are properly configured for the specific OBC in use and pack configuration.

When balancing conditions are met, the VCU will command the OBC to stop outputting current, command balancing of highest 3 cells per cell group, and then command the charger back on. It’ll then repeat this process until charging is complete. If options “ChargeTopBalance” is enabled, the system will continue to do this indefinitely until the VCU is powered down, otherwise the VCU and system will power down once “fully charged” criteria are met.

it sounds like the vcu will need to be able to see PE and PP at all times in order to balance correctly, as well as command the model 3 obc to start and stop charging

[jokeitch]

getting back into this, can damien's controller deal with being "told" to start charging without seeing the CP and PP pins?

it looks like the aem bms really wants to be entirely in charge of charging, and basically just bark orders at the OBC to start and stop on a dime

the signaling would be over CAN but idk if the Damien controller is ok with that (hopefully it is since i already got the hardware)

[jokeitch]

Update, as of current controller firmware and for the foreseeable future, the pcs isn't controllable over CAN. It also absolutely MUST be connected to the j1772 cp and pp pins at all times.

so for this all to work, the bms-18 will need to be configured to not need the cp and pp pins, and instead get those signals over can from the pcs (since it can broadcast parameters) . It's not yet clear if this is even possible with stock bms-18 firmware, aem is so slow with emails i may not know for months

also i'll have to make a little can relay controller out of an arduino or something, that listens for charge request signals from the vcu, then arms 12v lines to the pcs controller input lines 1 and 2

[tom91]

https://documents.aemelectronics.com/a8 ... 789ddd.pdf

Code: Select all

The VCU/BMS Wake (pin 22) is a bidirectional input/output that both wakes up the BMS and also allows the
BMS to wake up the VCU. This is needed since there are times when the VCU is asleep and the cockpit wake
switch is off but the J1772 charging needs to wake up the VCU and initiate charging. This input should be
2024.04.12 – Document Number: 10-8401-EV © 2024 AEM Performance Electronics
connected to the VCU Wake pin as well as the cockpit +12v wake switch. I

1. So the BMS wakes the VCU to "start" charging the VCU probably needs to be awake to close contactors and the likes. So no idea how to get an AEM VCU to do this. You could look at wiring the HV request to the VCU some how to enable contactor closing.
The PCS is checked by the Controller to see if it has HV, during the starting of charging.

2.There also is an enable as you mention that you will want to send to the PCS controller once the VCU is happy to charge. Enable can always be on, it is only checked to allow it to start the process even before it requests HV. Enable needs to go low once you want charging to stop.

3.You need to configure the CAN messages read by the PCS controller to keep the charging within the limits set by the BMS. (theoretically the "easy part")

Again this is just info I have found through reading the code, I do not have a setup to verify these on. Also the wiki is very lacking on pinout info and pin functions. Damien has it working on his cars so the info is out there.

Edit:

Note I have no idea how AEM do drive away protection and the likes so you will also have to implement that somehow.

[jokeitch]

I made a crappy flow chart to summarize my proposed approach, each step has a number in order

as well as open questions and known limitations so far

a key piece of info is the documentation for the aem ccu, the "official" combo obc and dcdc converter for the aem ecosystem

https://documents.aemelectronics.com/06 ... 9891f8.pdf

this is great because it gives some insight into what the vcu wants to see in order to charge, which will be what i need my pcs controller intermediary to broadcast

there's also things in the vcu200 ldu setup document
https://documents.aemelectronics.com/te ... iption.pdf
but these are more about configuration fields in the aemcal software

Amusingly, i only just noticed, buried in the aem ldu doc, there's a section about supported chargers, and there's one i haven't seen mentioned before...

That dilong unit...it's actually only like $1000 on alibaba. I'm now wondering if that's actually old documentation and they dont support it anymore, meaning to support their CCU unit which is a different model of combo obc+dcdc
https://www.alibaba.com/product-detail/ ... 13001.html

[P.S.Mangelsdorf]

Amusingly, i only just noticed, buried in the aem ldu doc, there's a section about supported chargers, and there's one i haven't seen mentioned before...

That dilong unit...it's actually only like $1000 on alibaba. I'm now wondering if that's actually old documentation and they dont support it anymore, meaning to support their CCU unit which is a different model of combo obc+dcdc

I'm pretty sure that 2 in 1 unit is resold under several names.

[tom91]

vcu wants to see in order to charge

No its not, it is what it expects from the Charger. The BMS puts it in charge mode.

If you want your build to work and be less dependant of AEM Support and them making changes you need, get a supported charger.