Two FOCCCI's on the same bus

[serh270]

Hi all. I am attempting to use two FOCCCI controllers (one 4.2 and one 4.5) on the same CAN-bus to enable dual EVSE charging. I have everything configured such that both controllers are on the same CAN bus but the PP/CP and PE lines from the respective CCS ports are isolated. Each charger works on it's own, however, they stop working when trying to run them at the same time. For example, I can initiate an unloaded charge on one EVSE but then when attempting to start the second, the first shuts down and posts a PLCTIMEOUT error. Then, the serial output for the non-functioning charger outputs "TCP error - wrong port". I suspect the issue lies in the wring of the charger inlet as when the two share a ground connection, some of the EVSE data from a charging EVSE will display from the second, non-charging EVSE.

All tests conducted were unloaded at 750 volts. I, of course, did not have the sense to initiate logging on the serial output but if I conduct further tests I will be sure to do so.

Does anybody have any general tips/ideas/intuition as to what might be causing this interference and how it may be resolved? I would be happy to provide more information.

I do not think the issue lies in the can communication as the messages seem to be intact in both directions. Thanks for the help!

[serh270]

after much trouble shooting and completely isolating the power supply to each board, I believe the can communication is the culprit. Both boards seem to send a can message with id 88 and I suspect this is the problem. I will try to create a second can bus and re-write the control software to operate in this way.

Is there anyway to disable this id 0x88 message? What is the purpose of it?

[uhi22]

The CAN message 88 is strange. Normally, if no CAN mapping is configured, the Foccci should just send two bootloader messages, as shown here: viewtopic.php?p=64555#p64555
What does the CAN mapping page in the web interface show?
Side topic: Does it work to configure different nodeId for each Foccci, and to use the web interface to connect to each individually?

My assumption regarding the loss of communication while the "neighbor" is connected: It is not CAN related. I guess it is caused by cross-talk between the CP lines, so that the running session gets PLC data from the other and is disturbed. There were also reports (from @johu) where on a public charger the session stopped when an foreign car was plugged on the second port of the same charger.
A serial log of such an abort would be helpful. And we need to review the software, to find where this comes from. You could try to force this cross-coupling by just running the two CP wires near to each other for 20cm, this should give sufficient coupling to reproduce the issue.

[uhi22]

Implemented a bugfix, so that Clara ignores the neighbors SLAC and SDP.
The issue: https://github.com/uhi22/ccs32clara/issues/24
The commit: https://github.com/uhi22/ccs32clara/com ... 965b6f25a6
The binaries: In the "Artifacts" section of continuous integration build #37, https://github.com/uhi22/ccs32clara/act ... 9922911558

I propose to run further tests with this new software, and in case of still having issues, provide a serial log.

[johu]

Congratulations, seems fixed

I drove to my local Aral Pulse which has two Alpitronic HyperChargers. I just took the chance and plugged in. Only a minute later a Danish family arrived and I asked them to plug into the other charge port on the same charger. When they started I saw my power briefly drop from 70 to 50kW for a few seconds. Most importantly the session was NOT interrupted

[xvyDFatih]

I want to communicate two focci board from car to car.

Which function do i need to use in clara code

For example i send 10 variable also i receive 10variable from another car

[uhi22]

Communication is only possible if the units are "paired", which means they use the same network ID (nid) and network key (nmk). With an EVSE, the SLAC sequence is used to assign these to the car. If we just have two cars, the SLAC is not possible. You could send a setkey with identical nid and nmk on both sides, but since the PEV modems are configured with the option "Central coordinator=No", I guess the modems will not find each other. Adding a third participant eg a homeplug adaptor with the same credentials should solve this.
Afterwards, if both focccis are in the same network it is possible to send a raw ethernet frame where you can fill a lot of bytes, and which will appear in the ethernet receive function of the other side.

The transmit function is myEthTransmit(). The data and length need to be filled into myethtransmitbuffer, myethtransmitbufferLen before calling the transmit function.

[xvyDFatih]

If i use send func in one board
Also i use receive func in another board

Why i need slac operation or another things

Can i use just send and receive functions

I want to set a communication between two focci board

Is it possible without slac operation or anything

Just i want to communicate

[tom91]

I want to set a communication between two focci board

Why?

Why i need slac operation or another things

You need to setup a network.

[xvyDFatih]

I have to set a communication between two EVs

[tom91]

I have to set a communication between two EVs

To do what? Any reason to use the Foccci and not just CAN?

[xvyDFatih]

To do what? Any reason to use the Foccci and not just CAN?

Because i will use ccs plug to communicate between EVs with focci

[tom91]

Better get to coding then. As uhi said you need a "master" EVSE "slave" PEV setup to get the SLAC comms started.

Depending what else you are looking to do you need to start to combine the various code bases that uhi helpfully shared on github.

[hiro]

Hi all. I am attempting to use two FOCCCI controllers (one 4.2 and one 4.5) on the same CAN-bus to enable dual EVSE charging. I have everything configured such that both controllers are on the same CAN bus but the PP/CP and PE lines from the respective CCS ports are isolated. Each charger works on it's own, however, they stop working when trying to run them at the same time. For example, I can initiate an unloaded charge on one EVSE but then when attempting to start the second, the first shuts down and posts a PLCTIMEOUT error. Then, the serial output for the non-functioning charger outputs "TCP error - wrong port". I suspect the issue lies in the wring of the charger inlet as when the two share a ground connection, some of the EVSE data from a charging EVSE will display from the second, non-charging EVSE.

