virtualbench

[ediva99]

Hi. i just got the Virtualbench and not evaluating it with labview 2014.

For my system, When it is at standby, current around 6uA. Upon active, it draws around 12mA. Using a Normal DMM, this could be measured

Had download the standard DMM VI from NI to test out the functionality. 

Connect the Virtual bench to the 100mA terminals as the measured current is less than 12mA. 

When System is at standby, the VI reads back the idle current as accordance

However, when system turns on, it keeps posting NAN and also error mesage on over-range

Had tried to remove the TRUE constant from Auto range of the DMM Configure Measurement (VI) and feed in numeric constant 0.01, 0.1, it just post the same issue. Had even try to feed in 1 and 10 constant just to check on the effect but it post the same issue.

Appreciate if you can give some insights on why is it so

regards 

[JoeFriedchicken]

Hi,

Would you describe more about your setup?

1. When you say "my system" are you talking about your PC or a circuit you are testing (often called a "device under test" or DUT)?

I'm assuming you mean this:

• When the DUT is in standby, it consumes about 6 uA of current.
• When the DUT is active, it consumes about 12 mA of current.
• When you use the VirtualBench DMM example VI with a DUT in standby, you receive correct measurements.
• However, when you use the example VI with an active DUT, you receive NaN measurements and an "over range" warning dialog.
• Turning off auto range and specifying manual ranges of 10 mA, 100 mA, 1 A, and 10 A did not change the measurements for an active DUT.

2. What happens if you use the high current DMM terminal?

3. For comparison's sake, what do you measure when you use the VirtualBeanch application?

[ediva99]

Thanks for responding. This is the first time i am writing in the forum and the first time using NI device (Virtualbench and labview...)

You are right on the DUT standby being 6uA and operation being 6~12mA.

On the high current rating, value took in seems to be lock at around 700nA (Sometime negative values) which i do not understand why.

Come to think of it, On the

DMM Configure Measurement (VI)

When trying to set manual range, i had remove the "TRUE" constant from the Auto range terminal and leave it open. Just wire in a "constant" range to test out. Is this the right way to do or must i wire in a "false" ?

One more thing... when i connect the Virtualbench (Max 100mA terminal), behavior is as per mention in earlier post. However, when i connect another DMM across the same terminal in parallel to the Virtualbench termina that was connected, current drops by half (2 DMM connect at the same terminal) and the VI starts reading back the values, which is 50% of its intended figure. Pretty strange that i would need to connect it in this way to get it working.

Appreciate for any advice in this matter

regards

[JoeFriedchicken · Accepted solution]

Welcome to the forums and the NI platform 🙂 How did you learn about VirtualBench, LabVIEW, and these forums?

Let me answer your questions.

---

ediva99 wrote:
On the high current rating, value took in seems to be lock at around 700nA (Sometime negative values) which i do not understand why.

---

This might be environmental noise since the DMM's terminals are not shielded for noise. The VirtualBench application has a null offset feature in the corner menu that allows the instrument to compensate for the noise.

VirtualBench Specifications, page 9 -- http://digital.ni.com/manuals.nsf/websearch/C85FACB21C0B2E7586257D87007CF760

The input terminals of the DMM are not protected for electromagnetic interference. As a result, the DMM may experience reduced measurement accuracy or other temporary performance degradation when connected to unshielded test leads in an environment with radiated or conducted radio frequency electromagnetic interference.

---

ediva99 wrote:

When trying to set manual range, i had remove the "TRUE" constant from the Auto range terminal and leave it open. Just wire in a "constant" range to test out. Is this the right way to do or must i wire in a "false" ?

---

You must wire in a False constant.

There are two reasons why:

1. The VirtualBench API uses input terminals that remember their last value. If True was wired in previously, then an unwired terminal would still use True.
2. In addition, each instrument's Initialize VI has a "Reset" boolean input which is true by default. As part of reset, the DMM enables auto ranging.

---

ediva99 wrote:

One more thing... when i connect the Virtualbench (Max 100mA terminal), behavior is as per mention in earlier post. However, when i connect another DMM across the same terminal in parallel to the Virtualbench termina that was connected, current drops by half (2 DMM connect at the same terminal) and the VI starts reading back the values, which is 50% of its intended figure. Pretty strange that i would need to connect it in this way to get it working.

