Recurrent OC issue while driving [SOLVED]

[arber333]

Recently i noticed an unsettling event while driving my Mazda in winter.
While at slow speed and/or in a stop with throttle released i frequently get an OC limit error and inverter stops. I can reset it immediately though even if car and motor are at RPM. After some experimenting i discovered more details.
1. This only happens at low speed or at a stop light.
2. Also this happens while throttle is released or if i just released car from braking.
3. This happens with certainty if the car was kept in cold place (parking outside)

Quriously this does not happen if i apply BMS pin and limit regen to 0 and torque to 75%.
This never happens at high speeds.

Resulting error is allways "overcurrent".

Did someone noticed such behaviour? I am concerned that now at sub 0 deg is having an influence on comparator chips inside inverter. But i know i used ones rated to -40deg.
I thought of using a 230V PTC heater wired after main contactor to heat up the circuits inside inverter. Hm... 60W light bulb inside would be enough, but for vibration.

[johu]

I experience something similar in Polo (Rev 1 board). It also seems connected to cold temperatures. When powering up the first time it stop with over current once the car moves by itself or you give it a little throttle. It is accompanied by a high frequency sound from the motor.
I thought it had something to do with single channel encoder code but then you use AB encoder...

For me it never happens on consecutive startups.

[doobedoobedo]

How cold is cold? (in C) What people consider cold varies according to the climate they live in.

[arber333]

Cold is below 0deg C. Maybe - 3deg.

I noticed when I stop (motor at still) RPM needle would shimmer some. Would that be pwm output interfering with other inputs.

A

[johu]

Yes, below 0°C for me as well.
When motor is stopped there is no PWM. Must be something else.

[doobedoobedo]

Thanks. So not spectacularly cold then (from my perspecive).

[nailgg]

Can you monitor the speed with a data logger? Is there any spike?

I had a similar issue too. Nothing was happening at high RPMs, even at full throttle. But it was tripping at very low speeds. Later I found that it was my encoder (US Digital E6-512-984-NE-S-D-D-B).

Inside the encoder, there is a nylon disk (photo attached). It was directly coupled to the rotor shaft. Turns out that the encoder cannot go above 80+ degrees. The disk curled a bit due to the heat from the motor and after curling, due to the friction between the optical sensor and the disk, some lines on the disk were removed. As a result, it was reading momentary but huge speed spikes. Like 6500 RPM instead of 500 RPM. So I replaced the encoder and coupled the new one with a different coupler, no issues so far.

[joromy]

I had similar problems when I tested the inverter not enclosed.
It went away when I put it inside the eclosure (100% air tight)

I think this was caused by condensation.
I also have conformal coating on the board.

[arber333]

I had similar problems when I tested the inverter not enclosed.
It went away when I put it inside the eclosure (100% air tight)

I think this was caused by condensation.
I also have conformal coating on the board.

I have inverter enclosed but not airtight. I think you have a point. After 2 years now i didnt touch it, havent even opened a lid.
I will take some time to resolder board and elements and clean afterwards with Nitro. Then i will do what you suggest and paint it over.
I will report back when i am that far...

I still dont understand why problem goes away if i apply BMS pin and limit regen. If the problem is condensation there shouldnt be any difference.

tnx

[johu]

Hmm, my board isn't coated either.
I think Nail has a good point with the encoder. Mine is very exposed so maybe condensation makes it read funny pulses?

[arber333]

Yes, but my sensor is totaly enclosed and is automotive inductive sensor. This should mean it gets funny ticks only after signal enters the main board.
I also remember i put a diode from reverse pin towards reverse switch to keep reverse light from activating if i intentionaly activate BMS pin. Could that diode cause some problems? It is just to keep electrons flowing towards the main board not in reverse.

[nailgg]

Yes, but my sensor is totaly enclosed and is automotive inductive sensor. This should mean it gets funny ticks only after signal enters the main board.
I also remember i put a diode from reverse pin towards reverse switch to keep reverse light from activating if i intentionaly activate BMS pin. Could that diode cause some problems? It is just to keep electrons flowing towards the main board not in reverse.

I'm not sure why ocur doesn't trip when BMS input is high or torque is limited some way, but I still recommend you data logging and plotting the speed. At least, it might be a starting point. Low speed overcurrents are likely be caused by incorrect speed reading since the voltage and frequency inverter sends to the motor dramatically increases (say from 30V to 300V, from 25Hz to 250Hz) whenever a speed spike occurs, which would definitely result in an overcurrent.

Sometimes very short spikes cannot be monitored by CAN or UART. While working on the issue, I added a spot value called "maxspd" which keeps the highest RPM the encoder ever read since the inverter power up. Changed the code a bit, like below:

