Modelling a motor for pid control

Hi All, I'm new to the group, so please be kind :) I was reading Tim Wescott's article on PID without a PhD and it was very us eful although it raised more questions in my mind. I then went over to Tim' s website, which has an article called Z Transforms For Embedded Engineers. The questions I have pertain mostly to this article, in particular to the modeling of motors and how the resulting Z transform of the model is obtain ed. So, here goes :
1) In Section 2.1 of the article, Tim describes a motor system and a result ing Z transform equation of the system. What I am trying to figure out is : Given an analog model of a motor system (and the corresponding physical pa rameters that describe such a system), what would be the process(es) availa ble to obtain the corresponding Z domain model of said system. Do different methods lead to better approximations, and under which conditions is it be tter to use one approximation over the other
2) In section 3.1 of the article, where Tim is describing a better filter, a second order filter model is presented. It would be helpful for me to und erstand the process of obtaining this model. For reference, the model eqn i s eqn (35). Also, why is this model preferred when not using a DSP ( see co mments above this eqn). Are there preferable models when assuming the MAC b ased instruction set of a DSP. I realize this article was written a while a go, so this may be a moot question given today's HW, but it did raise a que stion in my mind
I don't think I'm looking to be spoon fed here. If anyone knows of a good r eference that could answer these questions for me, that would be most appre ciated. And, if anyone has the in-depth knowledge required ( at least from my point of view ??) that would be required to answer these questions, then that would be most awesome.
Be Well
Victor

On Tue, 18 Nov 2014 05:49:33 -0800, Oluwokay Victor Johns wrote:
  Quoted Text Here  
This is probably the link: <http://wescottdesign.com/articles/zTransform/z-transforms.html > The questions I have pertain mostly to this article, in
  Quoted Text Here  
There are two good academic methods to use, and at least one good practical method.
The practical method is to get your hands on prototype hardware and measure it's response (one variation of this process is outlined in <http://wescottdesign.com/articles/FreqMeas/freq_meas.html ; the other method is similar but uses step inputs and a -- in my opinion -- less accurate way of extracting a plant model). For a lot of plants this should be done anyway, even if you start your design with a model derived from first principles.
The less accurate academic method is to use the bilinear transform. There are three variations of this, but basically they all replace the derivative in a differential equation with some variation of a discrete- time differentiator.
If you're going straight from a differential equation to a difference equation, then the easiest ones are the first forward and first reverse difference (I can never keep them straight). When you see
dx/dt
in the continuous-time domain, you replace it with
(x_n - x_) / T (reverse difference)
or
(x_ - x_n) / T (forward difference)
in the discrete-time domain.
In the Laplace domain, you do this by replacing 's' with (z - 1) / (Tz) (reverse difference) or (z - 1) / T (forward difference).
The best one of the lot is the Tustin transformation, which replaces 's' with 2 * (z - 1) / ((z + 1)T) -- there's probably a way to do this directly in a differential equation, but I don't know it.
All three of these variations of the bilinear transform suffer from inaccuracies for system dynamics with characteristic frequencies close to, or above 1/T. In the worst case, if you have a continuous-time system with a pole above 1/T, then both the reverse- and forward-difference transformations will cough up an unstable system model; the Tustin transformation does not, but the model will be inaccurate.
You mitigate this inaccuracy in two ways: one, by keeping in mind that, in a control system at least, if you have dominant plant dynamics that are that fast, then you're either over-modeling or you're not sampling fast enough; and two, by keeping in mind that no matter what you do your on- paper analysis is inaccurate anyway, so you're not losing something that you had in the first place.
The more exact method is the exact transformation (I don't know what the correct name is -- if there's any lurkers that do, please speak up!). The method basically involves finding the system's response to a step in the continuous-time domain, then translating the result to the z domain. It is exact in the sense that if you have an exact plant model in continuous- time, and you know exactly what your delays are from measurement to control output, and if your output is a zero-order hold (i.e., it acts like a regular old DAC), then the z-domain model of the plant will be exactly correct from the point of view of your controller.
I used to be quite attached to the exact method, until I realized that for nearly all real systems the inaccuracies involved in modeling a system from first principles are far greater than the inaccuracies introduced by the Tustin transformation. It's still good to know that it's out there, though.
(All of these methods are discussed in Chapter 7, section 7.8, of my book "Applied Control Theory for Embedded Systems". Just about any decent book in discrete-time control of dynamic systems will talk about the various bilinear transforms; fewer will talk about the exact method.)
  Quoted Text Here  
That is, I'm pretty sure, a transposed direct-form II filter (sorry about not citing it in the text -- the ten-year-ago-me was being a bit fast and loose).
The reason for that form is because (a) you can just use the coefficients directly in the code, and (b) it doesn't demand additional storage for the inputs (contrast this with the direct-form I and transposed direct-form I filter, which I'm pretty sure you can look up on Wikipedia).
There are some issues with coefficient quantization and state quantization which is gone into in great depths elsewhere (but not, alas, my book).
  Quoted Text Here  
It's still a valid distinction, although the effort vs. benefit tradeoff has moved out. With a "real" DSP chip that has hardware looping and a MAC instruction that includes good overflow handling, it's better to take your whole controller and express it as a matrix multiply in block floating point (block floating point _isn't_ in Wikipedia, but you can Google for it). You'll do a whole bunch of redundant arithmetic and multiplying by zeros, but DSP's are good at that and no better at branching than a regular processor -- so you come out considerably ahead.
  Quoted Text Here  
Well, of course I'm going to shamelessly plug my own book -- twice, actually, since I mentioned it already. Here's links:
<http://wescottdesign.com/actfes/actfes.html <http://www.elsevier.com/books/applied-control-theory-for-embedded-systems/ wescott/978-0-7506-7839-1#description>
It's good to have a general background in DSP as well. For that I recommend Rick Lyon's DSP book:
<(Amazon.com product link shortened) dp/0137027419/ref=sr_1_1? ie=UTF8&qid16334458&sr=8-1&keywords=Understanding+Digital+Signal +Processing&pebp16334462082>
Finally, I don't know what your math background is, but strictly speaking you can't really understand this stuff thoroughly unless you have some serious math training under your belt: you can just about convince yourself that it makes sense if you've gotten through a basic course in Calculus (and remember it), but it's a vast, vast help to have a grounding in mathematics up through differential equations. I don't know if difference equations are included in differential equations classes these days, but if you can handle linear multivariate differential equations then you'll find a lot of familiar scenery as you travel through the linear difference equation landscape.