LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem in acquiring signals immediately after turning on MOSFET using NI 9402

Hi,

 

I have designed a power cycling test bench using cRIO-9022. Fig 3. below shows the circuit diagram and Fig 4. shows the timing diagram.

okidoki21_0-1718892812487.png  
okidoki21_1-1718892835305.png

 

M_main, M_byp, M_DUT, and M_cur are the MOSFET switches that are turned ON and OFF using driving signals generated from NI-9402, with respective channel numbers and the associated MOSFETs shown below:

Channel MOSFET
0 Main
1 byp
2 DUT
3 cur

 

The switches are turned ON and OFF so as to create temperature cycle the M_DUT. The main program for power cycling is written in RT-Scan interface, whereas, the switching of MOSFETs using NI-9402 is programmed in the FPGA. This is done to allow controlling the delay in switching the MOSFETs in micro-second scale.

 

The program is still not fully complete and I am debugging it step by step. However, I have encountered a problem in a part where I want to acquire the measured signal during transition of states (example: transitioning from State 1 to State 2 in Fig 4.). Below is the explanation of the problem:

 

I have to acquire and log the voltage signal measured using NI-9229 and NI-9239 immediately after switching the MOSFETs. Below is the snapshot of one of the cases.

okidoki21_0-1718898566734.png

Before implementing this part of the code, the measured voltage is X. During this execution, M_main and M_DUT are turned OFF and M_curr is turned ON in the first frame and the measured voltage should change to Y.  In the second frame, I am using NI-9229 and NI-9239 to measure this changed voltage Y. However, the issue that after this transition it still logs the voltage X from the previous iteration and logs this new voltage Y in the next iteration. In general, the data logging is running one iteration behind the switching. From my understanding, it is happening because NI-9402 sends the signals for the new MOSFETs states but the data logging code executes before the MOSFETs actually changed their states. Therefore, the data with new MOSFETs states is logged in the next iteration. I tried to work on this by introducing a milli-second delay (also introduced a delay in the FPGA code), but the problem still persists.

 

I was wondering if anyone can help me. I have attached the LabView code along with the logged data Excel file (cells with undesired data have red colored text). You will notice that this bad data occurs when column 'Condition (0,1,2)' is changing its value from 0 to 1; 1 to 2; and 2 to 0.

 

Kind Regards,

Bhanu

 

 

 

0 Kudos
Message 1 of 9
(455 Views)

Hello,

 

I posted this problem last week in the post: https://forums.ni.com/t5/LabVIEW/Problem-in-acquiring-signals-immediately-after-turning-on-MOSFET/m-.... However, I have not received any reply till now. Probably, I didn't explain it in a proper way. I have tried to simplify the code and the problem and hope that someone here can help me with my problem.

 

I am working on temperature cycling where I turn ON and OFF a set of SiC MOSFETs for cycling their junction temperature. This is being done with the help of procedure called 'Active Power Cycling'. Below is the circuit and timing diagram.

 

okidoki21_0-1719222060385.png

okidoki21_1-1719222080478.png

Here, M_DUT is the set of 4 resistors (3.3 ohm each) that are connected in series. (Please note that M_DUTs should be the series connected MOSFETs. However, for troubleshooting purposes, I am using the resistors for now. So, gate signal to M_DUT is not relevant for now). The main program with different states is written in the RT Scan interface (filename: Debug.vi). I am logging the voltage drop across each resistor using NI-9229 C-series module and the program is designed in RT Scan Interface using subVIs (Data_Logging_ON.vi and Data_Logging_OFF.vi). NI-9402 is used to drive the gate drivers of the MOSFETs (M_main, M_byp and M_Cur). This part of the code is written in the FPGA interface using subVI (filename: NI9402.vi).

 

The setup has 3 main states and I have explained them below:

'State 1': M_main and M_bypass: ON / M_DUT and M_Cur: OFF ---- In this state 500 mA (I_tot) passes through the 'Main' switch in forward direction. Out of 500 mA, around 488 mA passes through the M_byp and 12 mA (I_DUT) passes through the M_DUT. The voltage drop across each resistor in M_DUT should be around 0.04 V.

'State 2': M_main and M_DUT: ON / M_byp and M_Cur: OFF ---- In this state 500 mA (I_tot) passes through the 'Main' switch and 4 series connected resistors (named M_DUT in the diagram) in forward direction. The voltage drop across each resistor in M_DUT should be around 1.65 V.

'State 3': M_Cur: ON / M_main, M_byp, M_DUT: OFF ---- In this state 100 mA passes through the 'M_Cur' and 4 series connected resistors (M_DUT) in the reverse direction. The voltage drop across each resistor in M_DUT should be around -0.33 V. Please note that voltage should be negative as the current is flowing in the reverse direction.

 

Below, I have explained my problem with data logging:

The logging and switching of the MOSFETs is working fine except that I am having issues in logging in the correct data during the transition phases. (Transitioning from 'State 1' to 'State 2'; 'State 2' to 'State 3'; and 'State 3' to 'State 1') as shown below:

Transitioning from 'State 3' to 'State 1' and 'State 1' to 'State 2':

Counter Loop Time Cycle No. State (1,2,3) Timer V_gs - DUT1 V_gs - DUT2 V_gs - DUT3 V_gs - DUT4
20 100 1 3 1900 -0.333003372 -0.332805014 -0.33218782 -0.332181285
21 100 1 1 0 -0.333286648 -0.333163104 -0.332479071 -0.33279324
22 100 2 2 100 0.039668491 0.039392123 0.039195323 0.039312672
23 100 2 2 200 1.655094267 1.6522812 1.649712174 1.649746699

 

Voltage measurements (V_gs - DUT1, etc) during 'State 3' should be -0.33V, 'State 1' should be 0.04V, and 'State 2' should be 1.65V. However as shown in the above table, during the transition the voltage during 'State 1' is still measured as -0.33V (which is voltage during 'State 3') and during 'State 2' is measured as 0.04V (which is the voltage during 'State 1'). This happens only during the state transitioning phase. Below is the picture of the part of the program where it switches the MOSFETs and then logs data during transitioning from 'State 1' to 'State 2'.

 

okidoki21_2-1719228237780.png

 

As you can see from the above Figure, I am switching the MOSFETs to change from 'State 1' to 'State 2' in the first frame and am logging the data immediately in the next frame. My first guess was that the probably data is getting logged before the MOSFET switches change their actual states. So I created a delay in the FPGA code, which gets executed after the MOSFETs have changed their states. However, I am still encountering the same issue.

 

I am eagerly looking for a help here. I have attached the logged file and the project file for your reference.

 

Thank you!

 

Kind Regards,

Okidoki

Download All
0 Kudos
Message 2 of 9
(427 Views)

Hi Okidoki,

 

you use the ScanEngine mode to read the AI channels: what is the timing setting for the ScanEngine (aka samplerate)?

Are you sure you can read AI channels fast enough according to your measurement requirements?

 

I recommend to read AI channels much faster (and continuously) using the FPGA in your cRIO.

I also recommend to improve array handling, like in "DataLoggingOFF" subVI!

Example for possible improvements:

(your code above vs. mine…)

 

And please don't maximize windows to fullscreen, especially for smaller block diagrams or just 3 frontpanel elements…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 3 of 9
(396 Views)

Hi GerdW,

 

Thank you for your reply.

 

The timing setting for the ScanEngine is currently set to 100 msec. I set this depending on how fast I want to sample for example 100 msec or 200 msec.

 

I designed the acquisition in the Scan Interface because I don't want to perform fast sampling (like in 100s of Hz or kHz range). However, it is during the transition phase where I am encountering the issue. I believe the module samples the signal even before the driver and the MOSFET changes their states during the transition.

 

Kind Regards,

Okidoki

0 Kudos
Message 4 of 9
(383 Views)

Hi okidoki,

 


@okidoki21 wrote:

I designed the acquisition in the Scan Interface because I don't want to perform fast sampling (like in 100s of Hz or kHz range). However, it is during the transition phase where I am encountering the issue. I believe the module samples the signal even before the driver and the MOSFET changes their states during the transition.


Using the ScanEngine can be quite limiting (IMHO)…

You cannot sync the ScanEngine to other events/triggers (easily): I think it's a bad design decision to rely on a 100ms/200ms scan interval when you want to measure samples at certain transition events. Using a higher sample rate and only analysing the interesting part of the waveform (synced with trigger signals) seems more reliable to me…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 5 of 9
(377 Views)

Check the specs of the Daqs if they can be triggered by external signal, then use FPGA to generate the trigger to acquire the data (maybe another signal from the same signal you are using to turn on  the MOSFET. 

0 Kudos
Message 6 of 9
(371 Views)

Hi Gerd,

 

I do want to sample at every 100/200 msec in order to save the temperature profile over the tests. However, it is also important to measure the maximum and the minimum temperatures and the corresponding values of the signals during the transition phase. The tests are meant to store data over long duration, several weeks in some cases.

 

How if I design the acquisition during transition in FPGA part and keep the remaining acquisition part (with 100 or 200 msec loop time) in the RT Scan Interface?

 

Kind Regards,

Okidoki

0 Kudos
Message 7 of 9
(346 Views)

Hi Okidoki,

 


@okidoki21 wrote:

How if I design the acquisition during transition in FPGA part and keep the remaining acquisition part (with 100 or 200 msec loop time) in the RT Scan Interface?


In my experience you either use the ScanEngine or the FPGA, but not both to handle the same IO module…

 

(Edit: added the words "same"/"module" in the sentence above.)

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 8 of 9
(343 Views)

Thank you for your reply.

 

I will design it in FPGA and check if it works. Thanks a lot for the support.

 

Kind Regards,

Okidoki

0 Kudos
Message 9 of 9
(340 Views)