Code: Select all

param_prj.h:
..
VALUE_ENTRY(maxspd,      "rpm",   2044 ) \
..

stm32_sine.cpp:

static void Ms10Task(void)
{
   ..
   ..
   int32_t spd = Encoder::GetSpeed();
   Param::SetInt(Param::speed, spd);
   if (spd > Param::GetInt(Param::maxspd))
   {
	  Param::SetInt(Param::maxspd, spd);
   }

   ..

[arber333]

Well i think root cause of my OClimit trouble was throttle pedal connector, or lacktheroff. There would be short drops of 5V supply to throttle and therefore reference would suffer. There is only so much filtering can save.
When i assembled correct connector for Prius throttle pedal and wired it to my throttle lines OClimit stopped to appeare.

[joromy]

Sometimes very short spikes cannot be monitored by CAN or UART. While working on the issue, I added a spot value called "maxspd" which keeps the highest RPM the encoder ever read since the inverter power up. Changed the code a bit, like below:

It would be nice to have the same on "max current"

I wish I could do changes and addons myself, but have only worked with arduiono IDE.
Have tested the STM32CubeIDE, but it was a little heavy for me.

[nailgg]

Sometimes very short spikes cannot be monitored by CAN or UART. While working on the issue, I added a spot value called "maxspd" which keeps the highest RPM the encoder ever read since the inverter power up. Changed the code a bit, like below:

It would be nice to have the same on "max current"

I wish I could do changes and addons myself, but have only worked with arduiono IDE.
Have tested the STM32CubeIDE, but it was a little heavy for me.

I already did that too on my firmware. The firmware version of my inverter is pretty outdated (before all FOC-related stuff) since it's already stable for my induction motor, but the code for max current is also simple:

pwmgeneration.cpp: ProcessCurrents()

Code: Select all

static s32fp ProcessCurrents()
{
   .. 
   ..
   if (ilMax > Param::Get(Param::maxcur)) {
	   Param::SetFlt(Param::maxcur, ilMax);
   }
   
   return ilMax;
}

param_prj.h:

Code: Select all

..
VALUE_ENTRY(maxcur,      "A",     2043 ) \
..

2043 was empty when I modified my code, you must be careful with that with the most recent software!

[joromy]

I already did that too on my firmware. The firmware version of my inverter is pretty outdated (before all FOC-related stuff) since it's already stable for my induction motor, but the code for max current is also simple:

I have a induction motor to, got problems after updating from 4.12.
Have my own version of hardware.
Have you removed something in your version?
What version is your version based on?
Mind sharing hex/bin files?

[nailgg]

My fw is based on version 4.18R but I have too many custom changes for my particular setup and it might not work well for you. Still attaching the bin/hex files but try it at your own risk!

• Instead of -1/0/+1 on the reverse/neutral/forward direction I also have implemented a "parking brake" direction on dir = -2. Direction selection on "dirmode=0" also behaves differently since I have four modes. Pushing the "forward" button momentarily increases the dir by +1 and "reverse" decreases by -1. My inverter streams the "dir" parameter through CAN so that the parking brake controlling device pulls the brakes when the dir = -2 and releases it when dir > -2. It might not work well with your existing direction knob if you're on dirmode=0.

• Implemented "throtmax" derating based on the SOC obtained by my particular BMS CAN stream. You don't have the same CAN stream so I'm not sure how "throtmax" will work.

• Added a new "cruisenb" mode to the "idlemode=3" parameter that I needed for my particular setup to use it as a hill-holder. It activates when the cruise button is switched on and doesn't deactivate it when the brake is pressed. Only deactivates when the cruise button is switched off.

• Changed the UART baud rate to 38400 and stop bit to 1. You will have to reprogram your ESP8266 or reconfigure your Zigbee if you're using one of these.

• Added "dirrev" parameter. When set to 1 it swaps the V and W phases resulting in reversing the motor direction.

• Added "finalampn" and "finalspnt" spot values. These always show the final "ampnom" and "fslipspnt" values. Needed these while working on the false overcurrent trips because the actual ampnom and fslipspnt wouldn't show the actual (derated) values when the current limit kicks in.

• Added "maxcur" and "maxspd" spot values. Shows the peak values since the inverter is powered up.
  
  and even more changes. I unfortunately don't have the time to revert all the changes except for the ones that you need since I currently don't have the possibility to test the firmware. So if you are sure you won't blow up your inverter, here are the binaries

[joromy]

Thanks will give it a try. Give you some feedback, later.....