We have to restart PLC modem before every session.
Closed this issue · 11 comments
Your Setup
Platform: EVSE
Firmware Version: V02_00_01
Host Controller Interface: SPI
Host: FreeV2G (EV_v2.0.1_4)
Describe the bug
Actually, I'm not sure it's a bug, but let me explain. We have 4 EVs from different brands. They can be fully charged on the first try at the same charging station for day long. But after the second attempt we get "charge parameter timeout error", but if we restart the PLC modem before each charging session, everything is fine. They can all be fully charged the second, third and fourth time on the same charger.
To Reproduce
4 EV, 1 EVSE
1st day > Brand ONE fully charged, second try from diferent brand give "charge parameter timeout error"
2nd day > Brand TWO fully charged, second try from diferent brand give "charge parameter timeout error"
3rd day > Brand THREE fully charged, second try from diferent brand give "charge parameter timeout error"
4th day > Brand FOUR fully charged, second try from diferent brand give "charge parameter timeout error"
5th day > They can all be fully charged if we restart PLC modem before every session.
Expected behavior
We expect that we didn't need restart before every session.
Logs
No log
Hey @sametyazici,
unfortunately I can not help you without any log files. You can follow this guide in order to capture the logs.
Thank you,
lho
Sure. Error and Correct Logs are listed below.
CorrectLog.pcapng.txt
CorrectLogSerial.txt
ErrorLog.pcapng.txt
ErrorLogSerial.txt
Hi @sametyazici , I do not think that this issue is releated to the reset of the PLC. The connection is closed because the host did not update the charge parameters in time. If you are in the charging loop you need to update the paramters at least every 500ms (default value). In the log you sent this does not happen. I set a time reference on the last update of the parameters:
You can see that after 500ms the connection is closed.
Please habe a look at the note in chapter 18.10.4 Update DC Charging Parameters
You can also change the timeout, but this is not recommended for production systems 18.10.21 Set Session Parameter Timeout
Thank you. What are the possible reasons we get this error? We didnt get this error if restart PLC. We don't think restarting solved the error completely but it reduces the error.
The issue is that you do not update the charge parameters often enough.
In which interval are you updating the parameters with the message 18.10.4 Update DC Charging Parameters?
We update charge parameters under _handleNetworkEstablished method.
We pass values from power stacks with CANBUS to charging parameters below.
charging_parameters = {
'isolation_level': 0,
'present_voltage': int(self.charger.getEvsePresentVoltage()),
'present_current': int(self.charger.getEvsePresentCurrent()),
'max_voltage': int(self.charger.getEvseMaxVoltage()),
'max_current': int(self.charger.getEvseMaxCurrent()),
'max_power': int(self.charger.getEvseMaxPower()),
'status': 0,
}
We set time delta under while True Normally it does not exceed 110 ms. But if error occurs and yes it exceeds 500 ms right before. When we check, we see that the time delta exceeds 500 ms under the v2gEvseUpdateDcChargingParameters method. The problem seems to be in the network rather than updating the DC parameters. Do you have any additional solution suggestions? For example, we are currently using Raspian 32 bits. If we update to 64bit, will the problem be solved?
What du you mean by "We set time delta under while True"? What is time delta?
What is the error that occurs?
Have you added code in this function that blocks for more then 500ms?
time delta is a time difference in one loop. As you see print function prints time difference in one loop. When we get timeout error it prints over 500 ms. Of course we didnt add any code in block that run over 500ms. In normal conditions print function prints 100 ms too.
time_now=time.time()
while True:
print("+++delta+++",time.time()-time_now)
time_now=time.time()
if self.charging:
id, data = self.whitebeet.v2gEvseReceiveRequestSilent()
charging_parameters = {
'isolation_level': 0
'present_voltage': int(self.charger.getEvsePresentVoltage()),
'present_current': int(self.charger.getEvsePresentCurrent()),
'max_voltage': int(self.charger.getEvseMaxVoltage()),
'max_current': int(self.charger.getEvseMaxCurrent()),
'max_power': int(self.charger.getEvseMaxPower()),
'status': 0,
}
Do you have other processes running on the PI?
Have you tried increasing the priority of the freev2g process?
Use the nice command on linux command line:
sudo nice -n -10 <command>
Priorities range from 19 (lowest) to -20 (highest).
We have made progress to solve the issue. We were powering rpi4 from our custom board before. We cancelled it and power rpi4 from rpi4 original adapter. It dramatically reduces frequency of the error. We have UI process. It run in chromium. But host is localhost. UI does not use ethernet interface.
Hey @sametyazici,
I close this issue because you. If the issue still persists, please reopen it and provide new information.
Best regards,
lho