Jump to content

Integration vi blocks


MTM

Recommended Posts

HI,

I need to perform an integration function within my block diagram. Whenever I use a simulated signal to match calculated results, the integration blocks never outputs the proper results I calculated. How can I correct this problem?? I don't want to use scaling parameters because these will not always give me the proper results I am looking for.

Mike

Link to comment

QUOTE(MTM @ Jun 29 2007, 09:28 PM)

HI,

I need to perform an integration function within my block diagram. Whenever I use a simulated signal to match calculated results, the integration blocks never outputs the proper results I calculated. How can I correct this problem?? I don't want to use scaling parameters because these will not always give me the proper results I am looking for.

Mike

Do you have an example of what you want to calculate, and how you tried to do this? just thinking about what discrete interpolation technique you used (euler, simpson, Bode, Cramer etc..), and if you give the discrete integral approximation enough datapoints to work on (dt VS array/simulation data size)?

Link to comment

QUOTE(xavier30 @ Jun 29 2007, 07:58 PM)

Do you have an example of what you want to calculate, and how you tried to do this? just thinking about what discrete interpolation technique you used (euler, simpson, Bode, Cramer etc..), and if you give the discrete integral approximation enough datapoints to work on (dt VS array/simulation data size)?

xavier30,

I have been using the NI_AALPro.lvlib:Integration x(t).vi block to do my integration in the Labview 8.2 enviroment. This is the first phase of a series of cascaded integrators I will need to apply but I need to make sure the first one works so the following series of integrators will also work. The function I need to integrate is A(t) on the interval of upper limit=2*pi and lower limit=0 where A(t)=A*sin(w*t)dt using trapezoidal integration. A in this case is constant, w is omega, and t is time. I'm not sure how the array data is handled within this block. I have been using different sampling numbers to try and get the proper result; however, when I use a high sampling rate my integrator block keeps integrating linearly off into infinity. I am using a simulated signal and believe that at the right frequency and amplitude (ones that I calculated and I know are right) I should be able to match my calculated values, but have not been able to do so. I am new to the labview enviroment so I could be overlooking something simple...

Thanks,

MTM

NI_AALPro.lvlib:Integration x(t).vi

NI_AALPro.lvlib:Integration x(t).vi

Link to comment

Hi,

as far as I understand, you try to integrate a sine function. Did a test, as can be seen, looks perfectly normal to me:

http://forums.lavag.org/index.php?act=attach&type=post&id=6287

http://forums.lavag.org/index.php?act=attach&type=post&id=6288

Integration of a sine yields a cosine. Even did a recheck by a numerical differention of the integral which yields the original sine function.

Or do you want to integrate the sine function over one period? Also tried that one, yields zero as expected.

Jens

Link to comment

QUOTE(xavier30 @ Jul 2 2007, 05:44 PM)

There is also a block called "integration ptbypt" (integration point by point) found under "signal prosessing", which can be used to integrate series of scalar momentary values (accumalates the total area of all the scalar values from 0 to n-1).

/x

I guess my core problem here is knowing how to setup the sampling rates. I don't know if anyone here is familiar with vibration measurements that are taken from an accelerometer. I am going to eventually replace my simulated signal with a DAQ signal. For ideal purposes, I started with the simulated signal source to make sure my integration function(s) are working. The input into my circuit from the accelerometer will be acceleration where I take that signal, integrate it, and that result after integrating one time will become velocity. I then will need to integrate from the velocity signal to displacement. Filtering out any other frequencies under ideal settings is not of concern. How do you know how to setup the proper sampling??

Thanks for the inputs everyone,

MTM

Link to comment

QUOTE(MTM @ Jul 3 2007, 03:47 AM)

How do you know how to setup the proper sampling??

The sampling frequency varies from daq device to daq device. This should be awailable in your device documentation, and you can set the rate in labview acordingly. This is if the network connection between your device and your computer supports the same rate. (or if possible, store the data locally and do calculations of the measurements after acquiring the data).

Where i work, we use several PXI's with DAQ cards to aquire data with frequencies up to 30Mhz, if the frequency is above this, we use FPGA since the PXI can't handle these speeds in RT. We store the data locally on the PXI, without doing any form of calculations or manipulation of the data, and when the test is done, we store the data in a main repository, where users can download and manipulate the data accordingly.

