LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why my force data and displacement data have phase lag

Solved!
Go to solution

Hi Good people,

I am using this attached VI to measure Force, acceleration, and calculating the displacement from the measured force. I am observing there is a phase lag between the force, acceleration and calculated displacement. One loop time (4ms) phase lag may be present but I am observing around 40ms between the displacement and the force.  I am wondering whether my program is correct or I did any mistake in the program. Could you please help me with my problem? Thank you.

0 Kudos
Message 1 of 17
(1,358 Views)

No, the program is not correct.  I'm not able to analyze all the possible ways, here are just a few things to start:

 

1. You haven't taken steps to synchronize the tasks.  Look into topics like "channel expansion" and triggering.

2. Your force measurement appears to use a bridge module, which will almost certainly use a Delta-Sigma converter that induces a delay in the signal path.  Your acceleration measurement is on a different module which is not likely to induce the same delay (if any at all).

3. You leave open the option to apply different digital filtering to the two measurements, each of which will induce their own delay.

4. For some reason you use a dynamic data conversion to squeeze a single tiny scalar out of your much richer multi-sample waveform data.  I have no idea what you should expect from that, I have dutifully avoided dynamic data whenever possible which is virtually always.

5. You've overconstrained your loop timing.  You shouldn't combine a Timed Loop with DAQmx Read calls that request a specific # of samples.  Either the # samples will require more time to accumulate (in which case the Timed Loop is pointless and a standard While Loop would have been better), or the Timed Loop interval will be longer than the time needed to accumulate those samples (in which case you'll eventually get a buffer overflow error from your DAQmx task).

6. Not exactly *incorrect*, but the code is much too large & cluttered to digest and understand easily.  Many more problems may be lurking, but I for one don't have the extra time needed to search for them.

7. Your many uses of local variables are *probably* setting you up for several race condition problems (when do the values get read relative to when they get written?  Is it guaranteed to be consistent?) that I don't have time to analyze in depth.

8. You'd be doing your present and future self a favor by:

   a. bundling related scalar values into clusters and always bundle/unbundle by name

   b. learning about how & why those clusters should be made into "typedefs".

   c. creating subvi's for various aspects of your numerical processing, preferably using some of these typedef'ed clusters to reduce the # of input and output wires.

   d. using the typedef'ed clusters will also let you greatly reduce the # of individual shift registers you need, which in turn will help reduce the wire clutter.  And then the bundle/unbundle by name operations become self-documenting so you don't need all the individual text labels for the individual wires and tunnels.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 2 of 17
(1,327 Views)

Hi Kevin,

Thank you very much for your detailed feedback. I am not good at LabVIEW, almost novice. Could you please help me a little bit more to develop the VI as per your suggestion?

0 Kudos
Message 3 of 17
(1,318 Views)

@Kevin_Price wrote:

1. You haven't taken steps to synchronize the tasks.  Look into topics like "channel expansion" and triggering.

 


Something like below may work with channel expansion since your modules are in the same chassis. (There may still be a phase shift between the two, but it will be locked at constant throughout the experiment.) See how everything is combined in the same task?

 

Snip.png

 

Get rid of the timed loop. Set the read to collect N samples; the loop time will (NSamples)/(Sampling Rate).

 

mcduff

0 Kudos
Message 4 of 17
(1,302 Views)

Hi,

Thank you very much. I will try this one and let you know.

0 Kudos
Message 5 of 17
(1,264 Views)

Could you please help me regarding the attached VI? I am trying to synchronize the accelerometer and force accusation but the VI is not working. 

0 Kudos
Message 6 of 17
(1,251 Views)

What is the error with the VI?

 

Why are you setting Continuous Samples and then have no loop to collect them?

 

If you just want to test the sync, why not try finite sample below and take 10000 samples, see below.

Snap144.png

I like to have integer sample rates, the Q&R function will not give correct answers for all possible n from 1 - 32; you may need to change it division if needed. Below are allowed sample rates along with n.

Snap145.png

 

mcduff

0 Kudos
Message 7 of 17
(1,245 Views)

Hi mcduff,

I am getting this error message when running the VI.

0 Kudos
Message 8 of 17
(1,241 Views)

The error appears to be self-explanatory, did you try something like this?

 

Snap146.png

0 Kudos
Message 9 of 17
(1,234 Views)

Hi mcduff,

I tried that and it was showing the error message as shown in the attached file.

0 Kudos
Message 10 of 17
(1,230 Views)