Power Electronics Development Center
hardware trigger ADC
Hey evryone
I have a question related to hardware trigger in FPGA. What Im trying to implement here is I want to have my ADC channel triggered by my pwm signal. In some other micro processor like TI dsp or Dspace this function is already in-build in their ADC settings
So what I did in FPGA is I used a control variable a,b,c to trigger the case structure. When the control is true, the ADC sampled the signal, when the control is false, the case is do nothing
as shown in picture
My pwm frequency is set to be 10khz and the while loop is also set as 4000 counts(10khz)
But the problem is that after I plot what I sampled, it seems like the ADC and the pwm is not always synchronous. Means, sometime I got the right results, sometime (to me its totally random)
So could somebody help me out with this?
Thank you
Regards
jia
Great question. This technique, commonly called synchronous sampling, is popular in applications in which the goal is to regulate the current sensed at the output of the inverter half bridges, before a line reactor filter, because it provides average current and the current is sampled in between switching events which minimizes the impact of radiated and conducted emissions on the sampled signals.
The downside is that it limits your sampling rate to 2X the switching carrier frequency. I recommend running the analog to digital converter at its maximum sampling rate (i.e. 115 kS/s or 8.7 microseconds). This is critical for overcurrent protection on the IGBT half bridges. Generally speaking you have about 10 microseconds to trip off the inverter if current goes over the limit in order to protect the IGBTs from damage. Therefore, you want to sample the analog inputs, check for overcurrent, and disable PWM as fast as possible. If you do, the FPGA will provide exceptional protection for the IGBTs.
Here is a diagram I drew to help explains how synchronous sampling works. The upper switch is turned on whenever the Control waveform is greater than the Triangle waveform. The Sample Clock signal is True whenever the Triangle waveform is counting up (positive slope) and is False whenever the Triangle waveform is counting down (negative slope). The simultaneous analog input waveforms, including Current, are sampled on the rising and falling edge of the Sample Clock signal. If you follow a line upward from the rising and falling edge of Sample Clock, you will find the Sample instances (indicated by the + symbols on the drawing). Note that since the Current waveform is triangular in shape (trapezoidal), taking the measurements at these Sample instances automatically gives the average current in each half cycle. Current waveforms are triangular if the load is inductive (di/dt = V/L). Also note that the samples are always taken mid-way between switching events (the turn on and turn off of the switches). This is good for EMC immunity. The lower switch state is not drawn but is assumed to be complementary (always the opposite state compared to the top switch) before deadtime compensation.
Synchronous sampling can be achieved easily in LabVIEW FPGA by creating a "Sample Clock" Boolean output from your triangle generation algorithm that toggles whenever the triangle generate switches from counting up to counting down. Then use the rising and falling edges of the Sample Clock TRUE/FALSE signal to trigger the sampling and control algorithm execution. Here is an example of a floating point triangle generator that produces a Synchronous Sample Clock signal, as well as a fixed point version. Both are intended for use inside a single cycle timed loop (SCTL) running at 40 MHz (resulting in 25 nanosecond resolution in the case of the fixed point triangle generator and 50 nanosecond resolution in the case of the floating point triangle generator due to a once cycle latency (L1) in the math operators).
The IP cores shown above are located in the power electronics master IP library here:
C:\LabVIEW 2015\IP Cores\IP Cores - LabVIEW FPGA\Control & Signal Gen\[FPGA] Float TriangleGen (use inside SCTL).vi
C:\LabVIEW 2015\IP Cores\IP Cores - LabVIEW FPGA\Control & Signal Gen\[FPGA] FXPT TriangleGen (use inside SCTL) .vi
Then there is the question of how to trigger the simultaneous analog input on the GPIC? To do so, add a single-cycle timed loop (SCTL) that waits for either the rising or falling edge of the Sample Clock signal. To ensure that the I/O node does not execute until this edge trigger occurs, include the error cluster for the I/O node inside the SCTL, so it will only be passed out after the SCTL exits. The code is shown below. Note however, that I actually don't recommend programming it this way because it slows down all 16 channels to 2 times the carrier frequency. I'll explain more below.
Important: You should read all simultaneous analog inputs of the GPIC using a single I/O node. That is because the ADC is a shared resource and sampling should only be performed at a single rate for all 16 channels.
Note however, that I actually don't recommend programming it as shown above because it slows down all 16 channels to 2 times the carrier frequency, fc [Hz]. This in turn limits the loop rate of all the control loops in the application to 2*fc. If you are ONLY controlling the phase current and you have independent overcurrent protection circuitry (i.e. analog comparators on your interface board), that would be okay, but most applications for which I consult involve controlling voltage, current and power factor after a line reactor filter such as in field oriented control where we regulate real and reactive power or power factor. These control loops definitely benefit from higher bandwidth control loops in my experience.
In general, running control loops faster typically makes them easier to tune and more robust against disturbances. As a rule of thumb, I want to sample the analog inputs and run the control loops about 100X faster than the gain crossover frequency of the physical system open loop gain. That's the frequency at which the open loop system has a gain of 1, or 0 dB. (For this gain crossover frequency calculation, set the control algorithm tuning so it has a gain of 1.) This is illustrated below.
The gain crossover frequency is a measure of the actuator and plant bandwidth. It is the frequency at which the stimulus (blue sinewave) and response (red sinewave) have the same gain and so it is also known as the unity gain frequency or the phase margin frequency (P.M. frequency).
The open loop transfer function, L(s), for a typical power converter, ignoring disturbance Eo(s), is shown below. More details. The important observation here is that the loop gain crossover frequency depends on the control algorithm (i.e. PID tuning gains), the actuator gain (i.e. the voltage produced for a given modulation index depends on the DC link voltage), and the plant gain (i.e. line reactor filter attenuation and transformer turns ratio).
Note that this also means that increasing the DC link voltage, V_DC, results in a higher bandwidth system and therefore a faster control loop rate. Since the DC link voltage also impacts the gain of the control system, and since it's easily measured, I like to account for it in my control algorithms. In this way, the tuning of my control loops is independent of the DC link voltage. This has many advantages, such as the ability to initially commision the power conversion cabinet at low voltage (i.e 48 VAC) using a variac and tune the control loops, and then bring it up to full power with minimal changes needed to the control system tuning.
So what is the average output voltage of a half-bridge inverter phase, V_out
V_out
Recommendation: For graphing the response of your GPIC inverter waveforms, don't display the control waveforms in their unitless format. Instead, use the formula above to scale the control waveforms to the expected inverter phase voltage output, V_out, in volts using the equation above. That way you can display the grid voltages on the same chart any easily tell which direction power should be flowing. If V_out is greater than V_grid then you expect power to flow out of the inverter to the grid, thereby discharging the DC link capacitors and producing a positive RMS current. If V_out is less than V_grid then you expect power to flow from the grid to the inverter, thereby charging the DC link capacitors and producing a negative RMS current. If the amplitude of V_out and V_grid are the same, then you can eyeball the direction of power flow based on the phase relationships.
Let's also look at the phase response of the loop gain transfer function, L(s), and how it impacts the stability of the control system. The loop gain must be less than 1 if the phase is less than -180 degrees because at these frequencies the system has positive feedback rather than negative feedback. You must execute the control algorithms fast enough to control the frequency response of the system all the way to the point at which the phase of the loop gain transfer function reaches -180 degrees (the frequency at which the gain margin is measured) and beyond.
The actual loop gain frequency response for a typical second order physical system (without controller) is shown below. The gain crossover frequency for the physical system by itself is 847 Hz.
The loop gain frequency response for the second order system and PID controller is the sum of the two individual responses, as shown below. The gain crossover frequency for the combined control system and physical system is 4282 Hz. Note that this is much higher than the gain crossover frequency of the physical system by itself (847 Hz).
The key point here is this. When you tune the control loops, you tend to increase rather than decrease the gain crossover frequency of the system. Another way to think about this is that you are generally making the system higher performance by closing the loop-- not lower performance. Therefore, the bandwidth of the system is increased by your control algorithm. This is illustrated below.
This is often a problem for traditional DSP and microprocessor control systems, where there is a lot of code competing for the processor or DSP core which is a shared resource. If the control loops cannot run fast enough to control the frequency response, the only solution is to "detune" the control system (use small gains) in an attempt to reduce the bandwidth of the system so that it is sufficiently slow that the control algorithm can control the frequency response. This results in poor setpoint tracking, poor disturbance rejection, and overall poor performance. Using traditional DSPs, you might not be able to achieve higher bandwidth control because of the performance limitations of the DSP(s). This tends to creep up later in the development cycle when more code is added, that must run sequentially with the control loops. The DSP tends to be a bottleneck and as you add more control code it slows down.
That's in contrast to FPGA based control where everything can run in a true hardware parallel fashion when programmed properly. With the sbRIO-9607 GPIC, you have 220 DSP cores embedded in a sea of reconfigurable computing fabric. Essentially, the FPGA ate the DSP cores and the microprocessors and they are now contained in a single integrated circuit, which I call a Reconfigurable System-On-a-Chip (RSOC). See the diagram below. It is the ultimate high performance, parallel hardware accelerated control platform for power electronics.
RSOCs also deliver roughly 70 times higher performance per dollar compared to traditional monolithic DSP chips. That's because packed 220 miniature DSP cores into a single integrated circuit (i.e. Zynq 7020) and then mass producing and selling that chip in lots of industries and applications results in great economies of scale and savings in manufacturing cost. The great thing about it is that we all benefit from higher performance control, and so control systems built using RSOCs can deliver 70 times more value to the end customer than those built using traditional chipsets. They are also more fun and productive to program using floating point math algorithms.
For commentary on the benefits of FPGA based power electronics control from an engineer who spent most of his career dealing with traditional DSPs, see the link below.
Feedback from Eaton Corporation Lead Engineer for Power Systems & Architectures,Yakov Familiant
So, I always run the simultaneous analog input on the GPIC at 115 kHz, which is the fastest rate it can run. This enables me to run my control loops at whatever rate (up to 115 kHz) makes sense based on the system I'm controlling. It also enables me to filter the signals at 115 kHz, which allows me to digitally remove harmonics from the waveforms very effectively if needed. Furthermore, it is fast enough that performing overcurrent protection in the FPGA control application is extremely effective, which keeps the IGBTs within their safe operating regions and avoiding damage. (Psychologically, a big benefit is that having such fast protection in the FPGA also makes me more free to test my control code without being afraid of damaging anything.)
You can still perform synchronous sampling in any of the control loops that you want to using the technique shown below. The phase currents, phase voltages, and DC link voltage are synchronously sampled from the analog input loop using the Sample Clock signal, meanwhile the analog input loop is run at the full 115 kHz sampling rate enabling me to run other loops including my protection logic up to that rate. Note that the single-cycled timed loop (SCTL) acts as the loop rate timer for the "synchronously sampled" control loop, so there is no other Loop Timer included. There is a tick counter that measures the loop rate, which will be twice the PWM carrier PWM. Also note that there is a feedback node just before the Vabc* cluster, which are the Control waveforms for sine-triangle PWM. This ensures that the Control waveforms are updated immediately with the values calculated from the previous iteration of the loop when the SCTL exits upon the rising or falling edge of the Sample Clock. This creates a zero-order hold delay which ensures that the Control waveform is updated at a specific instance in the PWM cycle, and eliminates any variations in the execution rate of the floating point control algorithms that result from the sharing of floating point operators. This ensures that the updating of the Control waveforms is completely deterministic and only happens twice per PWM cycle with a half cycle of delay. In other words, the sampling and transport delay time, Td, for the control loop in the loop gain equation, L(s), above is 0.5/fc where fc is the PWM carrier frequency in Hz.
Note that in the code below which goes with the "synchronously sampled" control loop above, the PWM outputs are disabled (set to False) just 50 nanoseconds after a fault such as I, V Limit? is asserted. That's because it takes one 25 nanosecond clock tick to read and handle the fault in the 40 MHz Fault Handling Loop, which then asserts the Fault boolean, and then another 25 nanoseconds for the 3-Phase AFE Sine-Triangle PWM loop to respond and disable PWM. This ultra-fast fault response capability is a tremendous advantage in practice, so be sure to write your application in a way that enables it. In other words, don't do anything that slows down your analog input sampling rate, the checking for overcurrent, the fault handling, or the disabling of pulse width modulation.
Important: Run the analog input at 115 kHz (8.7 microseconds) and don't put anything un-necessary in the analog input loop that can slow it down. Take advantage of the hardware parallelism of the FPGA to provide the fastest fault handling and control loop rate performance you can.
The code above is in the master IP and examples library here:
C:\LabVIEW 2015\GPIC\GPIC Grid Active Front End\NI GPIC Grid Active Front End.lvproj
