1 0 / 1 1 / Due : Fri. Nov. 2 nd / Mon. Nov. 5

Transcription

1 ENGG*4420 Real Time System Design Lab 3: Embedded Real-Time Controller of a Hot Air Plant using RTOS µc/os-ii on Altera NIOS II TA: Matthew Mayhew (mmayhew@uoguelph.ca) Due : Fri. Nov. 2 nd / Mon. Nov. 5 th 1 1

2 Today's Activities Lab 3 Presentation Lab 2 demos 2 2

3 Lab 3 Development Environment LabVIEW 2009 software Nios II IDE Altera Nios II Embedded Evaluation Kit 3 3

4 Simple Hot Air Blower PT 326 Process Trainer 4 4

5 Lab 3 Architecture Input Voltage Control Signal UART Write Serial Read Altera Nios II LabVIEW Plant Comm. PID Controller Plant Model Operator Input UART Read Serial Write Measured Voltage Feedback Signal 5 5

6 Lab 3 Plant/Controller Features 6 6

7 Lab Requirements Plant interface Input from plant to controller Output to plant from controller PID control system Implemented on Altera Operator Interface LCD display Operator input 7 7

8 Plant/Controller Interface Input from Plant to Controller Plant output voltage (from LabVIEW Altera) Output to Plant from Controller Heater control (manipulated variable from PID, Altera LabVIEW) Communication implemented using serial communication with termination character. 8 8

9 Operator Interface - Inputs Input from LCD touch screen ON/OFF signal Auto/Manual mode control Setpoint voltage (Auto Mode) Voltage input (Manual Mode) 9 9

10 Operator Interface - Outputs Output to LCD Voltage/Time graph (Lab 1) + voltage setpoint Current sampling time Voltage reference Voltage output (output to plant) Proportional gain (Kc) Integral time (Ti) Derivative Time (Td) Current time (HH:MM:SS)

11 Operator Display

12 PID Control System Continuous Time Implementation t [ e ( t ) + 1/ T e ( t ) dt + T p i 0 d mt ( ) = K d ( e ( t )/ dt ] m(t) = manipulated variable (output to plant) e(t) = plant error = r(t) c(t) r(t) = plant setpoint c(t) = controlled variable (voltage from LabVIEW) K = Proportional gain p T = Integral time i T = Derivative time d

13 PID Control Discrete Time Implementation s ( n ) = s ( n 1) + e ( n ) m ( n ) = K e ( n ) + K s ( n ) + K [ e ( n ) e ( n p i d 1)] K = K T / T i = p s i K = K T / T d p d s Where s(n) is the sum of errors T = sampling time = t s

14 Implementation Requirements LabVIEW model Two tasks: Plant Model task, communication task. Data communication between tasks using queues. Serial communication using termination character. Temperature and voltage graphs displayed on front panel. Altera implementation Must employ at least three tasks (e. g. controller, operator input, timer, etc..). PID controller must have a dedicated task. Bumpless transfer between manual and auto modes. Semaphores used for data synchronization. Accurate timer. Synchronization with plant when controller is turned ON. 0 V output from Altera when turned OFF

15 Implementation Requirements Note that ALL timing requirements discussed in the lab manual MUST be implemented. Task priorities MUST be discussed and justified in your report. Time delays on time critical tasks MUST be discussed and justified in your report

16 Real-Time System Implementation pg of lab manual

17 Real-Time Constraints Control system must operate with a sampling rate of [ ] ms. ON/OFF buttons Sampled every 2-5 seconds. Auto/Manual controls Sampled every 2-5 seconds. Vinput and Vref buttons Sampled every 1-2 seconds. Clock/Time Must execute every second to keep accurate time. Operator display must be updated every 5 seconds

18 Task Priorities µc/os-ii can manage up to 63 tasks. OS has it s own system tasks. It is recommended that you DON T use priorities 0-5 (Highest priority = 6) as they are reserved by the OS. Each task must be assigned a unique priority level. The lower the priority number the higher the priority of the task. µc/os-ii will always execute the highest priority task ready to run

19 Assigning Task Priorities Assigning task priorities in complex real- time systems is a difficult job. Noncritical tasks should obviously be given low priorities. Most real-time systems have a combination of soft and hard requirements. Soft RT Systems: Tasks are performed as quickly as possible to achieve better system performance, but deadlines can be missed without system failure. Hard RT Systems: Tasks must complete by their assigned deadlines

20 Rate Monotonic Scheduling (RMS) High Pr rio ori ity Low Task Execution Rate (HZ) Priorities are assigned based on how often the tasks execute. Tasks with the highest rate of execution are given the highest priorities

21 Rate Monotonic Scheduling (RMS) RMS makes a number of assumptions: All tasks are periodic (occur at regular intervals). The CPU must always execute the highest priority task that is ready to run. Given a set of n tasks that are assigned RMS priorities, the basic RMS theorem states that all task hard-real time deadlines are always met if the following inequality holds: E i 1/ E i nn (2 n 1) T i i

22 Rate Monotonic Scheduling (RMS) Where E = maximum execution time of task i i T = execution period of task i i n= number of tasks to be scheduled E /T = the fraction of CPU time required to execute task i i i Note: CPU use of all time-critical tasks should be less than 70%. 1/ Number of Tasks n(2 1 n 1) E i nn (2 1/ n T i i 1) Inf

23 Useful Functions & Structures Several functions exist to implement delays. OSTimeDlyHMSM(); OSTimeDly(ticks) the most reliable; MANUALLY TIME LONGER DELAYS!! Semaphores and Mutexes should be used to guard shared resources. Queues and arrays can be used to pass values between tasks

24 Useful Functions & Structures OSStatInit() can be used to check current CPU usage. Must be called after OSinit() and before OSStart(); Must be called from a single starting task!! Create initial task OSStatInit() Create other tasks Delete initial task; With OSStatInit() running, checking OSCPUUsage will return current CPU Usage. DOES NOT NEED TO BE RUNNING DURING DEMO!

25 Demo Front Panel Plant Response PID Control Offset Over/Undershoot Steady-State Oscillations Bumpless Transfer Operator Panel Required Information Controls Accurate Time Synchronization

26 Lab Report General structure outlined in lab manual. Introduction & Problem Description System Requirements Remember to link implementation to actual physical system. System constraints. Background Benefits/overview of Altera and µc/os-ii

27 Lab Report Implementation Top-Down implementation of system. Present overview of task organization in LabVIEW and Altera. Description of LabVIEW and Altera implementations. Include diagrams and code snippets where appropriate. Discuss task organization and priority selection. Simulation results (PID and CPU usage). Discussion of parameters. PID on LabVIEW vs. Altera. PID functionality over changing model. Timing issues/implementation

28 Deadlines and Marking Lab 3 is worth 12%. 6% for the report, and 6% for the demo. The Demo is due Nov. 2 nd /Nov. 5 th, 2012 in the Lab. The Report is due Nov. 2 nd /Nov. 5 th, 2012 in the Lab. Physical and Electronic copy. A signed group evaluation sheet must be submitted with the lab report. Do NOT include student numbers with the lab report