Meters are playing ping-pong. Argh!

[PaulG.]

I know I'm missing something very simple. I am trying to acquire voltages in parallel from 2 Agilent 34401, serial ports 3 and 4. I'm only triggering 1/sec, but the meters acquire back and forth, ping-pong style. I don't understand this. Both are getting the same trigger. I only need to do a simple A/B math function but can't since both voltages need to be read at the same time. This is driving me nuts. 

[crossrulz]

I don't think it has anything to do with your problem, but why do you have a wait inside of a timed loop?  That seems a little redundant to me.

[Ray.R]

Have you built a table of values that go to your meters?

Since you are reading a single point, your meters are showing that value.  If at each iteration the values are:

5

1

8

3

8

5

8

6

3

8

6

9

2

6

4

On a scale of 0 to 10, you will notice the needle going back & forth.

For the same scale (0 - 10), if some of your values are over 10:

5

12 > 2

8

3

9

11 > 1

8

9

12 > 2

8

11 > 1

9

10

11 > 1

10

12 > 2

9

11 > 1

and so on...  it will be an even more pronounced "ping pong"

[JÞB]

Paul,

Try making the read single point sub.vi re-enterant and prealocate clones.  (The call is blocking)

[PaulG. · Accepted solution]

Thanks everyone for your input. I had to dig a little deeper into lower-level trigger vi's. Part of my problem was logistics. I did not have hardware in the development machine. I write it here, create the exe, sneakernet over to the floor and test. Lots of exercise but not a lot of fun.  This is what is working. Operator is happy. That is all that matters, right?

[dthor]

One comment on your working code is that you have a shift register on the top error wire and not on the bottom. Minor, but could cause issues if you forget to fix it.

Personally, I would use the error wire to force data flow: make meter 1 trigger and read, then make meter 2 trigger and read, and then finish off the loop. Yes, it means that your measurements are not done *exactly* at the same time, but at least you know that meter 2 is always measured second. The time difference between the two will be on the same order as the communication delay over GPIB, so it's pretty minimal.  With your current code, you have a race condition: how can you tell which meter measures first?