openinverter forum

Hmm, can you spawn an abandoned airfield in my neighborhood, please
Paralleling the PWM channels shouldn't be much of a problem. Your current sensor paralleling strategy sounds interesting. Not sure what exactly is going to happen. It won't be able to detect imbalance so you have to make sure there is none. Otherwise you can just connect one pair of current sensors and double (half) the gain factor.
Current reading happens at control frequency - independent of PWM frequency fixed to 8.8kHz nowadays

johu wrote: ↑Thu Feb 06, 2020 11:33 am Hmm, can you spawn an abandoned airfield in my neighborhood, please
Paralleling the PWM channels shouldn't be much of a problem. Your current sensor paralleling strategy sounds interesting. Not sure what exactly is going to happen. It won't be able to detect imbalance so you have to make sure there is none. Otherwise you can just connect one pair of current sensors and double (half) the gain factor.
Current reading happens at control frequency - independent of PWM frequency fixed to 8.8kHz nowadays

Hmm... I am thinking of using longer phase wires and parallel connect them much closer to motor. I expect this will dampen induction surges and flyback diodes will not be too stressed inside IGBTs.

You can try to find an empty parking lot in a mall on Sunday? But idea is somewhere that you may not expect any traffic... or cops...

One more question J.
Can we use latest FOC code for Leaf motor with encoder ABZ interface? I have installed one ABZ encoder onto motor rear shaft since my resolver is damaged. If its possible to run motor without mechanical changes i would be very happy.

tnx

The first startup could be rough, but theoretically it should work.

johu wrote: ↑Thu Feb 06, 2020 7:59 pm The first startup could be rough, but theoretically it should work.

What do you mean for first setup rough? Why? Isnt ABZ signal pretty much the same as resolver only digital?
Do yopu mean every first start will be rough or just at setup?
Hm... should i then rather try to reinstall resolver?

A

Resolver instantly returns the current, absolute rotor angle. ABZ only returns incremental angle increase and once per rotation the index pulse. Only then do you have an absolute angle. So you're blind on the first turn and can just dump some random sine wave until you see the index pulse. Most of all I haven't tested ABZ mode for ages.
So I'd recommend you try to get the resolver running or use a sin/cos like this: https://www.melexis.com/-/media/files/d ... elexis.pdf with a small magnet as you already know. Of course I don't know if there will be any disturbance by motor stray field.

johu wrote: ↑Sat Feb 08, 2020 10:14 am So I'd recommend you try to get the resolver running or use a sin/cos like this: https://www.melexis.com/-/media/files/d ... elexis.pdf with a small magnet as you already know. Of course I don't know if there will be any disturbance by motor stray field.

What a good idea. I will try to implement it ASAP. I think RLS has just the chip for my form factor.
https://www.rls.si/en/products/rotary-m ... tal-flange

EDIT: So if i would do this with your rev. 2 board i would need the resolver circuit too yes?
I would connect it by Sin and Cos lines and i would leave Ex lines unconnected yes? Also Sin/Cos lines are single ended. That means probably that other side is connected to GNDfor reference. How does that apply to your circuit?
BUT this chip sends ONE sine/cos weave only at single FULL shaft revolution. What does that mean for 8 pole motor like Leaf? Would that be enough?

Yes, no excitation needed, so rev2 board will work. Remove encoder pull-up resistors!
You mean model RMF44AC? That is centered at Vcc/2. Would be perfect if it runs on 3V3. Otherwise you have to divide 2.5->1.65 accurately because there is no offset-calibration in that mode.
One sin/cos per turn is ok, just set respolepairs=1

It says signal is 1.1V each across reference so 2.2V in all. Can you tell me how to connect Sin and Cos signal wires? Do i just connect Sin to encA and Cos to encB? Minus pullups of course...

tnx

Hi,
I'm back with the smart for the week-end, i did the firmware upgrade 4.73,i have a lot more power now but it's too much for the liking of my battery (limited to 350 DC Amps).
Also i now have a HICUROFS2 wich occurs either a high speeds and high load. freezed data shows 294A on il1 an ~195A on il2.
As well as going from positive torque to regen.

I have basically the parameters from the release adapted to my car.

I'm thinking of switching back to 4.54FOC


Paul

Hello, there is a FOC firmware for asynchronous motor

I'm really sorry for the screen flicker, will re-record this when I have the time.

Best explanation of foc I have ever seen. Now I have some hope of understanding:)

Cool, thanks

Observed something interesting yesterday: the car was always "sputtering" at very low rpm which it didn't before. After a while I thought this could be down to a DC offset on the current sensors. So I restarted to recalibrate them, et voilá, sputtering gone. So for now, if you experience that problem, restart. I do consider a recalibration whenever the motor is stationary and no torque is demanded.

johu wrote: ↑Fri May 15, 2020 6:34 am Observed something interesting yesterday: the car was always "sputtering" at very low rpm which it didn't before. After a while I thought this could be down to a DC offset on the current sensors. So I restarted to recalibrate them, et voilá, sputtering gone. So for now, if you experience that problem, restart. I do consider a recalibration whenever the motor is stationary and no torque is demanded.

I noticed Lebowski has an option to calibrate current sensors whenever eRPM fall below certain level. It works better than innitial manual calibration.

How do we recalibrate them on the V3 board ?

They are automatically calibrated when switching from stop to run. If they develop a DC offset while being in run, that is not currently compensated.

johu wrote: ↑Fri May 15, 2020 11:10 am They are automatically calibrated when switching from stop to run. If they develop a DC offset while being in run, that is not currently compensated.

Why do you think they would develop offset? You think because of heat or other things?
I think you need to pull down on the signal with something like 4K7 just after the connector. Maybe it will compensate everytime when in the middle.

Yes they are pulled down by the mainboard resistive divider, so 3k3+4k7. Offset could be caused by slight variation in supply voltage and sometimes magnetic creepage. Though I think the latter rather happens with DC currents. My BMS calibrates and startup and shows exactly 0.0A. Then after a while of charging, when you stop charging it displays 0.5A and slowly creeps back towards 0 within hours.

johu wrote: ↑Fri May 15, 2020 1:01 pm My BMS calibrates and startup and shows exactly 0.0A. Then after a while of charging, when you stop charging it displays 0.5A and slowly creeps back towards 0 within hours.

I noticed the same with my EVdash. When I charge it is measuring energy, but with different temperatures I need to have a full limit so it jumps to 100 when at certain SOC.
this works really well but if I drive very partially sometimes SOC would drift and when charging it may jump from 88% to full.

The recent OpenInverter FOC Tuning video (which is very helpful)



discusses a notch type curve. I think it might be a curve a bit like what i have sketched below. Wonder what other folk think.

I only show it because perhaps it will be helpful for discussion.

I think curves might be closer to this one...

I prefer the original representation of SO v RPM, especially since it uses scales but not numbers. Given how easily folks misunderstand what the goal is, I believe the less numerical specificity of the concept, the better.

I guess you use what is best for you.