---

This makes electrical sense.

By adding a second low-impedance parallel path, you've essentially created a current divider, where each DMM allows half the current to flow through. The total sum of the current, however, is the same and Kirchoff's current law is upheld.

[ediva99]

Thanks, Joe. It's by chance that i come across labview. Soem some demo and like it. Bought a Labview lisence and a Virtualbench to start teh learning. Had already attend the Labview core 1 and 2 so as to have some basic understanding what how labview can help in automating some of the test that we are always doing it manually. The Forum has vast information and willing people to help out. Got many clues on how to solve questions and it's definitely a good place to start off with. Having problem myself, would tried to write in to tap on the expertise on this.

As per your recommendation, Had wired in a "False" constant and it works to a certain extend. i could continue to build the application base on this understanding.

If you may just help to enlighten me on the following, that will be great

1. When my DMM connect to the 100mA terminals and Auto range = False, Manual range = 0.1

- When DUT wake up, there will be an intial surge of around 20mA for 5 seconds. This will be reflected as NAN at the measurement display

- When DUT drop to standby which is around 400uA, it starts measuring again

- When DUT go into Idle mode, it could register a idle current around 6uA

Did further test to verify the Virtualbench operation

- When DUT operating around 12mA, it could measure as accordance

- When DUT operating above that range, something like 20~40mA, a lot of NAN values

Question - Is the range 100mA not sufficient to cover that 20~40mA measurement ?

2. Without changing another Labview constant, connect DUT to the high current measurement (10A) terminal

- Reading was always below 1uA, fluctauting in the nA range

3. Change the Manual Range = 1

- When DUT wake up, it will shows actual current and not NAN

- When DUT drop to standby which is around 400uA, it still measuring correctly

- DUT operating 20~40mA is not an issue and VB measure it as accordance

- When DUT go into Idle mode, it could register a idle current around 50~60uA instead of the 6uA range

For the time being, i had to take the NAN as the trigger point to "wake" up the VI, wake till the system stable down (Around 400uA, that when the VI able to detect) before starts the actual current data aquisation from that point onwards.

Setup is 100mA terminal, Autorange = False, Manual = 0.1

It will be great if any insights on this but the VI can still be build with this limitation in mind

cheers

[JoeFriedchicken]

Awesome! Thanks for sharing 🙂

---

ediva99 wrote:

1. Question - Is the range 100 mA not sufficient to cover that 20~40mA measurement?

---

This surprises me -- the typical VirtualBench support for a given range is a little over 100% full-scale (sometimes as much as 105% FS, see page 9 of the VirtualBench specifications). For example, in the 100 mA range, I would not expect NaN measurements until the current was 103..105 mA.

I suspect that there is more inrush current than you expect. If you can, use the oscilloscope and a known resistance value to measure the transient current that the DUT draws when it wakes.

---

ediva99 wrote:

2. Without changing another Labview constant, connect DUT to the high current measurement (10A) terminal

- Reading was always below 1uA, fluctauting in the nA range

---

The DMM's current ranges correspond to its current terminals:

• 10 mA, 100 mA -- only the 100 mA terminal is connected to the DMM's internal circuit
• 1 A, 10 A -- only the 10 A terminal is connected to the DMM's internal circuit

So, if you set a 100 mA range and connect to the 10 A terminal, then the DUT is not electrically connected to the DMM's internal circuit.

---

ediva99 wrote:

3. Change the Manual Range = 1

- When DUT wake up, it will shows actual current and not NAN

- When DUT drop to standby which is around 400uA, it still measuring correctly

- DUT operating 20~40mA is not an issue and VB measure it as accordance

- When DUT go into Idle mode, it could register a idle current around 50~60uA instead of the 6uA range

---

In this situation, you are observing the accuracy of the DMM.  Here's how to calculate it:

1 A range accuracy: (0.130% of reading) + (0.025% of Range)

Reading: 60 uA
Range: 1 A

(0.130 * 0.01 * 60e-6 A) + (0.025 * 0.01 * 1 A) = (negligible A) + (250 uA)

1 A range accuracy = approximately 250 uA

Right now, in the 1A range, the DMM is operating with more accuracy than specified 🙂

