LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

converting acceleration to displacement

Solved!
Go to solution

Hi guys,

 

I'm basically doing an experiment which involves using 2 x triaxial accelerometers to calculate displacement of the centre of a rotating circular tool (to which an accelerometer is attatched to each side) and I'm using labview 2009 to collect & analyse the data.  I know that there are limitations to this due to noise, but thats fine, i'm just going to compare it to some lasers... 

 

However, I think there is a problem in the proceedure/maths of my vi which is causing a completely wrong displacement.  I've attatched a screen shot of the front panel in action whilst its running and my vi.  It would be great if anyone could point out whats going wrong.

 

The vi is basically displaying the displacement from the lasers and from the accelerometers simultaneously.  for displacement from the accels I am subtracting the acceleration of one axis from the corresponding axis on the opposite accel and halfing it to gain the acceleration due to movement (roughly) of the tool's centre rather than due to rotation.  I then double integrate it to give displacement, find the magnitude between the 2 axis i'm interested in and plot it on a polar plot with theta being an angle observed independantly from an encoder.  I have no idea whether this is the correct approach, any help will be most welcome!

 

Regards

 

Luke

 

 

Download All
0 Kudos
Message 1 of 10
(5,648 Views)
Solution
Accepted by topic author lpaza

Ok this will take a couple steps.

 

First I change your structure a bit to implement a producer consumer loop.  You were not passing valid values into the consumer loop.  Your vi enqueued your analog samples until you pressed stop and you only dequeued the first set.  Then your second loop started and only had the first data to work with.  There was no time relation between the queue data and the counter data.  There still is not and we'll get to that eventually.

 

Check out the LV examples on usuing queues and we'll get back to making the vi work.  Your basic approach sounds reasonable.  Just a matter of learning enough LabVIEW to execute your desires.


"Should be" isn't "Is" -Jay
Message 2 of 10
(5,625 Views)
Thanks Jeff for the reply and for your help with the producer/consumer loop.  I'm quite new to LabVIEW and am so far learning from examples and the forum so your advice is much appreciated.  I think I understand now the flaws in the previous loop structure.   I had a look at a few examples and saw the 'wait (ms)' function in the consumer loop so I stuck it in since it sounded useful.  With regards to the relationship between the queue data and the counter data; I thought there was a problem but I could never fix it.  Since you highlighted its timing issue, (and I don’t want to make everyone else do the work for me!) I’ve tried juggled it around until both sets of data are being queued together.  Am I heading in the right direction? Cheers Luke
Message 3 of 10
(5,603 Views)

I wish I could give you more Kudos!

 

You are heading in the right direction!  and learning how to use the examples!  These are the types of posts that give us members the greatest reward.  I'll take a look at your code later today (time constraint) but I will get back.


"Should be" isn't "Is" -Jay
Message 4 of 10
(5,591 Views)

The Base Archetecture now looks meaningful.  GREAT job!

 

However the math is very questionable and its pretty obvious that you are not going to get meaningful data.  I'm going to need a signal map to understand what the several waveforms represent (I don't have your hadrware) So I'll ask you to add comments to the code to describe the signals (good practice- you'll need to rely on them when you look at this in 6months)

 

Here are some shots of the easy to spot bad math.

 A SML.PNG

Bbb.PNG

 

Just a start- but we will get there!

 


"Should be" isn't "Is" -Jay
Message 5 of 10
(5,581 Views)

Ah, it appears that my constants are 0 since it was an older version I adapted!  I'll re-post another with comments.

 

Cheers!

 

Luke

Message 6 of 10
(5,576 Views)

Okay, here's the real deal with comments also.  I'll have access to the lab tomorrow so i'll have a look at the waveforms and get a few screenshots maybe.  Thanks again for all your help.

 

Regards

 

Luke

Message 7 of 10
(5,562 Views)

Ok, I believe I understand what you've done.  Absolutly time to go to hardware.  Your methods look good (eventually you'll need to learn some better style for LV)  I can see a few places I would use sub-vis to encapsulate some of the common reusable functions and you've got some Rube Goldberg stuff in there.  Yet, I'd Focus on tweaking it to work before I started hitting style (it does come with practice)

 


lpaza wrote:

Okay, here's the real deal with comments also.  I'll have access to the lab tomorrow so i'll have a look at the waveforms and get a few screenshots maybe.  Thanks again for all your help.

 

Regards

 

Luke


My pleasure-  (though- if you would be so kind- Kudos for good responses and marked solutions are all we get to show for our efforts and are considered pollite on the forums)

 


"Should be" isn't "Is" -Jay
Message 8 of 10
(5,555 Views)

Hello, It is possible to get the code,  It file can not be downloaded, thanks

0 Kudos
Message 9 of 10
(2,778 Views)

Hi Gustavo,

 


@GustavoLab wrote:

Hello, It is possible to get the code,  It file can not be downloaded, thanks


Why don't you download the VI attached to message #7?

I can download the VI and open it with LabVIEW2020…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 10 of 10
(2,767 Views)