openinverter forum

Bigpie wrote: ↑Fri Sep 02, 2022 12:12 pm Does it require a specific version of Qt? Bit of a Qt noob, not able to get it to compile on Qt 6.3.1 for macOS, I've installed the Charts package with the maintenance tool. Googling isn't brining up much of use.

Code: Select all

error: unknown type name 'QT_CHARTS_USE_NAMESPACE'
error: no viable conversion from 'int' to 'Qt::WindowFlags' (aka 'QFlags<Qt::WindowType>') 

No expert myself!

I am using an old version though so possibly. The charting bit of it is based on the zoomlinechart example which should have been installed with Qt, could you see if that will build and run?

Looks like QT_CHARTS_USE_NAMESPACE in the chart.h file needs changing to QT_USE_NAMESPACE in 6.3.

Looks like this is no longer valid. To Up and running now, looking forward to having a play with it later

*EDIT* This is well cool Nice work

Thanks, hope it's useful!

Just bear in mind that the MTPA side of the simulation may still need a little work before it can be trusted! (it comes up with some very optimistic (probably unrealistic!) torque figures - or at least it did with the original OpenInverter Mtpa() implementation, it may be better now?)

While I don't have any OpenInverter hardware I've realised that the STM Nucleo-64 eval boards that I do have can probably be persuaded to do the job.

I've got the compiler installed, source code compiling, the Code::Block IDE installed and the debugger working so I'm going to have a go at getting the standard OpenInverter code to work on one. If that works I'll have a play with the interrupts to see what might be possible.

I found the IO mapping on the Nucleo board causes problems with the OpenInverter code. The STM32 Bluepill boards which can be found on eBay etc are supported by the standard firmware and can be build up on a breadboard. This is what I use to benchtest firmware builds.

davefiddes wrote: ↑Sat Sep 03, 2022 2:19 pm I found the IO mapping on the Nucleo board causes problems with the OpenInverter code. The STM32 Bluepill boards which can be found on eBay etc are supported by the standard firmware and can be build up on a breadboard. This is what I use to benchtest firmware builds.

I'm finding the same

I can either get it to go into manual run mode and then hit the tim1_brk_isr() or just refuse to go into run mode altogether depending on which pins I try to pull high.

Did you get anywhere figuring out where the problem was? I'd rather stick with this board if I can as I have it available here and now, moving to a bluepill will take a few days to get here.

Edit - The nucleo is also fairly convenient with the integrated debugger and comm port!

I think it was going to require a huge set of IO remappings at least as big as the bluepill support which is sprinkled liberally through the codebase as it is. There may have been a show stopper conflict but I've forgotten the details. Sorry.

No problem and thanks for the reply. I don't want to actually use it properly, just getting a PWM output in run mode would do, even in manual mode would probably be enough - so hopefully a reduced set of pins to sort out.

