openinverter forum

Did you change the iaclim value and refresh to ensure it saved to flash?

Mine still shows 16A as max aclim, which is what I had it set to before. I cycled the numbers by going 15, then save to flash, then 16, and I’m still seeing a solid 4kW/16A when charging. I’ll drain the battery some today or tomorrow and try again.

If max still shows as 16, the new file didn’t save or you re-loaded the original. The max value available should be 48, not 16. Did the status bar take a few seconds to show 100% file upload? If you click upload and it instantly shows 100% it didn’t work in my experience.

Yep, I don’t see a progress bar at all, it’s instantaneous for me. I’ve tried maybe 10 times in Safari and another 5 in chrome, downloaded the zip file twice. Still no go :/ uploading with the bin file via UART update.

Try the hex file in that case. If not, you may need to use the swd connection on the board.

EDIT: Disregard the hex file. I believe binary are the only supported file type for OTA.

Loaded via the header and I’m seeing 32A, which sounds more like it for the taper. Thanks gents.

Spoke too soon, I’m getting similar behavior to the CAN dropout bug: In the middle-end of the session here you can see I lowered iaclim until I got a stable charge (16A , then went to 20A stable, then 25 and the bug kicked in again:

Hmm, could you log the various temperatures? Seems weird the bug would only occur at higher load and after such a long delay.

What’s your cooling setup and charger mounting position as well?

Will check out temps today - the charger is horizontal, bled fine, using a D5 pump and a 4x8 radiator with small fans. The exhaust from the fans didn’t feel warm, nor did the coolant reservoir. In the past I ran it without the fans on and got the coolant warm to the touch without any issues. I had stopped the charger (powered down) for 10 minutes mid charge before retrying, so I’m not sure it’s temp related. I also haven’t broken the setup since completing a clean 26kWh charge at 40A.

It does seem odd that it’s load dependent.. maybe more related to being over/under the ramped current calculation?

So next time you charge can you use the datalogger (log.html) to log
modaclim, c1tmp1, c1tmp2, c1iac, c2tmp1, c2iac, c3tmp1, c3iac

That should show if all chargers are doing the same, whether they are commanded to do so by modaclim or self limit, and whether temperature plays a role.

Plugged in the cold charger this morning and the issue started immediately. Attached is a log of the session sampled every 500ms. I can sample more frequently if that's useful.

Phase temps seem to go totally wild, into the thousands (are these supposed to be degrees?)

They're degrees. So indeed modaclim seems to actually drop, maybe to 0. This is most likely caused by the charger dropping out of run mode. And that would happen if some error is detected with one of the chargers. Possible errors are loss of CAN comms from the charger for more than 2s or a fault flag being raised.

So: can you plot state, c1flag, c2flag, c3flag while oscillation happens?

EDIT: invalid temps are down to comm errors between wifi module and stm32. Sometimes happens, especially when logging many values

Log attached

Ok, it definitely cycles off. Can you use the plot function from web interface, because averaging on flags=no good
I do suspect for some reason the charger modules assert an error flag which makes the software restart them.

I haven’t been able to capture the transition but here’s an odd behavior I’ve consistently seen.

My charge enable input is driven by a relay controlled by my BMS. Turns off at the desired charge voltage and turns back on when it dips below a set hysteresis level. Everything works as you’d expect, however, if I leave the j1772 cable plugged in, after one charge cycle, (I.e. was fully charged, dips below hysteresis, and re-enables charging) my idclim changes itself from 45 to 0. I’ve checked the values both before and after a successful charge cycle and the value still shows as 45. It seems to be something about the transition state back to charge without unplugging the EVSE that causes this change. I’ve witnessed this at least 3 times so far. The first, I thought I didn’t save a setting to flash but something else seems to be going on.

Could some SDO message from your VCU be messing with it? It is param index 0, so same as boost in sine firmware.

EDIT: I guess I should move SDO messages to 0x602.

Hmmm I can try disabling the boost message temporarily. The motor SDO messages aren’t sent when the VCU sees a charge enabled message, but I’m guessing there could be a loop or two of overlap.

Just browsed my code. Im currently sending a static boost value of 1875, with the resulting SDO msg bytes[5] = 0x60, byte[6] =0xEA.
Assuming the charger expects a 1 byte value here, 0x60 would result in an out of bounds value for the charger parameter of index 1 and shouldn't result in a valid parameter change based on the behavior Ive seen with the LDU. Let me know if that's not correct.

It is using all 4 bytes so 1875 should certainly be out of bounds and not change the value. I haven't seen any code modifying idclim though, not sure what is happening.

Ill keep an eye on it and see if I notice anything else. I did just do a charge cycle that involved unplugging the J1772 and reconnecting after a drive. Nothing abnormal there. This also mean the charger should have received a full barrage of CAN messages that the bus has to offer and idclim is still at 45. I may try putting a super small hysteresis value in so there's greater chance to observe this in action.

Just thought of a scenario that could write a zero value over SDO CAN message. By default my VCU does not assign a value when my boost variable is initially declared. So if I upload an update and reboot, or it hits a watchdog timer reset, it will not assign a value to that variable until I put the car into a run state. This means there is a period of time where it could send 0x00 to index 0.

I did upload a change to some throttle ramping last night, so this would explain the occurrence this morning.

So that should be a word of caution to anyone changing parameters over CAN on the same bus unless the control ID is changed.

UPDATE: Confirmed that a reset of my VCU will result in writing a zero value to that index. I wrote an initial startup value to the relevant variables to eliminate the chance of a zero being written in this scenario.

johu wrote: ↑Mon Jan 18, 2021 12:40 pm Ok, it definitely cycles off. Can you use the plot function from web interface, because averaging on flags=no good
I do suspect for some reason the charger modules assert an error flag which makes the software restart them.

I just tried the plot function, and the buttons don't appear to do anything for me. The gauges don't work either, so I tried reloading SPIFFS via curl also without any luck. Any tips here? Using Safari browser if that makes a difference.

Can you check that 192.168.4.1/chart.min.js.gz is present? And try another browser?

Navigating to 192.168.4.1/chart.min.js.gz downloaded the file, so it seems that it is indeed present. I also gave Chrome a shot and no go on that either. For plotting, the buttons were non-responsive, and for gauges I got a blank white screen at the address below. It looks like it’s not passing the items through, from my layman’s view. I’m using the latest from your git repository.

I use the same source files. It must be something with the javascript, the plot loads regardless of anything else. Even if you open index.html locally from your hard drive you should see the plot. Well, provided you unpack chart.min.js.gz and make the capital C lowercase. Strange...

Ok, try unpacking chart.min.js.gz , rename Chart.min.js to chart.min.js and repack to chart.min.js.gz . Then upload that to your ESP and check if you see the plot.