LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

help please!

hi, before i put this code to bed, i need to sort out one little bit of it that i cant for the life of me do! i wouldnt imagine its not a big thing, i just have no clue! basically on the "results" frame, bottom left, im trying to do an FFT. however, certain paramtres are wrong! the detected fund is coming one tenthousandth smaller than it should, this value reflects the sampling frequency so ive just been multiplying the exported signals by the sampling freq as you may see to get a realistic frequency. im not convinced that this is acceptable though, nor am i happy that the other parametrs are correct, i.e. the harmonic comonents, THD. this feature worked fine in earlier versions, i have no idea whyit doesn t now? please help.


another thing, can the reults be changed so that the Y axis is linear in magnitude rather than dbV?


hoping someone can help., urgently. 😕


0 Kudos
Message 1 of 5
(3,006 Views)

I took a look at your VI but I quickly got lost in some of the states. The Results state is especially bad with wires going in all different directions. Wires (and functions) should flow from left to right, top to bottom. The style guide that ships with LabVIEW has examples. I'm not a fan of icon view on the diagram but you should pick one style or another. You also do some weird things with build array and index array in several locations. I've attached a picture that shows what I mean by weird. What you've done is just an unneccessary complication. All of the spearate indicators for your harmonic voltages could be done with a cluster array and that would make that part of the code much simpler to read and understand. You can also greatly simplify things by setting your DAQmx Read to return a waveform data type instead of a 1D DBL. If you used the waveform type in the first place, you wouldn't need all of those conversions to get a time stamp and passing sample rate to all of the correct locations. I suspect that all of your parameters would be correct if you were consistent with the waveform data type as that automatically includes timing information. Somewhere along the way you've lost that with the back and forth conversions but I would have to spend an awful lot of timing cleaning up your code before I could say exactly where that happened.

Message Edited by Dennis Knutson on 04-19-2006 12:23 PM

Message 2 of 5
(2,985 Views)
hi, thanks for having a look. the problem seems to be after the conversion from 2daryay to waveform.(see simple circuit attached to demonstrate) when trying converting from  2-D array of double [64-bit real (~15 digit precision)] to Waveform the frquency goes all to pot! ive demonstarted this in a simple example that came with the software. you can see the detectde freq is wrong! did i convert it correct?

 so i took your advice. only trouble is, when changing to read waveform, it totally mucks up the triggering VI. i dont know how to remedy this?


 how can this be resolved? thanks

0 Kudos
Message 3 of 5
(2,934 Views)
No, that is not correct. When you convert to dynamic data type, you do not automatically get any timing information because the timing information does not exist in the DBL array. Here is Analog SW Trigger converted to take an array of waveforms. With this, you get the timing information. That includes dt and t0. With this, you don't have to do anything in your later code to add this since it was never removed.
Message 4 of 5
(2,914 Views)
Hi G,
 
What I'd recommend doing with the VI in the state it is in, is to break that "Results" case down into as many different cases as you need to be able to shrink the block diagram down so it fits on one screenful (making the VI easier to navigate and edit). You could do this either by taking different functions into different cases which are set to execute sequentially, or you could break some of your computations down into sub-vis (at which point you can edit and test those blocks of code individually).
 
Regarding the front panel controls, I would group controls or indicators doing similar functions into clusters so you don't have loads of control/indicators nodes cluttering up the block diagram.
 
Until you start doing this, it is really difficult for anyone else to comment on what's going on in there. I've taken a part of your Results case that handles level and amplitude measurments and made it into a smaller sub-vi - you could either place this code in its own case on the block diagram (called, for example, level measurements) or make it into a sub-vi and pass in the data array, and out the values for the indicators and the table.
 
Hope this helps get you started.
 
Best wishes,
 
Mark
0 Kudos
Message 5 of 5
(2,892 Views)