PXI-4071 Triggered Waveform Acquisition Phase Problem

[ejensen]

I missed one of your questions in my previous reply.  I am using the same type/length of probes on each of the DMMs.

I previously thought I was getting consistent (though not in phase) output with both DMMs connected to the same point on my DUT.  Watching more closely, I am still getting one output on most runs and a different output occasionally.  In this case, the waveforms are always around 90 degrees out of phase, but in the typical output I get a 'current' (labelled current, but really a voltage reading) lagging by about 90 degrees.  Occasionally, I get a 'current' leading by 90 degrees.  I have attached an image showing both results.  I have labelled one typical and the other occasional.  As before, I get the typical output at least 95% of the time.  Connecting an oscilloscope at this point would be irrelevant since both DMMs are measuring at the same point on the DUT.

So, I seem to be having 2 issues, though probably related.  One, the acquisitions aren't triggering at the same time.  Two, they aren't triggering consistently (the same one doesn't always trigger first).  Thanks again for your help so far.

[ejensen]

I am still having the same issue.  Is it possible to take 2 simultaneous measurements with 2 PXI-4071's?  If so, how?

[aNIta B]

Hi Ejensen,

         I'm wondering what voltage ranges you are working in?  I am assuming you are working in two separate voltage ranges which could be part of the reason that you're not always seeing your signals line up.  The reason for this is due to the settling time and aperature time that varies for the different ranges.  The switch time as well is both non-deterministic and non-programmable. From within LabVIEW, you are able to change your settle time and aperature time with a property node by right clicking on the wire coming from your niDMM Initialize.vi and selecting Create»Property for niDMM Class»Configuration»Advanced. 

          It's important to note that the Measurement Cycles will vary for each of these devices.  I would highly recommend you take a look at the information listed in the NI-DMM Help under  Devices»DMM Measurements»DMM Measurement Cycle (both the top level article 'DMM Measurement Cycle' and DMM Measurement Defaults would be good to look at).  Additionally, please note that while these two devices are triggered at the same time, they are running on their internal sample clocks, which, while having the same rate, may still vary slightly because they are independent of each other.  

        One thing I would recommend trying would be to take two measurements within the same voltage range to see if your signals line up any better than they do working in two different ranges.  Let me know how that goes!

[ejensen]

Initially (waveforms.png above), I was using 2 different ranges.  When I decided to simplify things (waveforms2.png), I have set everything the same.  I think you're right in that it has something to do with the internal clocks being independent of one another.  However, the PXI-4071 is supposed to have a 28.8MHz internal clock.  If the both DMMs are waiting for a trigger, and a trigger comes, they should each get a clock pulse within microseconds.  Why am I seeing the waveform lagged by several milliseconds?  I must be misunderstanding something.

[Margaret F.]

Hello!

Anita is out of the office today, so I have reviewed the posts here and will try to offer my assistance today. I'm wondering if you can tell how long it takes between when you hit run and the trigger is actually received. If the trigger is received immediately, then the problem with the lagging may be that the code is still stuck in the configuration steps and so the timing is off.

If the trigger is received a few milliseconds into the code, then everything should be fine as far as this is concerned and we need to look somewhere else. Is this the case?

Thanks! Have a great weekend!

[ejensen]

It's hard for me to say how long it takes for the trigger after I hit run.  It immediately follows niDMM Initiate.vi.   I have considered this possibility, but the solution I attempted made matters worse.  I tried using a sequence structure to put a wait after the initialize and before the trigger.  When I did this, my waveforms were off more than before.  One reason I don't think the pulse timing is the problem is that I'm only sending a single pulse.  I may be wrong, but it seems if the initiate hasn't finished when the trigger comes, it won't ever trigger and would eventually timeout.  I don't currently have access to my DUT, but if it would help, I can put the delay back in and send some screenshots of my waveforms when I'm able.  I included my VIs in my first post if you have not had a chance to look at them. 

[Mark_E]

ejensen,

I finally see what's going on here. Take a look at your modified code and run it with wait times from 0-4 ms. With 0 ms, you get what you were seeing. With 4 ms, I get no phase delay at all.

So why does that help? You were starting your trigger pulse immediately after initiating one of the DMMs. That second DMM to be initiated still had to complete its switch time. (See the NI Digital Multimeters Help » Devices » NI 4071 » DMM Measurement Cycle) That time can take up to 4 ms depending on measurement type, range, etc. and is not user-programmable as previously mentioned. When a trigger is received during the switch time, it is queued until the switch time is done, and then the DMM will act on the trigger by finishing the rest of the measurement cycle. So even though you had the DMMs programmed in parallel, LabVIEW was initiating the DMMs in sequence. The first DMM had enough time to get through some of its switch time and the second DMM got through less of its switch time by the time the trigger pulse was generated. The reason you saw one DMM leading the other 95% of the time is because of a race condition in LabVIEW where it would choose that DMM to run first. But 5% of the time it chose the other DMM. If you wire the tasks in sequence as I have done, you will see that the DMM that is configured/initiated first will always lead the other. Prove it to yourself by then initiating the other DMM first and it will now lead in phase--every time.

Whew! So in summary, the wait time is to make sure that both DMMs have completed their (up to) 4 ms switch time, after which they are both ready for action. Please let me know if you have further questions and I will do my best to answer them.

[ejensen]

That all sounds very reasonable.  I will test it when I get back to work and let you know if I have any further trouble.  Thanks again for your time.