# LabVIEW

cancel
Showing results for
Did you mean:

## Finding Settling Time in an Analog System

I am currently trying to make a VI for transient analysis (and will try to provide as many details as possible, for you all!). My approach and thoughts are as follows:

1. Identify Steady State (SS) - Measure bandwidth and average SS value.

2. Identify when transient begins - value exceeds bandwidth

3. Measure Transient Response (TR) - measure bandwidth

4. Detect new SS region - find settling time to end TR and begin SS function

5. Measure SS again - use all this information to calculate overshoot, rise time, peak time, settling time, etc.

As background, I am designing a modular program to test on several different analog systems, regardless of levels and other extrema. There is expected to be voltage droop, so most other queries about settling time have been mostly unhelpful as I can't make the cut off a simple "if signal <= +/- 2%" (poorly noted, but you get the gist...). Also, since these systems aren't known controllers and can't be modeled as a second order system easily, I can't take the classical 4Tau approach to settling time.

For this reason, I started thinking rather than begin a new SS function, the TR function would have to incorporate some form of memory or buffer, find out what the SS value is, then go back and find the time the 2% threshold was achieved. That, however, seems pretty difficult! I will be sampling up to a rate of 10kHz, albeit usually less, I would like to design for that possibility. That creates quite the buffer, however, and I am unsure how to implement that.

The question:

Am I thinking about this the proper way? Does anyone have thoughts on how to do this better? If so (or not), how would I go about implementing this?

Especially with the buffer concept, I am at a loss of how to implement. I would like to stress, since the voltage droop will not be uniform between UUTs, I can't put a set value in, which is the current blight of this endeavor...

- Pearse

Message 1 of 5
(2,450 Views)

## Re: Finding Settling Time in an Analog System

I want to add: I am capturing data with cDAQs and DAQmx. This is to clarify what I mean by "Analog System" in the title, just referring to the UUTs output.

Message 2 of 5
(2,449 Views)

## Re: Finding Settling Time in an Analog System

Specific characteristics about the behavior of your devices and the data they produce will be important to the algorithm you put together.  You've already mentioned a reason why a standard, idealized method won't work for you.  So now you'll need to invent your own.

I've done a few of these "seat of the pants" algorithms.  They tend to be fairly easy to get *nearly* right with typical data and very difficult to make robust against all manner of untypical data.  After all, there's an near-infinite number of ways that data could (theoretically) differ from typical -- so which ones are worth exploring and guarding against?

A few practical tips:  I've often used linear regression as a strong clue about "settling."  You can look at both slope (how far does it deviate from horizontal?) and correlation coefficient (which accomplishes something similar to "standard dev about the best fit line".  In fact, maybe it's mathematically identical, I don't recall now.)

Another kind of thing I've tried:  find the % of samples over a given time period that fall outside a window around the average value (might be mean or median, depending).   Window size often scales with average value, and may have a constant component too such as +/- (1% of Vavg + 0.010 Volts)

It's usually been trickier identifying the point in time that marks the beginning or ending of "settled" behavior.  The nature of the data processing I've done has tended to make this more subjective.  The best generic tip I'd give is that it's usually best to have a simple, well-understood method for defining the interval boundaries than to have a much more complex but more theoretically perfect method.   Example: find where the best-fit line of "settled" intersects the best fit line of "transient".  The results may sometimes be crude, but the failure modes of such a simple algorithm are easier to predict and guard against.

Out of time, hope this helps a little on the general thought process...

-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 3 of 5
(2,426 Views)

## Re: Finding Settling Time in an Analog System

Great points. I appreciate the feedback. If I may, perhaps some additional detail will help!

I am testing electrical power systems (120/208V), specifically measuring voltage and frequency transients to identify droop and response, among other things. So although each system will exhibit significantly different transients, regardless we do know the voltage should be 120.0V per line and 60Hz, but depending on loading or unloading the bandwidth for droop may be a couple percent.

I've thought about linear regression a bit. Take the slope and look for a near zero crossing, however, since I can't guarantee how many peaks or troughs the signal will oscillate through before hitting that +/-2%, it's a bit dicey. Nonetheless, one could assume that if there's little distortion the slope would decrease as it settles, but my initial thoughts for worry are high frequency noise could ruin that. I'm interested about the sampling concept, though. Ultimately what I'm pulling from this is I may have to collect and observe data, then make inference on my cases...

Thanks much, but I would love to keep discussion going... All thoughts help a ton.

Pearse

Message 4 of 5
(2,418 Views)

## Re: Finding Settling Time in an Analog System

I know nothing about what to look for when testing such power systems.  My comments were based on picturing more of a DC signal that occasionally changes and settles into a new level.

I would imagine that in theory, you could transform the actual AC wave into a set of DC-like data where you have a cycle-by-cycle characterization of freq and amplitude vs time.  These processed measurements would look more like the time history I pictured during my earlier comments.

-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 5 of 5
(2,397 Views)