openinverter forum

Sounds great Please try.

johu wrote: ↑Mon Mar 28, 2022 3:08 pm Sounds great Please try.

You might answer my question first?

I would think it makes more sense to first make an assumption and change and check if the newer version still breaks it. If it doesn't we can always try to break it with the old version....

EV_Builder wrote: ↑Mon Mar 28, 2022 11:08 am @johu;
Is the requested power by the user or the amount send to the charger capped by anything? What if the user makes a typo like 32.0 or 32,0 and 320 gets requested internally? For example are there HW device limits in place?

Janosch speculated right

janosch wrote: ↑Mon Mar 28, 2022 11:28 am For the limits my understanding is that the firmware takes MIN of all limits to determine what to do in the end?

Code: Select all

aclim = MIN(cablelim, iaclim, evselim, hwaclim)
dclim = MIN(idcspnt, idclim)

Pure speculation

Indeed the step change was very small. It could even have been a coincidence that the charger blew just then.
Is the cooling sorted? Which temperatures are reported? Though I do remember they have internal over temp protection

Cooling was fine I think, I touched it a bunch afterwards and the gearbox/inverter were warm from the drive, charger not really. I agree, it might be a coincidence, but it dropped out just as I pressed enter.

What else should I capture when I run my stress test? What plot would be helpful additionally to a CAN capture?
I will try a few firmwares and settings, let's see where I get to.

I wonder if the change while charging caused a transient surge that killed it. I don’t think changing parameters while charging is something that would typically be expected to occur in the OEM setting. I doubt Tesla would have built in any safety to prevent that at the module level.

janosch wrote: ↑Mon Mar 28, 2022 7:44 pm Cooling was fine I think, I touched it a bunch afterwards and the gearbox/inverter were warm from the drive, charger not really. I agree, it might be a coincidence, but it dropped out just as I pressed enter.

Since CAN is pretty much the only data source and sink, everything should be visible on the log. Maybe to facilitate diagnosis you could plot cXiac and cXidc to see if there are any transients on there.

Also try manually ramping with the smallest possible steps in iaclim and do the step afterwards.

jon volk wrote: ↑Mon Mar 28, 2022 8:26 pm I wonder if the change while charging caused a transient surge that killed it. I don’t think changing parameters while charging is something that would typically be expected to occur in the OEM setting. I doubt Tesla would have built in any safety to prevent that at the module level.

Mhhh i think that they would if you take into account that the module is used in fast chargers and those kinda need tobe rock solid and maybe power demand driven..

Ok, good news is I wasn't able to break it by changing these variables mid-charge
Bad news for me is that I am still trying to figure out how I broke the chargers

Now two dumps are attached below, I don't know the charger internals I am looking for, can someone see if there are signs of spikes in Amps or tell me how to look for them?

• Firmwares: 1.06.R and 1.10.R (w/ rescaling of hwaclim)
• EVSE: granny lead, 12.5A AC
• TSLA: 1 charger module activated
• Variables: iaclim, idcspnt changed between 2-30A various times
• Pack: ~380V 24kWh (on bench)
• Cooling: none (on bench)

Edit: Ok, there is info on this in the development videos and the early firmwares, I am working my way through that, but any hints for CAN IDs and bytes are appreciated:
one two three four fivegit

Ok, I am digging into CAN today, but I suspect I won't find anything.

I wonder if I had a bad connection on the DC side, which made the charger see less than 200V for a brief moment, making it self-destruct.

1) I could parse the charger messages in my VCU (using chademo.h), and if udc is < 250V disable the charger, hoping it doesn't self destruct, this would take some time for the system to react
2) Any chance for a udcmin param like in the inverter?

We will replace the custom connectors as well just in case.

Now typing it out, if the control board just works via CAN, maybe the time to switch it off like that is the same for VCU or Charger board.

Edit: Although, if connection was bad -> high resistance -> cable getting hot -> I should have found burn marks

The charger doesn't self-destruct because of low voltage but because of high current. 3.7 kW (per module) is 10.5A@350V but 18.5A@200V. That's the part it doesn't like.

Yes, of course, Amps destroy it when trying to charge at low voltage.

