All Lab sessions are conducted in Lab:A of Dept. of Automatic Control (Entry level of M building)

• Instructions
• Class interfaces
• Sign-up

• Sequence control of a bead sorting process
• Sign-up

If you have selected to install JGrafchart on your local machine you may have problems starting it if you are running Linux or Mac and have python3 installed.

In that case you should change row 26 in /bin/run so that the argument to print is included in a set of parentheses:

print ("ERROR: {}".format(msg))

Lab responsible: Claudio Mandrioli.

An home version of lab 3 is now ready. Inside the zip folder you will find the manual for the laboratory exercise and the needed matlab and simulink files. The manual also describes how to submit your solutions to the lab. The laboratory is now INDIVIDUAL: each of you has to submit his own solution and we will check for plagiarism.

DEADLINE: You have time until next Wednesday for submitting your solutions, that is the 1st of April at 23:59. Two submissions are allowed, including the first one. This means that if you first submission is not good enough you will receive feedback and have one more (and last) chance to submit your solutions. It will be possible to ask further questions after the first submission as well.

SUPPORT: I have scheduled a Q&A session on Zoom for Monday morning from 10:15 to 12:00 (Zoom invitation in the email, if you cannot find it send an email to Claudio Mandrioli). The idea is that I will discuss questions that you send me IN ADVANCE to the session. In the remaining time we can eventually discuss new questions.

COMMON ISSUES:

• If you get an error like "the specified function 'vel_float' in C Caller block if filtered out because it is undefined in custom source files or library files." it is most likely that you have syntax errors in the C code that prevent it from compiling. Another option is that you have renamed functions or moved the files, which you don't need to do for this lab.
• The comments in the C file suggest you to write the states of the controller as global variables (i.e. define them outside of the function definition). This is an alternative to the use of the static keyword proposed in the lab manual. Both solutions can work equally. The only caveat is that the different functions share the same global scope (not surprisingly, by definition), therefore if you use the global variables approach you will need to use variables with different names in the different controllers (otherwise you get a compile time error).
• When you run the model all of the C functions need to be able to compile, not just the selected one. Therefore if you have a syntax problem in one of them, it won't run, even though it is not the functio you have selected.
• Debugging tip for the fixed point implementation: write down at each step the encoding of each variable (Qx.x) involved and trace it through the control algorithm. This should guarantee you that everything is as expected.
• Effective debugging approach: if your model crashes on opening or while running and you cannot make up your mind about why there are couple of effective approaches to spot the bug. Comment out the C code that you are currently using until you spot the line that makes it crash. Or, re-download the model and port your C code  piece by piece. The idea is that you should be able to trace exactly what is breaking the code.
• Syntax mistakes in the # commands (e.g. #include or #define) give weird errors and the compiler has a hard time giving you good debugging messages. Mainly because these commands are not really part of your code, those are commands passed to the compiler before compilation. In fact they describe actions to be done before compilation: like substituting every K symbol in the code with 123.123 or including some library. A common mistake is writing #define K = 123.123; the correct syntax is #define K  123.123 .
• The range [511,-512] (i.e. 10 bits representation) holds only for the A/D reading and D/A writing. The other variables can take larger values.
• In the fixed point implementation, make sure you remove you remove the fractional bits only when actually needed, otherwise you will have significant loss in precision and  performance.
• The controller should have good performances, e.g. no oscillations, no static error, rejection of the load disturbance, among others.
• If your control action u is staying fixed or close to zero all the time usually is because you are removing "too many fractional bits" and hence removing also the integer part of the variable.
• There are some compatibility issues with macOS Catalina 10.15.4 , this solution seems to work though: https://it.mathworks.com/matlabcentral/answers/512901-mex-xcodebuild-error-sdk-macosx10-15-4-cannot-be-located#answer_421931 . This could be needed if you have never been able to run the simulink model (not even as it is when you download it) and you get error messages related to the MEX tool, or clang tool or C compilation in general.
• It's good to keep at hand a list of the C operator precedence rules (like https://en.cppreference.com/w/c/language/operator_precedence) and double check that the compiler does what you  expect it to do.