LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Mean ptbypt not reaturning the average?


@randomguy77 wrote:

So does just the mean ptbypt need to be in a loop, or should I have the entire section that is finding the phase in a loop as well, or should the whole vi be in a loop, and then a subloop that has the mean calculation being done?


Your entire application should be in a loop.  Then you add a stop button to stop the loop.  This is the alternative to using the Run Continuously, which was only designed to be a debugging tool.



There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 11 of 16
(849 Views)

You'll want a loop around the whole VI, after all that is what Run Continuously does, right?  It executes all of the code over and over, except that each time is like the first time.  Think of it like this, when you click Run Continuously, it's like you clicking the run button but after the code finishes execution the first time, there is an invisible mouse cursor waiting to click the run button again....and again....and again. 

 

When you put a loop around your code, you only need to use the Run button once and provide a stop condition when you are ready for the program to exit (boolean button, loop count, etc).  This allows the Mean function to function properly and maintain a running total of input values.

aputman
0 Kudos
Message 12 of 16
(848 Views)

Thanks for you help. I obviously didn't realize that the run continuous button was only for debugging. I added the loop at it starting taking the average.

 

Can someone let me know if this:

 

http://digital.ni.com/public.nsf/allkb/F4BB644ECCA595D886256FFE00722E29

 

is the best way to find phase? I'm using the second method listed as they are square waves, but I am not getting a constant phase. There should only be a few degrees of variance between the signals, but it is jumping a lot while calculating it. It is jumping down to around -270, so it is almost like it is taking the other signal first at times to calculate the phase. Can that be caused by just not having a high enough sampling rate?

0 Kudos
Message 13 of 16
(839 Views)

What does your actual signal look like?  Your graphs are showing the phase difference.  

aputman
0 Kudos
Message 14 of 16
(832 Views)

This is the input graph of the two signals. When it graphs them it shows the phase correctly. They stay around 90 degrees.

0 Kudos
Message 15 of 16
(826 Views)

It sounds like you have a synchronization issue.  Since you start sampling at some random time relative to your waveforms, you could start sampling when the first waveform is already high but the second is still low.  Since the Pulse Measurement defaults to using the first pulse, the second signal's pulse center will be before the first.  This will give you the -270 degree phase.  So you should add a check to see if your data makes sense.  If the calculated phase is less than -5 degrees (assuming both are in phase and with some jitter, this is not unreasonable), then redo the pulse measurements on the second waveform using 2 for the pulse number (an input to the Pulse Measurement VI) and recalculate the phase.  Or you can just add 360 to the calculated phase when it is out of range.



There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 16 of 16
(814 Views)