See Table 3 on page 8 of the VirtualBench specifications for the coefficients for every range and mode.

[ediva99]

Thanks, Joe, for the great insight.

To share, using the same setup,

Connect to the 10A terminal and check graph. The current recorded is almost 100mA and the swing in range in attachment Measurement 1 seems to show that

Had lower the current of the DUT slightly below 100mA and measurement 2 shown that.

Had further lower the DUT curent to attachment measurement 3 where it is in the range of less than 30mA.

All these could be measure and represented as accordance.

However, when switch over to 100mA terminal of the Virtualbench and set to manual range, constant = 0.1, NAN observe in all 3 scenerio. Measurement 1 and 2 might be corner cases since it is close to 100mA but strangely, measurement 3 should be within range.

Now, have to separate the test to check operating current and time and then redo the test to ignore those NAN to check whether DUT go back into sleep mode. Double job...

Maybe Virtualbench is not the right platform to perform such check ? Do you recommend using those DAQ products to do similar ? If so, any DAQ recommendation ?

regards

[JoeFriedchicken]

---

ediva99 wrote:
However, when switch over to 100mA terminal of the Virtualbench and set to manual range, constant = 0.1, NAN observe in all 3 scenerio. Measurement 1 and 2 might be corner cases since it is close to 100mA but strangely, measurement 3 should be within range.

---

Thanks for the screenshots. Based on them, I still expect the 100 mA range to serve your needs.

Perhaps there is a problem in the VirtualBench DMM. You can check for hardware malfunctions using the application.

1. Start the VirtualBench application, and turn off the DC Power Supply and set the DMM to DC current mode.
2. Connect the +25 DC Power Supply terminal to the 100 mA DMM terminal.
3. Connect the corresponding ground terminals.
4. In the application, set the +25 rail to 10 V and 5 mA and turn on the DC Power Supply.
5. Begin increasing the current set point and observe the resulting measurement in the DMM.

On my device, I don't see "OVER" (or "NaN") until the current is above 104 mA:

[ediva99]

HI, there.

Had a few session with NI folks on the Virtualbench, hopefully to come to some conclusion.

It seems that in measuring the DC level, DUT has transient that cross beyond the 100mA range. When this happens, as accordance to NI member, DMM read vi (Those are the Vis that comes along with Virtualbench) will return a NAN value on that iteration. The loop i had set in labview is a DMM read every 100ms. A single DMM read will read in multiple value instants but if any instance is a NAN, it will present the whole value as NAN although there are valid instances in that single DMM read.

In our case, this will break the Datalogging on the operation.

Does anyone has any work around or any modified DMM read vi which may be able to disregard the NAN and only return the average valid values ?

When using normal handheld DMM does not have this issue and currents as display as accordance. Below is the capture current Transients together with NI members.

Thanks in advance and appreciate the help from NI Technical Member in that work together with us too.

[ediva99]

Hi.

Had post a post today and it seems not reflected at the forum. Therefore, post again as not sure where when wrong.

Had a few session with NI member to try to resolve the Virtualbench issues that was mention.

Pre-condition - VirtualBench using 100mA terminal, connect in series

1. Virtualbench itself, is functional, using Joe test recommendation

2. Looking at the waveform, it seems that when measuring the DUT current, there occur transient spike that is beyond 100mA

3. Using handheld DMM (200mA range), we have no issue to read back the DUT current

4. Using VirtualBench, In our application, labview DMM read vi is within a while loop with 100ms interval. The DMM read VI are supply along with the Virtualbench

As accordance to NI members, every execution (Or every read) of the DMM read VI might takes in multiple DC values instance. If any of those values happen to be NAN, the resultant output = NAN, irregardless if that single read execution of the DMM vi has other valid DC values. The spike, as per attach might end out being read in and cause NAN to be output.

In Our case, the datalogging portion is an issues as we will end out many intervals (Can be a couple of seconds) with NAN values. The system will report that as a break in operation which is not a real case.

Is there any recommendation to overcome this in labview ? Or anyone has some modified DMM read vi which at a single read instance, disregard the NAN and returns the average for that read instance ? 

Appreciate if anyone can offer any advice or work around. Thanks in advance and also thanks to the NI members that had spent time with us trying to troubleshoot on this issue

regards