LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

MPC stops working after a short time

Hello, I encountered a problem concerning the CD Implement MPC controller (MIMO). The frontend (fig. 1) and backend (fig 2 & 3) are shown below. The MPC receives constant set-points from the frontend panel and state space matrices, identified using the Matlab “system identification toolbox”. It happens that the MPC always stalls after a certain time (10-30s) regardless of the weights of the system output error. When tracing the issue, it appears that the optimizer has converged to the optimal solution, as the QP dual optimizers output (which states the change of the input vector from the previous step) converges to zero (fig. 4). Checking the “QP dual” block (fig. 5), we saw that not only the output but also the cost function took a value of zero in these cases, which seems strange to me since in all cases there was still an output offset at this point.

If you reset the MPC (e.g. by toggling the “integral action”) the MPC starts changing the inputs again. However, the same problem as described above still occurs after a couple of updates.

We initially thought that this might be a problem with the system matrices (A, B, C, D), but the in-house Kalman filter converges to the actual values in all cases. This was tested for a wide range of output setpoints. Also, it appears that the Kalman filter is also reset when the MPC is, which would explain the behavior in the section above.

I look forward to your response,

Best regards.

0 Kudos
Message 1 of 5
(737 Views)

Because you are a New Member, I'm going to try to be patient (and assume you haven't been reading other posts on this Forum which echo what I'm about to say) ...

 

When posting a questions about your LabVIEW code that "doesn't work properly", please help us by doing the following:

  1. Post the LabVIEW code (the actual VIs).  Do not post (only) "pictures" of parts of the Front Panel or Block Diagram -- we cannot "play" with your code, clean it up, try executing it to see what fails, etc.  (Imagine that I sent you a picture of a printout of some Matlab ".m" files, maybe only the 200 lines where I thought the "bad code" was, and asked your help in finding the bug ...).
  2. If the code uses data supplied by the Front Panel, or read from a file, supply the data as well.  For file input, include the data file.  If just Front Panel settings, do the following:
    1. Make a copy of your VI (this step is optional, but Steps 2 and 3 will change your VI, so you might want to "change the copy").
    2. Set up the Front Panel with the settings you'd like us to use.
    3. Now go to "Edit", and choose "Make Current Values Default".  Send us this version of your code that includes the values you'd like us to use when testing.
  3. Attach this VI.  Note if you are a better LabVIEW Programmer and use sub-VIs, especially if you use a LabVIEW Project file, you can compress the folder holding the Project and its files and attach the resulting .ZIP file, but be sure to tell us which VI or VIs we should examine.

Bob Schor

0 Kudos
Message 2 of 5
(699 Views)

Thank you for your Answer ! I am indeed new to this community and I will take all your input into consideration.

Since we are working with a lab scale plant it is a bit difficult to supply working code as it only works in conjungction with the plant. Do you have any advise for me on how to handle this issue ? (I imagine that simulating the plant with the given LTI-system could work.)

I will provide an executeable code solution as soon as possible.

 

Lukas Scheffold

0 Kudos
Message 3 of 5
(665 Views)

Thank you for the courteous response!  I did look at some of the pictures of code sections you included, but could not tell what fit with what (probably because some of the Block Diagrams were multi-screen), and could see a number of issues that make trouble-shooting your code more challenging.

 

Here are some suggestions that might help you to trouble-shoot your own code (since you clearly "know the subject matter" (i.e. what you are trying to do) better than most of us.  The short-term goal I'm suggesting is designed to make your top-level code show what you are trying to do, and to "hide" the "messy details" of how you are trying to do it.

 

To Hide the Messy Details, bury things in sub-VIs.  For example, in Figure 3, there is a section of code with a Big Black Box around it called "Setting MPC", which takes 5 Variables-on-a-wire that have the name "MPC" at the beginning.  First, gather all these MPC wires and put them in an MPC Cluster (you now have only a single Wire in your VI that has the 5 MPC Parameters in it).  Write a sub-VI called "Set MPC" that takes this Cluster and the SS-Model and outputs whatever the output Cluster is from the VI inside the box.  Note that this sub-VI has three Inputs (the MPC Cluster, the SS Model, and Error In) and two outputs (whatever comes out of the VI shown inside the Setting box and Error Out).  You don't need to pass out the MPC Cluster.

 

The next half-While Loop (grrr -- I hate "pictures of code"!) shows what looks like several identical "pulling apart of three Arrays" (note -- if you are extracting the first four elements of a 4-element Array in the order 0, 1, 2, 3, then you don't need to number the indices -- just "drag down" 4 times and they will take the default values 0, 1, 2, 3 -- I learned this trick from a Forum Post of mine a few years back ...).  Could these also be made into a single sub-VI called with four inputs?  Too bad I can't see the outputs, I might have something useful to say there, too.

 

Since you are using the Error Line to sequence things, and you probably know how Data Flow works, please get rid of the Sequence structure -- you almost surely do not need (or want) it.

 

Here's a goal to set for every VI that you write -- you should be able to see the entire VI, all at once, on a Laptop screen.  The trick to making this possible is to "encapsulate, encapsulate, hide the messy details" and try to reduce your VI to maybe a dozen (or two?) 32x32-pixel sub-VI boxes.  But who wants to look at a bunch of "anonymous" boxes?  Create Icons for each of them!  They don't need to be fancy, they don't need pictures, but they should "convey a message".  I use Text (up to 3 lines of 9 pt letters, with Capitalize off, and sometimes a header line -- here's an example of a VI that displays a Dialog box offering a choice of "Abort" or "Ignore", and another designed to run a "Do Forever" loop (I designed the Icon to look like a big While Loop) that is the Consumer part of a Producer/Consumer pair.

Sub-VI Icons.png

 Another suggestion is to create TypeDefs, especially for Clusters.  When you do that, of course, you'll give them TypeDef a name, but you should also create an Icon for each one.  The reason for this is a "feature" that (so far) only works with Clusters -- if you put a Cluster constant on the Block Diagram, it looks kind of "ugly" and doesn't clue you in on what it does, but if you right-click its border, it transforms into a beautiful Swan (if you gave it an Icon) --

TypeDef Icon.png

 

You might recognize the first element of this Cluster is our old friend, the Error Line, but if we want to use a Bundle-by-name function, and need to define the Cluster, the Icon on the right gives the viewer (which is probably going to be you, a month later, trying to find/fix "bugs") a much better clue what this Cluster is all about.

 

Bob Schor

0 Kudos
Message 4 of 5
(661 Views)

Thank you very much for this detailled answer. I already incorporated many of your suggestions into my work ! Even if they didn't fix the problem directly, they helped. It turns out that that the "Implement MPC Controller" block needs a "Controll Reference Window" to function properly.

 

Thank you very much for taking the time and best regards,

 

Lukas Scheffold

0 Kudos
Message 5 of 5
(635 Views)