First-Time Config of FOCCI And CCS1 vehicle charging

[serh270]

Hi All, I've mentioned in some prev postings but I am currently trying to implement DC CCS1 charging into a larger project and had this task mostly thrust upon me. I have a FOCCI board as well as the ESP32 interface and have finalized the plans to implement it all. I would be very grateful if someone could look over the below images and descriptions and let me know if they seem some errors/problems.

High-level Schematic:

I do not yet have any thermistors connected but have plans to do so in the future along with a Bender AGH420 leak detection system.

Communication between Vehicle Management Computer (VMC) and FOCCI:

I am not sure if there is any information I am missing but so far, this is what I have. The vehicle-side communication is done by a python can interface that will continuously send the can messages on the bus and read from FOCCI.

- [ ] ISSUE #1
I attempted to configure FOCCI to send the max power parameter over can and while it did send a message with the correct id, there was no data in the message other than an arbitrary offset (added to see if the message was truly empty). I simply powered up FOCCI and the esp32 interface board and attempted to read these data values and had the above issue.

image.png (11.69 KiB) Viewed 854 times

This is quite a large post so apologies in advance if this is too much for such a forum. I have some limited experience in this area but not with projects like this so again, apologies if this is quite a "newb" post. Had this project thrust on me so I'll take any help I can get. These forums have been a very friendly place so thanks to those who have already assisted.

EDIT: One last question, I've been trying to send messages from the PCAN interface connected to my PC to FOCCI but haven't been able to verify that it's receiving these messages and the data inside them. Outside of my CAN mapping being incorrect, how could I test this? I would prefer to verify all aspects before attempting charging but I'm slowly running low on time.

[johu]

ISSUE #1

Gain=0 and x*0 is 0 Make Gain=1 and you'll get your data

In the diagram it looks like you're feeding 5V to Foccci? This is not necessary
The CCR might be redundant as the driver chips are quite strong, lets say 5A total contactor current (limited by reverse protection diode)

[serh270]

Thanks for the help with the gain, as with the feedback on the CCR (was unsure as to their power delivery). Noticed the gain issue as soon as I went back to read the descriptors .

I have been trying to read through the ccs1 protocol as well as the forum to try to understand the step by step flow-chart of a charging session to try to correctly write my charging manager software.

Just to verify my understand of a charge session:
1) Set MAX params, inlet voltage src, target, etc... before connection to charger
2) On begin sending SOC and EV side voltage to FOCCI as well as target voltage over CAN from the EV
3) Connect charger
4) Set enable to 1
charging session begin...

Upon reach session end criteria:
1) set enable to 0
2) wait for EVSE voltage/current to reach 0 (safe to disconnect)
3) Disconnect charger

If am have verified communication, would you recommend I simply connect everything up, set very low maximums and targets and simply test the charging? It is my understanding the the charger itself has certain failsafes but is there another way to test? I saw a lightbulb demo but again, unsure on exactly what differences there are in connection and how this is set up. Thanks again for the help

[uhi22]

"1) Set MAX params, inlet voltage src, target, etc... before connection to charger"
--> The max parameters and inlet voltage source are "parameters", in the sense that you configure them once when you build everything together, you save them into flash, and there they will be the complete car life. No need to write them each charging session.

"2) On begin sending SOC and EV side voltage to FOCCI as well as target voltage over CAN from the EV"
--> Not only on begin. Send the SOC always. It is only used to show it in the chargers screen, not really important but nice.
The BatteryVoltage needs to be send before connecting to the charger, yes.
The TargetVoltage can be a fix value which is the max battery voltage for 100% SOC. The charge current can start at a low value (1A) and increase slowly to a value what ever the BMS is allowing. Or use a fix 5 or 10A for the first tests.

"4) Set enable to 1"
--> No. The enable should be 1 from the beginning. Connect to charger afterwards.

For stopping the session, you can set enable=0, yes. Or press the button for 1s, or end the session on the charger. The Foccci will end the session, including waiting for voltage ramp down and connector unlocking. Afterwards you can pull the plug.

For the testing without much risk, just use your intended setup, but instead of the battery, connect a light bulb. Make sure that the BatteryVoltage and the TargetVoltage is matching the allowed voltage of the bulb.
If you want to skip the CAN communication part for the beginning, set the DemoControl to STANDALONE and the DemoVoltage to e.g. 230V. Connect a bulb instead of your battery to the contactors. And then just plug in.

