Delay while turning ON channel in NI-9402

[okidoki21]

Hi,

I am using NI-9402 with cRIO NI-9022 to switch the MOSFETs. I am performing the power cycling test, where the junction temperature of the MOSFET is cycled in between given temperature. During the test, I store data in the TDMS file. I have implemented the sampling time-period of 30 msec by using the timed-loop. In order to capture the maximum temperature, I have used additional sampling when the condition of maximum temperature is met. Therefore, there will be additional sampling (in 1 cycle) in between 2 regular 30 msec sampling.

However, I have noticed that I have a big delay time (around 7 msec) from the time when LabView commands to turn OFF MOSFET to the time output of NI-9402 turns low.

In the below figure, on the extreme left, I am writing data at regular sampling of 30 msec using timed loop. When the turn-off condition is met, we do the switching of the MOSFETs and then again write the data (extreme right) at that operating state (MOSFET highest junction temperature). This data is stored when turn-OFF condition is met.

In the below figure, the data in green shows that MOSFET is commanded to switch from ON to OFF. The data in red shows the ouput voltage from NI-9402. This is without having any delay in between the time when the command is given and when the data is read. Column 1 shows the sampling time in milli-second.

The below data is when delay of 6 millisecond is introduced and it didn't worked this time as well. The data in red still don't changed to zero (NI-9402 low state)

The below data is when delay of 7 millisecond is introduced and it worked.

There are no gate drivers involved. We are directly reading the output of NI-9402 using NI-9229.

I was wondering if there is any way by which I can avoid this delay.

Kind Regards,

Bhanu

[GerdW]

Hi Bhanu,

---

@okidoki21 wrote:

I am using NI-9402 with cRIO NI-9022 to switch the MOSFETs. I am performing the power cycling test, where the junction temperature of the MOSFET is cycled in between given temperature. During the test, I store data in the TDMS file. I have implemented the sampling time-period of 30 msec by using the timed-loop. In order to capture the maximum temperature, I have used additional sampling when the condition of maximum temperature is met. Therefore, there will be additional sampling (in 1 cycle) in between 2 regular 30 msec sampling.

However, I have noticed that I have a big delay time (around 7 msec) from the time when LabView commands to turn OFF MOSFET to the time output of NI-9402 turns low.

In the below figure, on the extreme left, I am writing data at regular sampling of 30 msec using timed loop. When the turn-off condition is met, we do the switching of the MOSFETs and then again write the data (extreme right) at that operating state (MOSFET highest junction temperature). This data is stored when turn-OFF condition is met.

---

IMHO your VI lacks any proper design/algorithm…

• Placing a timed loop set to iterate in 30ms does not ensure this iteration time when you place large sequence structures inside, with lots of ScanEngine IO nodes and also lots of SharedVariable accesses! Why do you need to access the same IO nodes multple times within one iteration of your loop?
• Why do you need so many local variables? (Use wires…)
• Why do you need to write to a shared variable in one frame and read from it in the next frame? Why don't you use a wire in such places???
• Why do you write to indicator terminals in one frame and read from their locals in the next frame? Why don't you use wires in such places, too???
• Why do you write to a terminal in one case of a case structure and to a local of that element in the other case? When you want to write to that terminal in both cases then that terminal belongs AFTER the case structure!
• Why don't you implement a (proper) state machine with some decent data handling using atleast one shift register?
• Why don't you use subVIs to make your main VI more readable?
• Why do you place charts inside a timed loop? (This is a no-go.)
• Why do you use charts on a REALTIME target at all? Your "legacy" cRIO controller doesn't provide any display connector and so is NOT capable to display an UI!!!

When you want to use a Realtime target for realtime applications then you need to write your program in a realtime-compatible fashion!

My recommendation:

• Learn LabVIEW basics and start to "THINK DATAFLOW!".
• Then learn LabVIEW for realtime target basics and apply them to your project!

NI provides training and manuals for both recommendations…

[okidoki21]

Hi,

Thanks for the reply @GerdW.

We followed the tutorials mentioned here (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000x0UdCAI&l=en-US) before starting to write our LabView code. We have also watched few LabView and cRIO tutorials.

I understood your points when it comes on replacing the shared variables and local variables with wires. However, I still cannot understand about the disadvantages of using the shared variable and local variables.

We basically have a simple state machine where we heat up the device using its own power losses and then cool it down depending on the manually entered turnON and turnOFF time. This process should repeat for many cycles. Through the heating and cooling phase we want to log the data at constant sampling frequency. Additionally, we also want to log the maximum and minimum temperature (which can occur in between 2 sampling points). I understand that having everything in the same timed loop can create a lot of burden on it. Should I use 2 synchronized timed loops, one for scanning the data from IO Scan Engines and saving it in a variable and the second for controlling the transition among the states in state machines?

Kind Regards,

Bhanu

[GerdW]

Hi okidoki,

---

@okidoki21 wrote:

However, I still cannot understand about the disadvantages of using the shared variable and local variables.

---

SharedVariables, especially the network-based ones, can introduce lags. When readings a NSV immediately after writing to it may result in wrong readings…

Local variables introduce race conditions and data copies…

THINK DATAFLOW: the wire (and shift registers) are "variables" in LabVIEW!

---

@okidoki21 wrote:

Additionally, we also want to log the maximum and minimum temperature (which can occur in between 2 sampling points). I understand that having everything in the same timed loop can create a lot of burden on it. Should I use 2 synchronized timed loops, one for scanning the data from IO Scan Engines and saving it in a variable and the second for controlling the transition among the states in state machines?

---

• How do you want to log min/max values when they may occur between your "sampling points"? How do you even know them when you don't sample them???
• Why do you insist on using timed loops? What are your timing requirements? Why not use two (or more) default while loops in parallel?
• The ScanEngine will limit the timing anyway: which sampling period did you configure? Don't forget: the legacy cRIO9022 is rather limited…
• LabVIEW offers a lot of mechanism to share data between loops. Locals may seem easy to use, but there are notifiers, queues, different kind of channels, RT-FIFOs, …

[okidoki21]

Hi GerdW,

Below are my replies:

• How do you want to log min/max values when they may occur between your "sampling points"? How do you even know them when you don't sample them??? REPLY: We have a condition, which defines whether the device has reached the maximum temperature. We have an additional sampling inside the boolean case structure when the condition becomes true. Otherwise, we have usual sampling with sampling period of 30 msec.
• Why do you insist on using timed loops? What are your timing requirements? Why not use two (or more) default while loops in parallel? REPLY: We want to write the sampled data in the TDMS file at regular interval, example 30 msec. That is why we introduced the timed loops.
• The ScanEngine will limit the timing anyway: which sampling period did you configure? Don't forget: the legacy cRIO9022 is rather limited… REPLY:  ScanEngine is configured at 1 msec.

I am planning to implement a state machine with 3 loops, one for sampling all the data from IO nodes, second and third for controlling state-transitions and writing to the TDMS files.

Kind Regards,

Bhanu

[GerdW]

Hi okidoki,

---

@okidoki21 wrote:

• The ScanEngine will limit the timing anyway: which sampling period did you configure? Don't forget: the legacy cRIO9022 is rather limited… REPLY:  ScanEngine is configured at 1 msec.

---

Even when you configure the ScanEngine to run at 1kHz: does it even run that fast? Does it run this fast when you handle more than 1…4 IO nodes? What's the CPU usage when trying to run the ScanEngine this fast?