First-Time Config of FOCCI And CCS1 vehicle charging

[johu]

For Precharge TargetVoltage isn't used but BatteryVoltage. Is that mapped correctly?

[uhi22]

Nobody tried above 500V, I guess. Regarding unloaded tests: Different chargers behave differently. Alpitronic make a perfect regulation, no matter whether they are with no load. Others overshoot the voltage and shut down.

[uhi22]

Well, this could be the trigger to integrate also the ISO schema besides the currenty used DIN schema. Seems possible, but some work to do.

Trying to support DIN and ISO in one software runs into out-of-memory (RAM and ROM) at the moment. https://github.com/uhi22/ccs32clara/tree/iso-test

[johu]

Yes, that would require much more RAM

Code: Select all

   text	   data	    bss	    dec	    hex	filename
 683952	   2112	 154504	 840568	  cd378	stm32_ccs

Solution would be either try to butcher some redundant stuff or bigger MCU like https://www.digikey.de/de/products/deta ... Q/18085716 or https://jlcpcb.com/partdetail/Stmicroel ... 6/C5270988

[uhi22]

Found out, that the ISO1 (aka ISO 2013) needs less ressources, and also KIA EV6 uses this schema, so it should be fine for us. Now it fits. In case someone needs the ISO2 (aka ISO 2016), a bigger controller is necessary. What a crazy thing.

[Edit] We are off-topic here, so let's discuss the DIN/ISO topic in the main Foccci thread: viewtopic.php?p=70756#p70756

[serh270]

For Precharge TargetVoltage isn't used but BatteryVoltage. Is that mapped correctly?

I believe this was done to verify the upper limit of the charger (if you mean that the values are the same, I am a little unsure what you mean)

Nobody tried above 500V, I guess

Hopefully this works then

[serh270]

More reliability issues: Having made zero changes since the last loaded test, unloaded tests today resulted in the charger faulting during CableCheck. I've attached the logs below. It has many errors still, as I couldn't secure a shorter cable/better UART-USB device but I will soon. Any thoughts as to what might be causing this? If I'm missing any information, I'm happy to provide what I can.

[uhi22]

good news: The Qingdao announces that it is able to provide 1000V, even with the good old DIN:
"EVSEMaximumVoltageLimit.Multiplier": "-1",
"EVSEMaximumVoltageLimit.Value": "10000",
"EVSEMaximumVoltageLimit.Unit": "V",
and 150V minimum:
"EVSEMinimumVoltageLimit.Multiplier": "-1",
"EVSEMinimumVoltageLimit.Value": "1500",
"EVSEMinimumVoltageLimit.Unit": "V",

In the log I see the cable check is successfully passed:
[705380] The EVSE says that the CableChecë is finished and ok.
[705380] Will send PreChargeReq

and in the PreCharge the voltages are not fitting, that's why it does not finish:
[708380] PreCharge aknowledge received.
PreCharge aknowledge received. Inlet 0V, accu 20V, uMin 150V
[708390] Difference too big. Continuing PreCharge.

For Precharge TargetVoltage isn't used but BatteryVoltage. Is that mapped correctly?

Johu wants to say, that Clara expects two inputs from CAN:
1. The actual battery voltage (in your case reported as 20V, which seems wrong). Clara uses this voltage to tell the charger the precharge voltage.
2. The target voltage, which is usually higher than the actual battery voltage. Clara uses this voltage during the charging loop to limit the voltage, to avoid overcharging the battery.
You need to feed both voltages in a consistent way. With 20V battery voltage the charger cannot charge (it is 150V minimum), and that's why Clara is stuck in the PreCharge.

[serh270]

Whoops, looks like the output file may be partially overwritten by the new log, and the rest of it is from the first file I uploaded. Looks like screen doesn't start from fresh when overwriting a log file, but rather operates concatenates.

Code: Select all