[serh270]

"1) Set MAX params, inlet voltage src, target, etc... before connection to charger"
--> The max parameters and inlet voltage source are "parameters", in the sense that you configure them once when you build everything together, you save them into flash, and there they will be the complete car life. No need to write them each charging session.

So only send these values if there is a change to be made?

"2) On begin sending SOC and EV side voltage to FOCCI as well as target voltage over CAN from the EV"
--> Not only on begin. Send the SOC always. It is only used to show it in the chargers screen, not really important but nice.
The BatteryVoltage needs to be send before connecting to the charger, yes.
The TargetVoltage can be a fix value which is the max battery voltage for 100% SOC. The charge current can start at a low value (1A) and increase slowly to a value what ever the BMS is allowing. Or use a fix 5 or 10A for the first tests.

The charge current ramping would be handled on the control software side and not FOCCI? Also, once the target voltage is achieved, will FOCCI automatically shutdown or does this have to be handled on the control end?

For the testing without much risk, just use your intended setup, but instead of the battery, connect a light bulb. Make sure that the BatteryVoltage and the TargetVoltage is matching the allowed voltage of the bulb.
If you want to skip the CAN communication part for the beginning, set the DemoControl to STANDALONE and the DemoVoltage to e.g. 230V. Connect a bulb instead of your battery to the contactors. And then just plug in.

Haha what has been giving me some pause is how plug-and-play this product seems to be. Outside of the obvious basic high-voltage/load charging precautions, is there anything specific to the FOCCI board I should be looking out for?

[uhi22]

So only send these values if there is a change to be made?

When you change your battery, yes. And most likely you will not "send" them, you use the web interface (or command line tool) to configure them and write them into flash, so they will be there "forever".

The charge current ramping would be handled on the control software side and not FOCCI?

Foccci/Clara will do not ramping. It is just forwarding the values to the charger. The charger may apply a current ramping, but this is depends on the charger type. I have no experience of the case that the vehicle requests "full" current from the beginning, maybe this also works fine. My Hyundai is ramping up approx 1A per 30ms. To be discussed, whether a ramping inside Foccci/Clara should be implemented.

Also, once the target voltage is achieved, will FOCCI automatically shutdown or does this have to be handled on the control end?

No, neigther Foccci nor the charger will shutdown if the TargetVoltage is reached. The charger just will provide this constant voltage then. Usually, in this constant-voltage-mode at the last percents of the charge, the battery current will decrease, but this can last nearly infinitely. It is up to the user, to terminate. Either by pressing the stop button on the charger, or the button on Foccci, or sending enable=0 via CAN based on a certain SOC or a certain minimum current reached.

is there anything specific to the FOCCI board I should be looking out for?

In best case prepare a serial-to-usb converter to record the logging messages. This helps a lot for trouble shooting, or to just confirm that everything is fine

Edit: And as Johannes already wrote: Do not apply 5V to the Foccci. The only supply is the 12V (9 to 24 is fine). The 5V is an output to feed the voltage sense board.

[serh270]

All the communication issues have been solved. Managed to get communication and control going from a python program. Going to begin putting together the lightbulb demo and then attempting a session. Thanks for all the help! Will post updates

[serh270]

About to do my first charge test and wanna double check my order of operations.
1) config max values
2) initialize can comm between management computer and focci
3) live update EV voltage, target voltage, and soc (to FOCCI over can)
4) Set enable 1
5) Connect Charger
6) Begin current ramping (increase, wait for charger to catch up, increase, etc)
7) Keep sending EV Voltage, soc
8) Shutdown: Ramp down current to 0 (decrease, wait for charger to catch up, decrease, etc)
9) remove plug

Any specifics I'm missing here?

[uhi22]

The enable should be 1 from the beginning. Sending enable=0 would terminate the process, so you should always send 1.

In step 8, no ramp down to zero is necessary. Just send enable=0 or press the button on Foccci for 1s. The (fast) rampdown will be done by the charger.

[serh270]

Ran the first test, was unable to get to the actual charging portion but it seemed like foccci was communicating with the EVSE properly and displayed startup opmodes as well as the shutdown stages. Kept getting the CANTIMEOUT error though. I see that this means the "canwatchdog" did not receive the messages it was expecting for over a second. Are these just the "receive" mappings in the can mapping portion of the web interface? I was hoping that these would be "receive when available" configurations rather than expecting constant updates because for testing purposes I want to control different one-time parameters from my external dashboard controlling charging. I would love to provide logs but for some reason my jerry-rigged uart logger wasn't working.

