From help-octave-request at bevo dot che dot wisc dot edu Thu Nov 6 23:56:09 2003 Subject: Re: sys variables for control theory From: A S Hodel To: Doug Stewart Cc: help-octave at bevo dot che dot wisc dot edu Date: Thu, 6 Nov 2003 22:54:25 -0600 There's a few details on system theory at the front of this note; developers interested in the controls toolbox should scroll to the end of this note for some of my own questions and observations on the OCST (octave control systems toolbox) On Thursday, November 6, 2003, at 10:56 AM, Doug Stewart wrote: > > A S Hodel wrote: > > The reason behind octave's restriction is to ensure the ability to > > convert between > > rational polynomial representations (tf, zp) and state-space > > representations. That is, > > a PID in the form described is not physically realizable, that is, > the > > transfer function > > is not proper. A hardware (or software) > > implementation requires an extra pole with very fast settling time > > (relative to open loop > > poles and closed loop design poles). > > > > With all due respect to A S Hodel, I will just note that my students > build and test this PID opamp circuit every year and then they model > it in "C" and so it is realizable. Also you can buy them off the shelf > for industry. I'm well aware of such systems. I stand by my statement that (a s^2 + b s + c ) / s is not physically realizable, nor is any rational polynomial n(s)/d(s) where degree(n) > degree(d). Consider these observations: - An op-amp has its own frequency response with a cut-off frequency around 1e5 to 1e6 Hz. It's a nonlinear circuit, but can be approximated by a pole (or poles) deep in the left half complex plane. - The idealized model (algebraic loop) typically used in sophomore circuits classes is ok as long as one works in telephone-frequency audio or lower frequencies. - More details on op-amps and other microelectronic circuits and their small-signal models can be found in microelectronics by, e.g., (1) Richard C. Jaeger, (2) Streeman, or (3) Sedra and Smith. The dynamics of an op-amp (and, for that matter, ANY semiconductor based circuit) is due in part to the capacitance inherent in any p-n junction. My area of expertise is control systems/numerical methods, but my "lunch buddy" has been teaching microelectronics for nearly two decades, so this is a regular topic of conversation for me. - d/dt is a borderline non-causal operation, since backward differentiation (f(t) - f(t - delta) )/(delta) doesn't work until delta is exactly 0. That is, a pure PID is not physically realizable. - Finally, the existence of a fast pole deep from a physical PID in the left half plane (eventually) will have an impact on a system's root locus, so a proper treatment of a PID ought to include some treatment of its behavior. > Now for the real question. > This conversion between tf zp ss representations is where the work > will be needed. > > Would it be OK if we checked for proper form at the start of the > conversion and reported an error at this point? This could be done. Conversions to and from state space often happen in the process of doing block diagram manipulations, e.g., sysgroup, sysadd, sysmult, etc. After reading the many posts on how to handle empty matrices (0x0 is not 0 x n nor is it n x 0 ... etc), I'm wondering what the "best" way to handle non-proper systems is. The issues are speed and numerical accuracy. I occasionally sacrificed the 2nd of these for the first, e.g., sysmult( tf1, tf2) just multiplies the two polynomials rather than doing a sysgroup, sysconnect operation. > OR > > Should we allow improper form for zp ss and tf and only do the > checking when we try and get a time space result ie. "step impulse > bode? rlocus?". Bode(PID) (even if it's non-proper) should be fine. rlocus might also work o.k.. However, this approach will run into problems as outlined above. I think this needs to be dealt with in a more comprehensive fashion. All that said, these are good questions. Other questions to ask (they;'ve been on my mind for several years, but I just haven't had time to address them): - Since Octave now appears to be supporting cell data structures, should the OCST be rewritten to support MIMO tf and zp formats? Currently MIMO systems can only be implemented in state space form. If this is done, one wonders how to handle MIMO "minimal realization" issues: for example, since a PID is not physically realizable, how should one handle a command like minreal ( sysgroup (PID1, PID2, PID3) ); Normally, I'd go to state space and extract controllable/observable subspaces, but that gets lost here. - Octave's OCST was written before either Octave of MATLAB had user-defined data types (we wrote most of it around 1993-1995), so it just uses a structure variable. Octave has some ability for user-defined data types in C++ class structures. MATLAB has user-defined data types in m-file form (a subject of occasional discussion in the octave mailing lists). Is it worth the effort to implement a linear system data type directly in Octave (or octave-forge), then rewrite the current toolbox to use the corresponding member functions, or should we stick with the current data structure? - Octave's OCST was written to permit mixed sampled-data and continuous time systems. I did this to maintain compatibility with a NASA-internal simulation tool that, as far as I know, is no longer used (they've migrated to simulink in order to match industry) and is export-controlled, so it will likely not ever be made public domain. Is there any reason to maintain "mixed" systems (continuous and discrete-time states and outputs)? - Should we change octave's OCST function names to match those of MATLAB, where possible? For example, one could use ss, zpk, tf instead of ss2sys, zp2sys, and tf2sys. However, unless we define a new data type, we're stuck with sysadd, sysmult, sysgroup, sysconnect, etc. With all of these questions and the ongoing discussion/revision of is_stabilizable, dare, etc., it sounds like the OCST is due for a revisit ... with due attention to such references as at article{lau85, author = {A. J. Laub}, title = {Numerical Linear Algebra Aspects of Control Design Computations}, journal = {{IEEE} Transactions on Automatic Control}, year = 1985, volume = {AC-30}, number = 2, pages = {97--108}, month = {February} } at book{patlauvan94, editor = {R. V. Patel and A. J. Laub and P. M. Van Dooren}, title = {Numerical Linear Algebra Techniques for Systems and Control}, publisher = {{IEEE} Press}, year = 1994 } etc. A. S. Hodel, Associate Prof. Elect. & Comp. Eng., Auburn University ------------------------------------------------------------- Octave is freely available under the terms of the GNU GPL. Octave's home on the web: http://www.octave.org How to fund new projects: http://www.octave.org/funding.html Subscription information: http://www.octave.org/archive.html -------------------------------------------------------------