[1191140] [PEVSLAC] from 2 entering 4
[1191170] In state Off. TcpRetries ∞
[11912π0] [CONNMGR] 165 158 0 0 0 0 0 --> 10
ˇ[552650] In state Off. TcpRetries 0
[552980] [PEVSLAC] Timeout while waiting for`SLAC_PARAM.CNF
[u52980] [PEVSLAC] from 4 entering 0
[553018] [PEVSLAC] from 0 entering 2

There's this odd change in log value numbering. I think this may be where the new log starts? I have uploaded a shortened version starting from here.

[uhi22]

I use Putty on windows10 for logging, this adds nice wall-clock time and date at the beginning of each session. And if you repower the foccci before plugging in the CCS, you also get fresh time stamps of clara, starting at zero milliseconds. Both helps a lot for orientation.

[uhi22]

There is confusion. You are saying the cable check fails, and in the related log it is successful.

How do I get to this conclusion? Using Notepad++, there is in the search window (Crtl F) the button "find all in current document". Searching for "CableCh" reveals the conclusion.

[uhi22]

There's this odd change in log value numbering.

Do you talk about this: [705380]? This is not a "log value numbering", this is the time since Foccci was powered-on, in milliseconds.

[serh270]

I'm using screen on debian. I'm now saving the old log to gDrive, then removing and logging rather than overwriting.

Conducted a loaded test today. Same Cable Check fail. It seems that PPresitance goes to 10000 in the middle of the test. Statically, a multimeter reads 150 ohm between PP-PE which seems consistent with documentation. However, the logs I've attached read wildly different values. Not sure why this is. I've shown a snippet of this below.

Code: Select all

5800] cpDuty [%]  0
[135810] AdcProximityPilot  2322
[135810] ResistanceProxPilot [ohm]  982
[135810] HardwareVariant  4002
[135810] ETH will transmit: ffffffffffff02342883105788e101646000000000023428831057000000000000000000000000000000000000000000000000000000000000000000
[135810] [PEVSLAC] from 2 entering 4
[136210] In state Off. TcpRetries 0
[136280] [CONNMGR] 165 112 0 0 0 0 0 --> 10
[136790] [PEVSLAC] Timeout while waiting for SLAC_PARAM.CNF
[136790] [PEVSLAC] from 4 entering 0
[136820] [PEVSLAC] from 0 entering 2
[136850] [PEVSLAC] Checkpoint100: Sending SLAC_PARAM.REQ...
[136850] cpDuty [%]  0
[136860] AdcProximityPilot  3082
[136860] ResistanceProxPilot [ohm]  10000
[136860] HardwareVariant  4002

There is confusion. You are saying the cable check fails, and in the related log it is successful.

I believe this is a problem with this log file. Apologies. Below is the cable check failing.

Code: Select all

[152790] Will again send CableCheckReq
[152790] TCP will transmit: 01fe800100000010809a0210d1510cd04d91505011401540
[152790] ETH will transmit: a0b0c0d2347e02342883105786dd60000000002c060afe80000000000000c69083f3fbcb981efe80000000000000a2b0c0fffed2347ee756c35000000286d4e9cd09501803e842fc000001fe800100000010809a0210d1510cd04d91505011401540
[152790] cpDuty [%]  5
[152800] AdcProximityPilot  3033
[152800] ResistanceProxPilot [ohm]  10000
[152800] HardwareVariant  4002
[152810] ETH rx IP: 023428831057a0b0c0d2347e86dd6000000000140640fe80000000000000a2b0c0fffed2347efe80000000000000c69083f3fbcb981ec350e756d4e9cd090000029e50100384eaa50000
[152870] ETH rx IP: 023428831057a0b0c0d2347e86dd6000000000140640fe80000000000000a2b0c0fffed2347efe80000000000000c69083f3fbcb981ec350e756d4e9cd090000029e50140384eaa10000
[153110] [CONNMGR] 165 0 0 466 22 153 1012 --> 100
[153170] In state CableCheck. TcpRetries 0
[154100] [CONNMGR] 165 0 0 433 0 120 979 --> 100

My biggest problem is that I have no idea what could have caused this as I have verified continuity and voltage levels across all connections with a multimeter. I made no changes to the wiring. I made only can-mapping changes.

For Precharge TargetVoltage isn't used but BatteryVoltage. Is that mapped correctly?

I understand now. This had the same can-message length error as mentioned previously on this thread. It is now fixed (same fix)

[uhi22]

There are physical connection issues. Back to 8th of May:
2. When plugging and unplugging, you should see in the web interface resistanceproxpilot changing between 10000ohms (means infinite) to whatever your charger has.
3. If nothing helps, disconnect everything, use a resistor (something between 100ohms and 1500ohms) and connect it between PP and ground on the Foccci. The value should be visible in the web interface at resistanceproxpilot.

[serh270]

There are physical connection issues.

I do not think the issue is physical connectivity. I ran some more unloaded tests (values under 500v to negate any din/iso issues), and the PPresistance values were reading nominally until I initiated the charging sequence. I tried this with two separate chargers with the same result.

I tried messing with PPvariant and when it was set to 0, PP resistance was reading ~2800 during the charger fault. Again failing cable check. Could this be a configuration issue? I'm beginning to suspect that a problem occurred with FOCCCI at some point during testing.

I've attached logs from the latest test below.

[uhi22]

It does not help to try random things. The goal is to find the root cause, why the PP resistance is not 150 ohm. This is a simple resistance measurement, where not much can go wrong. Theres a certain chance, that fixing this issue could also fix the failed cablecheck.
To find the issue with the PP resistance, I'd propose to do some additional measurements. Because, we have your 150 ohms (measured with your multimeter) and on the other hand this, measured by Foccci:

This could mean, that the Foccci in general is measuring wrong, or that something between Foccci and the CCS plug is wrong. To find this out, I propose to connect a 150 ohm (or what ever) directly to Foccci, between PP and ground. This should (if you configure the correct PP variant) lead to the correct value in the web interface. If not, search inside Foccci. If yes, search in the harness.

You could also do a voltage measurement, to find out where is the issue. Foccci has a pull-up of 330 ohm to 5V. If you have 150 ohms PP resistor in the plug, the two resistors form a voltage divider between 5V and ground. The divided voltage is around 1.5V. You could take a multimeter, and measure the following positions:
1. PP to ground directly at the Foccci board. Expected: 1.5V. Measured: ....
2. PP to PE at your CCS inlet. Expected: 1.5V. Measured: .....
3. PP to PE inside your charger (there where the empty PP wire hangs around). Expected: 1.5V. Measured: .....
If the Foccci says that the resistor is much higher, you will measure much more that 1.5V directly at Foccci, and the position where the voltage is lower will guide you to the point where the connection is bad.

[serh270]

Update: Success!
After many fixes, was able to repeatable charge at 700v+, 20A+ with mostly no problems. Found the PP issue lied in the dc/dc converter we were using. There was a defect from the factory and it was not properly grounded, giving FOCCCI an incorrect reference. Replacing it with a new one solved all resistance-measurement issues.

Something to beware of: The mains power cables running through the fuse in the charger were, from the factory, not properly secured and through vibrations from rolling the charger, had popped out at some point. Many screws on the casing were also lose. Aside from these quality errors, it seems to be functioning just fine.

Another fix, PP variant was for some reason defaulting to 2 and this was not working. Setting it to 2 worked great.

It does not help to try random things

Apologies if this is how it came across. My logic may have been incorrect but I promise nothing was done randomly XD.

To confirm a couple things:
- FOCCCI/CLARA had no problem charging ~800v and pushing 25A. Maybe that was only with this specific charger but again, no problems on that front.
- With contactors closed, the entire system was drawing about 450mA at 24V (90-130mA when contactors open).

Potential Errors:
- The "maxPower" parameter didn't seem to stop me from setting voltage/chargeCurrent to values exceeding the set max wattage.
- MaxVoltage didn't seem to prevent me from setting target voltage higher (did not prevent the output power)
- MaxCurrent did not prevent me from setting a charge current
- Sometimes, FOCCCI would not ramp down the output current when EVSE voltage reached the "maxVoltage" param.

I'll do more empirical testing to confirm the above findings but these were just a few things I noticed. What is the hierarchy in terms of maximum values? Is it simply which ever it hits first? Or are these values simply for the supply?

One small suggestion for the interface:
It may be beneficial to add certain params like target voltage or charge current to the spot value page? It may get quite cluttered but it might just be nice to see those side-by-side with the realtime spot values.

Thank you so much for the support!! Thank you for the patience and assistance. Unfortunately the error was quite anit-climactic but at least it works now

EDIT: Setting PP variant to 1 did the trick, not 2

[uhi22]

Great, congratulations!

- The "maxPower" parameter didn't seem to stop me from setting voltage/chargeCurrent to values exceeding the set max wattage.
- MaxVoltage didn't seem to prevent me from setting target voltage higher (did not prevent the output power)
- MaxCurrent did not prevent me from setting a charge current

Clara gives these three max values to the charger, in the chargeParameterDiscovery request message. The charger may or may not respect them, this is not in the hand of Clara. If your charger does not respect the limits, you could try to create an issue report for the charger supplier, maybe they want to fix this.

- Sometimes, FOCCCI would not ramp down the output current when EVSE voltage reached the "maxVoltage" param.

Clara is not expected to ramp the current. It just routes the targetVoltage and targetCurrent to the charger, and the charger shall respect these values. The "maxVoltage" is more a safety parameter, which is not intended for ramping or controlling at all. On some chargers, it leads to shutdown, if this voltage is reached.

I updated some parameter descriptions in the Wiki, to make the things more clear. https://openinverter.org/wiki/CCS32Clara

One small suggestion for the interface:
It may be beneficial to add certain params like target voltage or charge current to the spot value page? It may get quite cluttered but it might just be nice to see those side-by-side with the realtime spot values.

Good point. We'll have a look.

[serh270]

Clara gives these three max values to the charger, in the chargeParameterDiscovery request message. The charger may or may not respect them, this is not in the hand of Clara. If your charger does not respect the limits, you could try to create an issue report for the charger supplier, maybe they want to fix this.

I understand now. I'll implement more saftey/shutdown procedures on my end rather than expecting the charger to do it.

I updated some parameter descriptions in the Wiki, to make the things more clear. https://openinverter.org/wiki/CCS32Clara

This makes things very clear, thank you