[johu]

Are these just the "receive" mappings in the can mapping portion of the web interface?

CanWatchdog is reset automatically when a new ChargeCurrent is received via CAN. Of course provided you are using a recent version.

[serh270]

CanWatchdog is reset automatically when a new ChargeCurrent is received via CAN

So as long as a new ChargeCurrent is sent <1 sec, the CANTIMEOUT error should not occur?

Of course provided you are using a recent version.

I am using whatever came installed on the 4.2 foccci board.

[johu]

So as long as a new ChargeCurrent is sent <1 sec, the CANTIMEOUT error should not occur?

Yes

I am using whatever came installed on the 4.2 foccci board.

From the shop? Then I think it should be recent enough

[uhi22]

Looks like some good progress. Next steps from my point of view:
1. Find a working serial-to-usb, to get a log file. This would help a lot to understand what is going on.
2. I propose to by a cheap STlink adapter for flashing new software. Flashing via the web interface works often, but sometimes crashes.
3. Make sure that you send the ChargeCurrent at least once a second. Better twice a second, to be on the safe side.
4. If you have an older software, resetting the CanWatchdog works by creating a CAN mapping from the chargecurrent message with scaling zero. This sets the CanWatchdog to zero with each reception. Newer software does not need this trick, it resets the CanWatchdog on update of the ChargeCurrent.

[serh270]

1. Find a working serial-to-usb, to get a log file. This would help a lot to understand what is going on.

got mine working, just reusing some old hardware from prev project. Should be good to go for my next test.

3. Make sure that you send the ChargeCurrent at least once a second. Better twice a second, to be on the safe side.

is there an upper bound to how many times a sec it can be sent?

From the shop? Then I think it should be recent enough

From the shop, purchased it a week or two before the newest release

[uhi22]

is there an upper bound to how many times a sec it can be sent?

Good point. Not sure if somebody tested what happens if you send it each 250µs. But I think everything between 5ms and 500ms cycle time is fine.

[serh270]

Keep attempting to charge but without making any hardware changes, the EVSE seems to have stopped recognizing when it is plugged into the inlet. Is there anything on the software side that could be causing this? All I am doing before charging, outside of sending can data to the charger, is set enable to 1 on startup.

The only suspect thing is that control pilot duty is reading 0%, even while the charger is actively connected. Could the problem be with the connector (inlet or plug)?

[uhi22]

The 0% CP duty is clearly pointing to an error, either of the charger, or of the wiring. First point is to take a multimeter, and measure on the unconnected charger whether there are 12V between CP and PE. Second, check whether the CP of the inlet is connected to the CP pin of foccci. Third, with removed Foccci connector and plugged-in charger, you should see the 12V on the CP pin of the Foccci harness. And when plugging everything together, the CP should change from 12V to 9V and then after some milliseconds (up to a second) change to 5% PWM with -12V and +9V. In best case, you could use a scope to check this.

[serh270]

The 0% CP duty is clearly pointing to an error, either of the charger, or of the wiring

The charger I am using requires a "start charge" button press once it recognizes that it is connected. Even before this initiation, should there be a >0% reading on CP duty cycle?

[uhi22]

Nobody knows. Best would be a scope to check

[uhi22]

Cross referencing a potential root cause: mixup of PP and CP: viewtopic.php?p=70247#p70247

[serh270]

Redid most of the connections and that seemed to fix the issue. My guess is that one of my temporary lever connectors wasn't totally secured and causing my headache. Wasn't able to connect the vehicle but I connected the EVSE and it recognized the connection again. My other guess as to the cause is that there was an issue with the PP. From the testing I have done, it seems like the EVSE won't send any CP data until it is "initialized" which won't happen if the PP connection isn't correct.

Good point. Not sure if somebody tested what happens if you send it each 250µs. But I think everything between 5ms and 500ms cycle time is fine.

Currently running a 3ms cycle and that seems to be working fine. (not yet charging but not getting the timeout error anymore)

[uhi22]

Great. In case you are charging (or run into trouble) it would be nice to provide a logfile, and the charger type if possible.