So do you need to do the measurements and calculations in RT, or is it possible to buffer/save the data locally and do the calculations after? if buffering/saving is possible, you aren't that dependant on the sampling speed of your calculations on the computer, since you then calculate the outcome of the array.

/x

Link to comment

QUOTE(xavier30 @ Jul 3 2007, 09:06 AM)

The sampling frequency varies from daq device to daq device. This should be awailable in your device documentation, and you can set the rate in labview acordingly. This is if the network connection between your device and your computer supports the same rate. (or if possible, store the data locally and do calculations of the measurements after acquiring the data).

Where i work, we use several PXI's with DAQ cards to aquire data with frequencies up to 30Mhz, if the frequency is above this, we use FPGA since the PXI can't handle these speeds in RT. We store the data locally on the PXI, without doing any form of calculations or manipulation of the data, and when the test is done, we store the data in a main repository, where users can download and manipulate the data accordingly.

So do you need to do the measurements and calculations in RT, or is it possible to buffer/save the data locally and do the calculations after? if buffering/saving is possible, you aren't that dependant on the sampling speed of your calculations on the computer, since you then calculate the outcome of the array.

/x

X,

Never thought about it from that angle, I could buffer/save the info, but our field crews like to have real time accelerometer measurements. Any thoughts on how to manipulate dt from the sample rate?

Thanks for your help,

MTM

Link to comment

QUOTE(MTM @ Jul 3 2007, 05:20 PM)

I guess there are many ways to do this, and there are probably alot more skilled LabVIEW programmers in this forum than me, but i would suggest that you time the calculations you are doing

so that you have a pinpoint on how many seconds/milliseconds your calculations take in a "real" run. Then you atleast know what sampling frequency/time you can't pass.

This can easilly be done by adding a flat/stacked sequense structure around your calculations, and time the calculation time, something like this:

http://forums.lavag.org/index.php?act=attach&type=post&id=6299''>http://forums.lavag.org/index.php?act=attach&type=post&id=6299'>http://forums.lavag.org/index.php?act=attach&type=post&id=6299

A good thumb rule is to have atleast 2 or more measurements/samples for every half period to prevent folding of the signal. (think it was Lindquist who calculated that, but im not quite sure).

So if your application at "max" speed doesn't use more time to calculate than the time it takes to take atleast 2 measurements (i would prefer more points, but this is the absolute minimum i guess), i would beleive you could do a "almost" RT tool..

If you can, i would rather divide the program into two parts: RT and "calculations". The RT task is set to a higher priority than the "calculation" part, and the data is buffered and only updated to the calculation part when the RT is "idle" or when it is suitable to do so. This way you dont loose any time from calculating or loose any data (more than the digitalization itself looses), and get the least corrupted data.

The most time and even CPU consuming part i often find being the charts and visual data updated. Even a small detail such as using square dots instead of round ones (or was it the opposite way around??) in the charts, has a effect on the "calculation" time, so all the graphical handeling should be placed outside tha RT task.

The only problem with this solution is if your data amount before "idle time" is really big. Since the "calculation" part of your program never handles the data synchronus with your RT task, the data array of the RT task increase for every minute. But usually this isn't any problem with todays memory or equipment.

i think there are several examples on ni.com's pages and in the RT package itself (sorry, but i dont have the LabVIEW RT installed on the maschine im writing on right now, but i will check it) on how to do prioritized loops.

Don't really know if this answered your question, but if you could provide some code of what your are doing, it would be easier to (atleast try to) point out some sollution :) (and some additional equipment / operating frequency details would help aswell)

/x

Link to comment

X,

Here is a version of the code I am working on. Take note of the integration blocks with the control inputs of initial, finial, and dt these are the values I don't know how to properly set. For velocity integration, if you set the amplitude to 3.6625 and frequency to 300 your output after integration peak to peak should be 1.500inch/sec and .530RMS. I thought I could get the same value out of Labview as calculated by hand.

Thanks for all your info above,

M

Link to comment
  • 1 year later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.