Now, I parsed & plotted the messages the charger sends.

Working Broken Some thoughts:
- Nice to see: AC voltage drop from 240 to 226 as soon as there is a load (expected)
- BMS reports ~6 Amps (8A - ~2A noise in the data). The individual phase only reports ~2A, so is it charging on all phases? So odd! I need to set it up again and check chargena. My understanding is that 22B, 229, 227 report dc voltage and dc current for the three phases, I would have expected one of them to match the BMS and the other two to be zero.
- I can't actually tell from the CAN messages what is limiting the broken charger: hwaclim in 209, 20B and 207 looks good to me in the broken log as well?
- the idc_bms noise changes at some point in the broken version, I wonder why.

Maybe I will look very stupid here soon, but I can't figure out why yet!

Edit: Another one, this is where I changed the setpoint a few times during charge (idc going up and down visible). In this one I only had messages from one phase as I expected before.

changing current limits

et0 wrote: ↑Wed Mar 16, 2022 10:18 pm

johu wrote: ↑Wed Mar 16, 2022 6:19 pm oh, now I get it!
Alright, that of course requires a relay. So it breaks the connection to L2 and makes the connection to L1 on the second module. One way to find out would be a 32A CP current limit but only AC voltage visible on the first charger module. I think there's an open collector output left.

There's a few different ways to do it! The simplest, I think, is to route L1 to all 3 modules by default (for single phase operation) - that can be done with a single DPDT relay. Then the charger works in single phase mode as normal, so CP current limit divided by 3 to each module.

This relay can be energised by the voltage between phase 1 and 2, now it sends L1, L2 L3 to module 1, 2, 3. This detection can also feed an *input* on the charger, and all that does is change the flag to 3 phase mode.

On that link is a nice schematic - I have done it slightly different because of the choice of relays available, but it's same idea.

If you implement it I will test it

This thread kinda got side swiped, is there any update on implementing this function in the firmware ?

johu wrote: ↑Wed Mar 16, 2022 6:19 pm oh, now I get it!
Alright, that of course requires a relay. So it breaks the connection to L2 and makes the connection to L1 on the second module. One way to find out would be a 32A CP current limit but only AC voltage visible on the first charger module. I think there's an open collector output left.

Hi J

I just got a Gen2 charger. I am waiting on Damiens V5 board and i am wondering on how to improve already good product .

Now i am using 3x chargers that i run over CAN bus. I can cycle them via different CAN addresses via single button + 3 LED interface.
I need that to avoid overloading my home power in case there would be other load(s) on some phases.
Is simple and it has visual feedback on charger operation.
https://leafdriveblog.wordpress.com/202 ... -chargers/

Would something similar be possible with CAN interface for your firmware? A byte inside CAN ID 0x102 that would mark which module to use. Not dissimilar from wifi interface .

Alright, now back to the phase switching topic. I'm still trying to understand what to implement, if anything.

So I take it the charger should be enabled to charge from 3x16A or 1x32A without user interaction. In the latter case a relay connects the first phase to all (or just 2) charger modules. The relay is switched by L2 or L3, so the NC contacts would connect the first phase to modules 1-3 while to NO contacts connect L1-L3 straight through to modules 1-3.

In the 3-phase case we get a 16A current limit via CP and in the 1-phase case we get a 32A limit.
So now we need the software to automatically toggle between Type2-3p and Type2 depending on the vacant digital input. Right?

Ok, lets just try that.

The second digital input now decides between 1-phase or 3-phase operation. Pull it high for 3-phase AND set inputype to "Type2-Auto"

johu wrote: ↑Mon May 09, 2022 3:54 pm Alright, now back to the phase switching topic. I'm still trying to understand what to implement, if anything.

So I take it the charger should be enabled to charge from 3x16A or 1x32A without user interaction. In the latter case a relay connects the first phase to all (or just 2) charger modules. The relay is switched by L2 or L3, so the NC contacts would connect the first phase to modules 1-3 while to NO contacts connect L1-L3 straight through to modules 1-3.

Correct.
Relay off: L1 goes to all modules
Relay energised: L1, L2, L3 goes to module 1, 2, 3.

