I am not an expert in PCB design so please take my input with caution, or just ignore it.
Have you considered using the combination of
STB60NF06T4
ACS780LLRTR
L6387ED
as a substitute? Especially STB60NF06T4 or STL220N6F7 or alternatively any of the high current automotive grade ST STripFET F7 series have small packages and times in the nanoseconds, which is incredible. Combining two per channel with an L6387ED driver each and one Allegro inline sensor per channel and your problem is solved. I understand the allure of a single package that does everything, however the IFX007T tradeoff here appears to be a deal-breaker. The above combination delivers three orders of magnitude faster response times. 50ns rise/fall will give you comfortably 200ns pulse half-width, or 0.5MHz upper PWM limit before you enter the predominantly linear region of mosfet losses and melt the solder. Plus you donāt want to even be there that high because your board will be lighting up the EMF spectrum like a microwave oven, and the skin effect will probably kill the board anyway.
Itās not the mosfets that are slow. A mosfet is a transistor with isolated gate. So you donāt need current to drive it open, only voltage.
But :
The isolated gate behaves like a capacitor and therefore needs a charge-current to reach the switch-on voltage.
The driver delivers this charge-current. If you limit the charge-current, switching will take longer.
They do this on purpose, because faster switching means more radio-interference.
I am sure that by optimising my PCB design Iād probably have a bit better resuts but I am not sure that Iād be able to have what Iām searching for in terms of low-speed smoothness.
@Jason_Kirsons. Iāve tried removing the resistors and grounding the pin, but it did not help really; Still around 3us on, 3us off time. Could you try the open-loop velocity control under 1rad/s and see if you have a lot of cogging, the behaviour should be as for the gimbal motor, as smooth as it gets
But with a lot of current!
@Jan_Donker, You are right, I agree. I am wondering is that the reason they are not directly putting forward FOC for their BLDC shield with IFX007Ts. They use mostly the block commutation and Back-EMF.
@Valentine I was wondering if you could tes a low spaad <1 rad/s open-loop velocity control. How much cogging do you see? This is a good coging test and it shows directly the problematic in my case.
@runger Iāve tested the open-loop velocity control for a lot fo different PWMs and whant I can tell you is that when I come to the range of sub 5kHz the motor behaves better, less cogging.
Configrming that, for example when I put the voltage limit to 1 volt and test the maximal openl-loop velocity the motors can execute on 5kHz it goes till 60-70rad/s and on 20kHz barely 40 rad/s.
Probably the way to go, even thought this board is suitable for some use cases, so I am a bit confused what to do with it.
You can see that the BTNs have much more irregular PWM signal and that ther have much longer rise time. And in the motor behavior you can see a lot more stalling. Especially for open-loop velocities under 20rad/s there is a large bumping.
Whereas L6234 even though not designed for this kind of motors creates a very smooth operation.
Here, at 1V the current is very low and this is not an issue of the EMI in mu opinion. Maybe I am wrong though.
Do you guys have some suggestions, Iād love to hear them.
That overshoot sure doesnāt look good. Itās as if the device is actively limiting current when it shouldnāt.
But I canāt tell what the cause would be. In electronics, anything is possible. A bad component ( even new component can be bad ), a bad solderjoint ( things go crazy when ground is connected poorly ), your oscilloscope may be fooling you because it is not fast enough. Comparing things with an identical device might give you some clue.
I have scheduled a meeting tomorrow with my hardware engineer. These things usually take time. I will present the problem and he needs to review it. The good news is that since I already have a IFX007T eval board he wonāt need any other help. The bad news is that the board may have to be redesigned. The really bad news is that silicon shortage is a real problem now so just redesigning wonāt do any good if you cannot order the components. Some component lead times are into 2022.
Is it the device or the SimpleFOC current control?
I must admit that I donāt really understand whatās going on thereā¦ as usual I have to think about your answer
are you sure that isnāt a kind of precision issue? In terms of the less cogging, 5kHz should have 4x the resolution of 20kHzā¦ this could be an explanation - because the MCU is able to more finely control the voltages/currents you get less cogging. Especially with a 1V limit on 12V power youāre already working with only 8.3% of the available resolution from the outsetā¦
Does it also go faster if you use a slower MCU or insert some delays in the move loop? Iām not sure how to express this thought well, but if the move loop is too fast compared to the precision, it could be setting new Uq values that get rounded down (due to precision) to the same value as before. So it would be āholding backā the motor instead of āpulling it forwardā by setting the new value. With slower PWM you have more resolution and hence are able to hit the values you need more exactly?
I wonder, could that be a real issue?
And thinking some more on this - another explanation is that this confirms the supposition that the FET switching times need to be significantly lower than the PWM minimum pulse.
When working with the lower end of the resolution, the FET switching times can amount to a significant proportion of the on-time if the FET is slow and the PWM is fast. So that means less power delivered to the motor at higher PWM frequencies - for the same duty cycle.
As this ratio improves, for example by going from 20KHz to 5KHz PWM, the motor gets more power hence you get more speed.
If this is the explanation, then you should presumably see an improvement in speed if you use current control rather than open-loop with the 20KHz PWM.
@Jan_Donker please excuse my imprecise language. When talking about āslowā or āfastā FETs I guess what weāre really referring to somewhat imprecisely and collectively is the whole power stage including the FET-driver (which comes with propagation delays) and possible gate resistors. I.e. how quickly does our PWM signal get translated into the high current version.
@runger thatās exactly what I was thinking. Due to such a long ride time for higher frequecies it generates a lot of noise for low voltage settings 1V or so. And it becomes better for low frequencies since the resolution of the owl as you said is better and slow rise time accounts for less noise. But since the low resistance motors are always going to work with low voltages this noise influences the behavior a lot!
I still have to say that this board works and both in voltage and the current mode i am able to control my motors but i just cannot get the smoothness Iād like to have. The smoothness I get with using drv8302 + power mosfets.
@Jan_Donker I agree that there is something wrong. Iāve got couple of these board from different batches (over the course of few months) so either they are all bad or the chips are ok and itās something else. It can be my board design that is for sure, but again in the videos we are talking about the currents around 2amps which is not enogh to generate any real EM effects.
Yes, a problem with SimpleFOC is that you want everything to be generic, but working with microcontrollers is very hardware-specific. The PWM part of microcontroller manuals is often very long. Say your bus voltage is 24 volts, then at 8 bits PWM resolution 100 mV is the minimum step. In this case you need more than 8 bits. In other cases the PWM-frequency may be too high or too low, depending on the required motorspeed.
I know Infineon from the coolmos ā¢ SMPS controllers. It says in the manual that they have open-loop protection. They just forgot to implement it in the actual device. If there is a failure in the feedback circuit, the thing just blows up.
I spent some time today on this issue. This device cannot be driven effectively over 3kHz. Assuming duty cycle from 10% to 90% (for sinusoidal) at about 10us (at 10kHz) rise+fall you enter the linear region of the device where the dissipation is predominant and most of the energy goes into the heat-sink. Especially if you try really slow rotation or angle-seeking where one of the channels is always held at minimum duty cycle. The 10% safe duty cycle needs 100us width which corresponds to 900us (~1ms) at 90%. That gives you a little over 1kHz. Assume you really push the envelope, and with the minimum slew rate you hit 3us you could triple this to 3kHz before things get dangerous.
This device will be great for low frequencies, high currents and square or trapezoidal wave form. In other words, for e-bikes and scooters, with an added heat-sink.
Yep thatās exactly what I was thinking as well. Which is very unfortunate. It turns out to be too good to be true
Maybe this kind of board would be more interesting with the bemf circuit only and avoid inline current sensing completely. So that people can use it to drive a bit bigger motors without position sensor ( or with hall sensors).
But then again thatās almost exactly the infineonās board.
Here comes the bad news :
It doesnāt work because you have violated several design rules.
1- Timing : the minimum pulse width must be more than 10 times the rise-time of the switches. That means you cannot do low voltages and high speed PWM.
2- Decoupling : the power line should be rock-stable, or you will create an unwanted feedback from the output to the input. That is what is causing your slow rise time. You get 3 microseconds, where the datasheet says the typical rise-time is 0,25 microseconds. The power line should be decoupled by a combination of big enough and fast enough capacitors.
You have neither.
3- Thermal design: There should be a large heatsink on the opposite side of the board and heat should be transferred through thermal viaās. To make room for a heatsink and connectors, you should have designed the board upside down. Making the board stackable is not an option.
I donāt see why current sensing would be impossible ? Just reverse the sign in software when the lower switch is on. You can never have both switches on at the same time.
Hey Jan, thanks for the info and for the bad news. I appreciate the effort.
Exactly thatās the same conclusion we have had so fa, and the problem weāve identified. Even though 10x times seems much better than it turns out to be. For example Iāve had the same issue for low PWM frequency 5kHz.
Guilty. This is a problem. Iāve seen the DC bus voltage to drop in certain moment. Mostly in raise times.
But Iāve got a pretty bid capacitor of 470uF on the board but i donāt have the fast ones itās true. On the other side the voltages Iām testing at thebmoment are not producing a high current so this effect is very low. But again, Iām sure if I add more capacitors to the VSS and better output capacitors Iād better a better behavior but this would still not be good enough in my opinion. It is true that the raise time is 0.25 typically but if you look carefully in the datasheet youāll see that there is the delay time added to it which accounts for the first 20% of the pulse raise period and the typical time is around 3us. So the raise time accounts only for 60% or the raise of the PWM signal actually.
Guilty, but then again, this is a proof of concept design which is not intended to be rock solid in terms of thermal discipation. So is the infineonās board as well for example. They have chosen not to have a heatsink and they are the manufacturer of this chip, they should know better.
Just kidding, thermal discipation is a bug problem and in needs to be addressed properly. For me honestly, stackable shield is much much more important than a heatsink. But that is only mat opinion.
The signal is not just unipolar but is chopped. And itās the high side current sensign so you can only measure something when the high-side is on. But this would work actually, and it does.
The problem comes form the choppedvunipolar signal. You would maybe be able to go around this by figuring out which of the phases is chopped and then using the other two to do the foc if they are not chopped as well. But this is not possible for the full electrical cycle. So I am sure that one could create a more elaborate estimation technique to do this, but for me the simplicity is the number one goal. Very specific and very complicated solution unique for this board is not what Iām searching for.
They said 10% of the minimum pulse-time, not 10% of the PWM period time. That can make a very big difference. They state the minimum and maximum duty cycle for that reason.
Even a proof of concept should work. Otherwise, what would it prove ? And that was not the way it was presented a while ago. If it is almost finished, you donāt need anybodies help, but if it is just an idea youāre playing with, you might.
I donāt think a big enough capacitor would even fit the board, so it would have to be an external one. This tiny thing is just going to explode when a big motor is connected to the board, because of the ripple-current that it is to absorb.
I wonder if it is even a low-ESR type, like it should be. There should be ceramic capacitors close to each of the switches.
I donāt know if there are, for lack a schematic or X-ray vision.
One more thing : big mosfets require large gate-drive currents. So even if you donāt have a big motor attached, you will need this decoupling close to the switches.
Of course the current signal is chopped. Like with any method of measuring current through a switching element.
Now what you are saying is : An arduino Uno cannot handle this, so we will not use this method and just add extra components. But then what is the point of using these Infineon devices or fast-ADC capable microcontrollers ?
Most of the hardware you can buy will have low-side current sensing, so this board would not be an exception if you did.
Thanks Jan, I appreciate your message and your thoughts. However after reading your messages I started feeling really discouraged to continue. So Iām going to stop for some time.
So PowerShield will stay opensource but I will not be continuing the dev.
This board works well, Iāve used with several low resistance motors, but for the reasons of very high rise time+dead time, it does not make sense to continue the effort to make it usable for low speed smooth foc.
But if youāre interested in using it, especially for higher speed velocity control with current sensing the board will work well. And at least youād not have trouble running some pretty powerful motors.
I have the same motors and tested them in PowerShield v0.2. Usually, I set the voltage limit as 2V. In fact, it works well as expected. I will test a low speed <1 rad/s open-loop velocity control.