All tests conducted were unloaded at 750 volts. I, of course, did not have the sense to initiate logging on the serial output but if I conduct further tests I will be sure to do so.

Does anybody have any general tips/ideas/intuition as to what might be causing this interference and how it may be resolved? I would be happy to provide more information.

I do not think the issue lies in the can communication as the messages seem to be intact in both directions. Thanks for the help!

Hi All.

These still don't work properly.

I am continuing to have him try using two chargers to charge one car.
The two chargers work fine when used separately.
If I have one charger running and I start a second charger, it will never get past the start of the charging sequence.
The second charger does not show any errors.
The first charger continues to work normally.
Then, when I manually shut off the first charger, the second charger's sequence begins and it starts charging.
The situation remains the same even if the starting order of the two chargers is swapped.

Does anyone have any ideas how to solve this issue?
Thanks for the help!

[uhi22]

The most helpful information would be a serial log. More ideas here: https://github.com/uhi22/foccci?tab=rea ... oting--faq

[hiro]

Hi

I took logs while trying to charge using two chargers.
This log is from the second charger.

The approximate timeline is as follows:
[35210] Start the 1st charger.
[69800] Start the 2nd charger.
[91400] Stop the 1st charger manually.
[142970] Stop the 2nd charger manually.

I would really appreciate it if you could review these and give me your advice.
Thank you.

[johu]

Most important piece of info: you're using outdated firmware 0.38.B

Please read carefully what is written in a thread to avoid redundancy

viewtopic.php?p=72829#p72829

[uhi22]

An other interesting finding in this log file is, that for a single SLAC_MATCH request we receive two SLAC_MATCH confirmations, which are addressed to different Focccis (023304732057 and 023428831057), and contain identical source MAC address a0b0c0d2345b.
One explanation would be, that both chargers are using the same MAC address, which would make addressing "a little bit" tricky.

So please do two steps:
1. Use the latest firmware e.g. from the github continuous integration build here: https://github.com/uhi22/ccs32clara/actions
2. In single charging sessions on each charger, check whether both cables of the charger have different MAC addresses. The MAC address of the charger can be seen in the SLAC_MATCH.CNF message, e.g. here:

image.png (10.66 KiB) Viewed 2174 times

If it turns out that really both chargers use the same MAC (which I do not hope and which should never happen) we need to think about a workaround.

[uhi22]

Fortunately, the two SLAC_MATCH.CNF in this log contain to different destination MAC addresses.
destination source
023304732057 a0b0c0d2345b
023428831057 a0b0c0d2345b
So we can implement a filtering in Clara, that it only takes the "personal" message, and discard the message which has a foreign destination MAC. This can be easily implemented in the function evaluateSlacMatchCnf().

Edit: Created https://github.com/uhi22/ccs32clara/issues/42
Edit2: Implemented a solution proposal. Ready for testing.

[hiro]

I appreciate your help, but I need a little more of your help.

I made a mistake with the firmware update, I tried to update the wrong file and now I can't communicate with the Foccci board.
The power-on light(?) is on, but the [ALIVE] light has stopped flashing.
And communication via the ESP32 CAN Web Interface was no longer possible.

The firmware update for the other board was successful.

Is there any solution to this situation?
Thank you in advance.

[uhi22]

Yes, you need a STLINK adaptor. This connects via USB to the PC and via SWD to Foccci.
The procedure is described in the Clara User Manual https://github.com/uhi22/ccs32clara/blo ... uild-chain

[hiro]

I appreciate your sound advice.

I used the STM32 ST-link to flash the Foccci board and it was successful.
After flashing, the [ALIVE] light started flashing again and Wifi communication was established via the ESP32 CAN Web Interface.

However, I cannot update the new firmware to Foccci from the ESP32 CAN Web Interface.
Even if I select the correct file, the update stops at about 5%.

The version of the Foccci board is v4.5, and the board that has already been successfully updated is v4.2.
Does this difference affect this issue?
Am I missing some steps?

[johu]

Try flashing this boot loader: https://github.com/jsphuebner/stm32-CAN ... s/tag/v1.2

[uhi22]

Good point, I just updated the clara user manual regarding the new bootloader version.

[hiro]

I tried charging it using two chargers at the same time.
But it didn't work, the situation is the same as last time.

The first charger is started and charging begins. Then, when trying to start the second charger, the start sequence does not proceed.
When charging on the first charger was manually stopped, the second charger's sequence automatically proceeded and charging began.
When I tried to recharge the first charger in that situation, the same thing happened as before.
It's like a seesaw game.
Both Clara version : 0.39.18.B
The logs are attached below.

LOG-double charging.txt

(1.43 MiB) Downloaded 37 times

2. In single charging sessions on each charger, check whether both cables of the charger have different MAC addresses. The MAC address of the charger can be seen in the SLAC_MATCH.CNF message, e.g. here:

I checked the MAC address of each charger.
The addresses of each are as follows:
1

2

I'd appreciate it if you could take a look at the data and let me know what the next steps are.