From Part I of this topic, we learn the basics of Scilab serial communication toolbox and construct a simple GUI to handle the connection and data transfer in form of ASCII strings. Things seem to work fine with general commands and responses, which so far are displayed on Scilab console as status message or parameter value retrieval.
For control system analysis and design purpose, data need to be plotted and processed in Scilab. So the received data string must be in some valid format ready to be executed. For example, suppose we request the CM1 board for a set of sampled input and output values, say, 100 points. It is preferable that the returned string be in a matrix format so that Scilab command execstr could be used to construct a matrix in the workspace easily. For such convenience, RED provides a command “scilab on” to append a variable name dstr and square brackets to the raw data. Then we can pass the whole received string to execstr without having to edit anything.
At present I am quite busy developing the controller module (CM1) together with the supplement DC motor simulator (EM1), as introduced in my Embedded Prototypes for Control Engineering article. The main purpose of these low-cost embedded systems are to serve as educational tools for control engineering, though, if one wishes to do so, the universal controller board can be used in certain real applications with up to two feedback loops.
Basic serial port communication in ASCII format is implemented on the target board for a user to issue commands and receive response, as well as capture data for analysis. Any UART terminal program such as HyperTerminal or CoolTerm can be used for such purpose. For classroom use, however, integration with Scilab would significantly improve user-friendliness of the board. What we need are a couple of Scilab functions to access the serial port. The required operations are open, read, write, and close. No need to be fancy. I have found The Serial Communication Toolbox on the ATOMS packaging system that provides just these basic functions and is very easy to use.
PID controllers are widely-used nowadays due to their ease of implementation and deployment, with many commercial products available on the market. To achieve desired performance, the controller gains need to be adjusted properly. Among many tuning schemes in the literature, the so-called Ziegler Nichols Frequency Domain (ZNFD) approach is one that can easily be understood and applied to a physical system. In this article we demonstrate simulation of manual ZNFD PID tuning, and then extend to an autotuning procedure using relay feedback. Basic theory can be read from  and our previous article Digital PID Controllers*.
From H-infinity Control of DC Motor Part I : Plant Modeling and Controller Synthesis, we discuss essential steps required to achieve a controller for DC motor plant, from estimating a plant model by least-square identification, adjusting weighting functions, formulating a generalized plant, synthesizing, and performing controller model reduction. Data captured from real DC motor is provided in the Scilab script dcm_lsid.sce. Before we move on to implementation phase in this part, if you have not done so, I encourage you to try step 1 – 5 in Part I in Scilab by running the scripts in this order: dcm_lsid.sce, kreduced.sci, dcm_hinf_st.sce. You may leave everything untouched on first attempt. When you get the idea how things work, start playing around with weighting functions, adjusting gamma variable, or using the iterative h_inf function in place of hinf.