In the 3-phase case we get a 16A current limit via CP and in the 1-phase case we get a 32A limit.
So now we need the software to automatically toggle between Type2-3p and Type2 depending on the vacant digital input. Right?

edit: correct, and I see you implemented it while I was typing. Thanks!

I think I found a bug in the later firmware versions. As soon as you save the parameters to flash it seems the CAN map is lost on the next reboot. Will investigate this. If in doubt, type into the custom command field and send it. This should yield a long output above the parameter table. If not, type send it and save to flash. Then restart the charger. That gets you the CAN mapping back.

Yes, that was my problem. All chargers are charging again! Updated the Common Issues section in the wiki: https://openinverter.org/wiki/Tesla_Mod ... mon_Issues

You didn't think we just did CHAdeMO while I was over at Janosch?

Of course not. Also worked on the Tesla charger code until it yielded good results. As always, more testing, more better.

et0 wrote: ↑Wed Mar 16, 2022 10:18 pm
There's a few different ways to do it! The simplest, I think, is to route L1 to all 3 modules by default (for single phase operation) - that can be done with a single DPDT relay. Then the charger works in single phase mode as normal, so CP current limit divided by 3 to each module.

This relay can be energised by the voltage between phase 1 and 2, now it sends L1, L2 L3 to module 1, 2, 3. This detection can also feed an *input* on the charger, and all that does is change the flag to 3 phase mode.

On that link is a nice schematic - I have done it slightly different because of the choice of relays available, but it's same idea.

If you implement it I will test it

Just saw this post, never to late
Can confirm that this has worked for long time now, can plug in to 1phase and 3phase, and have full power at 16A 3phase.

I use this setup and sofware change:
https://openinverter.org/forum/viewtopi ... 761#p10912

johu wrote: ↑Tue Jul 05, 2022 7:56 pm You didn't think we just did CHAdeMO while I was over at Janosch?

Of course not. Also worked on the Tesla charger code until it yielded good results. As always, more testing, more better.

Can you post hex file as well?

Tnx

arber333 wrote: ↑Wed Jul 06, 2022 10:08 pm Can you post hex file as well?

Yes, added to post above

johu wrote: ↑Tue Jul 05, 2022 7:56 pm You didn't think we just did CHAdeMO while I was over at Janosch?

Of course not. Also worked on the Tesla charger code until it yielded good results. As always, more testing, more better.

Curious, what did you change? Mine has been working great here at home

Bryson wrote: ↑Thu Jul 07, 2022 3:27 pm Curious, what did you change? Mine has been working great here at home

It's kind of scattered along the thread here. It has the digital input for signalling 3-phase availability, it's got a new CAN module which improves accuracy, it no longer forget CAN messages (a bug that was introduced after the official release), charge current calculation in 1-phase mode was fixed and finally a parameter was introduced that lets you delay the start of the charge.

So if you don't need any of the new features and yours runs fine, you can skip the update

johu wrote: ↑Thu Jul 07, 2022 4:32 pm

Bryson wrote: ↑Thu Jul 07, 2022 3:27 pm Curious, what did you change? Mine has been working great here at home

It's kind of scattered along the thread here. It has the digital input for signalling 3-phase availability, it's got a new CAN module which improves accuracy, it no longer forget CAN messages (a bug that was introduced after the official release), charge current calculation in 1-phase mode was fixed and finally a parameter was introduced that lets you delay the start of the charge.

So if you don't need any of the new features and yours runs fine, you can skip the update

Hi Johannes, finally getting to try out this update - if you remember I needed the auto 3-phase capability (thank you for adding it!) and I also want to use CANBUS to control the charger (so, J1772 wires not connected to the charger).

The charger works, stand-alone, with cancontrol off and J1772 wires connected.

However I have no success getting the CANBUS messages to have any effect. On my Candaptor I can see messages from the charger, and from the BMS (my 0x102 message, sent at 100ms interval).

On the charger I have cancontrol on, enablepol high, and the enable pin is pulled high.
I have the termination link closed (it is at the end of the line). The total can resistance is 60R

On the web interface it shows canenable=0, enable=0, state=off. Nothing happens.

How can I debug this please?