Some progress, It's now generating pwm outputs in manual mode with timer break ISR disabled so I assume it's the break input pin that is the main problem. Just trying to figure out which pin this maps to in v1 hardware now (as that's what it seems to think it is).

Edit - PB12, was reading the schematic wrong, pulling low disables it and it runs with the ISR enabled again!

Very good, I also think you just need a small subset of pins.
Re compiled in simulator: not sure if that is worth the effort as you loose all the real behaviour of ADC, the low pass filters and so on.

Also tried your simulator last night and after making Jamies mod it ran like a boss Didn't even add the extra parameters so it's probably meaningless but I can now start playing with it anyhow. Many thumbs up to you

johu wrote: ↑Sat Sep 03, 2022 4:08 pm Very good, I also think you just need a small subset of pins.
Re compiled in simulator: not sure if that is worth the effort as you loose all the real behaviour of ADC, the low pass filters and so on.

Is there any trick to getting the digital outputs to work from your code. I've tried both direct CM3 function calls and going through the digio class (adding test4_out to the DIG_IO_LIST) but can't get either to do anything useful. I'm missing something obvious but can't see what??

Re simulator - True, depends what the goals are, it would make debugging the higher level code on the bench a bit easier but that's about it.

johu wrote: ↑Sat Sep 03, 2022 4:08 pm Also tried your simulator last night and after making Jamies mod it ran like a boss Didn't even add the extra parameters so it's probably meaningless but I can now start playing with it anyhow. Many thumbs up to you

Not sure which OpenInverter code you are using with it but if it's the original it will be using the param_prj.h file in the project directory so will have the right params. If you are trying my revised code you will need to rename the param_prj.h file in the project directory so that instead it uses the one in the stm32-sine/include subdirectory as otherwise it will have the wrong param values. Not a particularly nice way to do it I'll admit but it works.

Ignore the above re the digio - I was trying to use one of the JTAG pins which don't play nice when connected to the debugger! Moved to GPIOB7 and all is good.

Got the Nucleo board working and added some extra output pin writes to the standard code and hooked up the logic analyser to capture the data: The three plots are:

• PWM::Run - Goes high at the start of the PwmGeneration::Run() function and low once the new dutycyle values have been calculated and written.
• PWM - Channel 1 of the PWM output - note this is fixed in the code to 75% to keep the plot stable as it is running open loop and the nurmal dutycycles are all over the place.
• ADC_INJ - This line is toggled when the injected ADC conversions complete (I've added a ISR on the injected conversion completion and added the IO write in there)

So results.

• First the Run() function does start at the centre of the PWM pulse so this agrees with johu's results and gives me confidence I've set it up right!
• The time needed for the Run() function to execute is 32us. It should be possible to optimise this a bit more too.
• The injected conversion completes 64us before the centre of the PWM pulse (49us into the period) as expected.

From this it looks like there is plenty of time to execute the PwmGeneration::Run() before the PWM timer reload if it is started from the ADC injected conversion complete ISR. This will give us a measurement to output latency of under 70us. It would also appear that with a little optimisation it should be possible to get the latency down to nearer 30us, or possibly even less if we trade a little code readability for speed.

Realised that while the way I was hoping to do this will work fine with a PWM frequency of 8.8kHz it will be tricky to get it working at other PWM frequencies.

What are thoughts about restricting the FOC build to 8.8kHz?

Pete9008 wrote: ↑Sun Sep 04, 2022 8:01 am Realised that while the way I was hoping to do this will work fine with a PWM frequency of 8.8kHz it will be tricky to get it working at other PWM frequencies.

What are thoughts about restricting the FOC build to 8.8kHz?

Not possible, e.g. the Prius inverter only runs fine at 4.4 kHz.
Not very happy about trading readability for speed as it would also restrict future development. Maybe fine for testing.

The repetition counter is set up differently:
- 4.4 kHz : ISR called twice per PWM period, once in the beginning, once in the middle
- 8.8 kHz : ISR called once per period, in the middle
- 17.6 kHz: ISR called every other period, presumably in the middle

johu wrote: ↑Sun Sep 04, 2022 8:32 am Not possible, e.g. the Prius inverter only runs fine at 4.4 kHz.
Not very happy about trading readability for speed as it would also restrict future development. Maybe fine for testing.

The repetition counter is set up differently:
- 4.4 kHz : ISR called twice per PWM period, once in the beginning, once in the middle
- 8.8 kHz : ISR called once per period, in the middle
- 17.6 kHz: ISR called every other period, presumably in the middle

Fair enough re readability and freq, will keep it as is. Worth asking though

On the repetition counter thats the issue. Need to have a read of the stm32f1 data sheet to see what might be possible (wondering whether the spare timer channel could be used to trigger the isr at different positions in the pwm period for the different freqs).

Re the hand drawn isr timing sketches above, are you happy with aiming for the second one?

EDIT - does the mk3 prius run ok at 8.8kHz?

johu wrote: ↑Sat Sep 03, 2022 4:08 pm Very good, I also think you just need a small subset of pins.
Re compiled in simulator: not sure if that is worth the effort as you loose all the real behaviour of ADC, the low pass filters and so on.

Couple of other thought re this.

It would probably be worth adding configurable simulation of the low pass filter phase delay into the PC based simulation. Also might be be worth adding configurable noise to the angle and current measurements too so that its impact can be evaluated.

On the stm32-sine integrated simulator it would have the advantage that if you set a breakpoint in the code the simulator would stop too keeping everything in sync.

EDIT - Just reviewed Prius inverter PWM frequencies and it's 4.4kHz (not sure why I had 8.8kHz in my head!). In the process of doing this I have also realised that the support for different inverter frequencies in the simulator is woefully inadequate and needs improving. At the moment it is only the 8.8kHz that is representative (but that's not much use on Prius inverters ).

Ok, bit of a brain dump to try and get thoughts in order. First, this is what I think we should be aiming for: To achieve this the PwnGeneration::Run() function needs to be called earlier than it currently is so that it can have the new dutycyles calculated prior to the timer reload at the mid pulse point. Testing so far indicates that there is a 64us window in which this can be done.

I'm not comfortable running the PwmGeneration::Run() function from the ADC injected conversion complete ISR. This is already slaved from another ISR in code, would add too much dependence on other modules and would also need the resolver timer to be running in all other encoder modes.

There is a spare capture/compare unit on the PWM timer. It should be possible to use this to generate another interrupt at whatever point in the PWM period that we want (and then use this to call PwmGeneration::Run()). The problem is that at higher PWM frequencies there would be multiple interrupts for each control loop execution. I think we can get round this by reading the repetition counter in the ISR to decide whether to call PwmGeneration::Run() to execute the control loop. This still leaves one problem, the Run() function would need to complete within a single PWM period at the highest frequency, or 56us (in order to ensure that we do not start to miss interrupts). This should be possible if some of the slower bits (such as Mtpa()) are moved to the 1/10/100ms tasks.

If done this should get the measurement to output latency down from 180us to around 60us, a factor of three improvement, which will make a big improvement to control loop stability but it's a lot of changes to the codebase.

Is it worth it?

Having thought about it a bit more there is another issue which means it probably is worth it.

If I understand the code correctly the measurement to output delay will vary with PWM frequency at the moment. At the moment the measurement sampling occurs around 60us before the interrupt. In the interrupt the new duty cycles are calculated and then these values take effect at the end of the PWM period.

This means that at 17.6kHz this is 117us (60+56), at 8.8kHz it it is 183us (60+113) and at 4.4kHz it is 286us! (60+226).

Changing to the suggested scheme should keep latency at 60us at all frequencies which will help reduce the effect the PWM frequency has on control loop stability.

Edit - I think the timer might be able to run in double update mode (need to check data sheet for the chip used). If so then that would reduce latencies to 88us, 117us and 183us for the three frequencies.

Edit2 - Having reviewed johu's comments above it looks like the double update mode is already used at 4.4kHz meaning latencies should currently be 117us, 183us and 183us for 17.6, 8.8 and 4.4kHz respectively.

I've realised that the hardware test setup I have can be used to measure the latencies fairly easily. If I use the line that is being toggled in the ADC injected conversion complete ISR as an input and check it to decide whether to output a large or small dutycycle in the PwmGeneration::Run() function I'll be able to measure the latency on the lines already bought out to the scope.

So the plan is:

1. Measure the latencies in the standard code.
2. See what can be done in the firmware to improve them.
3. Once I know what can be achieved update the PC simulator to accurately model it.
4. Use the simulator with the new latencies to see if the control loops can be adjusted to keep things stable under all conditions.

Measurements of the latencies on the original code - not quite what I expected:

17.6kHz PWM: 8.8kHz PWM: 4.4kHz PWM: The 4.4 and 8.8 match calculations but the 17.6kHz is slower - actually the same 180us as the other two. Looks like the timer double update mode is only used at 4.4kHz.

The PwmGeneration::Run() period remains unchanged throughout as expected.

Actually I'm very glad to see this because it is what I expected. The "repetition counter" is set in a way that the ISR frequency stays constant at the 3 selectable PWM frequencies. 0 repetitions mean running the ISR before downcounting AND upcounting (done at 4.4 kHz), 1 repetition means running ISR only before downcounting and 3 repetitions runs one full period and a half without calling the ISR.

So B1 is where the resolver is sampled, A1 is start of ISR and B2 is supposedly the start of the next PWM period. But it isn't because it is center aligned. So it actually starts midway between the negedge of the last period and the posedge of the next. So I'm assuming the real latency is exactly one PWM period.

I'd summarize the following learnings:

• ISR is called in the middle of the period
• When currents are sampled right at the start of the period they should be mostly noise-free because in most cases no switching takes place here
• As expected delay between sampling resolver and calling ISR is 113-40=73us.
• Taking too many current samples from the past increases latency and probably affects control loop stability
• syncadv needs to compensate delay between resolver sampling and current sampling, so something less than 73us
• field weakening current should be determined from distance of total amplitude to maximum possible amplitude
• User current request must be limited to allow field weakening - also determined like FW current?

I'd try to throw this into the software, the last 2 points into SetTorquePercent() which runs every 10ms

johu wrote: ↑Mon Sep 05, 2022 9:22 am So B1 is where the resolver is sampled, A1 is start of ISR and B2 is supposedly the start of the next PWM period.

Should have said that A2 and B2 are on top of each other on the plot which hides A2. A1 - A2 is the ISR period.
B2 is the equivalent of A1 (start of the ISR) but for the next cycle.

johu wrote: ↑Mon Sep 05, 2022 9:22 am But it isn't because it is center aligned. So it actually starts midway between the negedge of the last period and the posedge of the next. So I'm assuming the real latency is exactly one PWM period.

You've lost me there, could you explain a little more?

I'm treating latency as from the measurement to the point where the output action actually takes affect, isn't that at B2?

Pete9008 wrote: ↑Mon Sep 05, 2022 9:39 am You've lost me there, could you explain a little more?

I'm treating latency as from the measurement to the point where the output action actually takes affect, isn't that at B2?

Yes, look here: So one period isn't just "on" and then "off" but "off", "on", "off". Since the trailing "off" continues into the leading "off" of the next period you can't determine the start of the period from the edge off the PWM signal, unless you set it to a very high duty cycle.