Emerson Exchange 365

Julian,

I noticed that you have shown the BKCAL_IN1 parameter on the MPC-PRO1 block and wired the BKCAL_OUT parameter of the PID1 block to it. This wired connection is not necessary, as when you configure the Properties MPC-PRO block and use an internal or external reference (in this case, would be an internal reference) to the block and parameter you wish to drive - PID1/CAS_IN or PID1/RCAS_IN - then the BKCAL connection is made for you. I would recommend deleting that wire.

It is the BKCAL_IN1 value that the MPC block is seeing as limited - you can check this on-line by looking at either block's applicable parameter.

It looks like you're using PID1/RCAS_IN in the configuration of the MPC-PRO block, based on the value of 25 shown for RCAS_IN. The BKCAL parameter for the RCAS mode is RCAS_OUT, which also supports the deletion of the connection to the BKCAL_IN parameter.

The Mode of both the PID and AO blocks were shown as MAN in the online screen shots you provided. To have the MPC-PRO block work with the downstream blocks, the Mode of the PID block will need to match the configured reference, and the Mode of the AO block will need to be CAS. In PredictPro, the MPC/Local selection sets the mode of blocks downstream to the MPC block appropriately, based on the referenced connection in Properties for the MV's; with the In1 (MV1) valued configured to RCAS_IN, changing to MPC in PredictPro will change the downstream block to RCAS mode.

The configuration of MV1 in Properties includes a high and low limit on the MV; check to be sure that those limits match the OUT limits of the PID block.

Hope some of this helps!

In reply to JDWheelis:

Hello JDWheelis
Thanks for your reply, please find below my reply to your observations

I deleted the wire from the bkcal_out of the PID to the mpc as you suggested, and verified the operating mode of the PID and AO, they are in remote cascade and cascade respectively.

I set the mpc in manual because, since it does not have a model yet, it can't go to auto. Further, even if I set the mpc to auto it says "auto/manual".

The mv1 of the mpc was set to pid1/rcas_in from the beginning. Actually I forgot to mention that I can start the test of the mpc predictpro, the error pops up when going from +5% to -5% (63.5 °C to 34.5°C according to my calculations) which is inside the setpoint limits of the pid1 and mpc mv1 out limits.

Right now I started another test taking into account your advise of deleting the bkcal_in wire. In about 15 minutes I'll be posting if it worked.

In reply to Julian Navas:

Well, the test aborted sooner than I expected, but I took some time to gather more information and update the original post.
As you can see, the SP limits of the controlled variable (air temperature) are 20 to 80 °C, and those are also the limits of the manipulated variable (PID setpoint).
Double checked the SP_HI and SP_LO limits of the PID1, they were 0-80, I changed them to 0-100, but the test aborted anyways.
Honestly I can't see what am I missing.

Would it be the range suppression parameter of the test? could it be a discrepancy between the PID PV range/units (-99 to 208°C )and the AO input range/units (0 to 100%)? maybe I should try ignoring errors altogether?

In reply to Julian Navas:

There may not be anything helpful there, but could you show the config tables for the MPCPro variables? Double click on the MPCPro block to invoke properties. Then select the >>More Data option to show all of the parameters. Then screenshot each tab... MV, CV, LV, and DV. It's an easier way to visualize the configured limits, for me anyway. If you have changed the limits on-line, please upload before grabbing your screen shots.

In reply to James Beall:

Hello James,
It makes a lot of sense! thinking about it, when going from +5% to -5% in the test the PID goes down to 0% output, which is exactly the inferior limit of PID1/OUT_SCALE parameter, so the MPC block sees it as reaching a limit. I remember something similar occurred on a test months ago, but in that case it was the PV reaching a limit. Anyways, that case was more evident and I could correct it quickly.

At the moment of your reply I already started a test ignoring the error and it proceeded normally, but now I know to have this in consideration for future tests

In reply to Lou Heavner:

Hello Lou,
I'll be doing it in a minute, please find the pictures in the updated post

In reply to Julian Navas:

Julian,
Both Lou and James provided good information and further explanation on your MPC application. I looked over your additional screen shots and noticed that the limits on the MV (PROC_IN1) are 20 to 80, while the PID scaling - which is set by PV_SCALE - is -99 to 208 degC. I believe the MV limits provide additional limits on the SP of the PID block, as the MV is connected to the SP of the PID through RCAS_IN.
Try changing the MV limits in the MPC-PRO block properties to -99 and 208 and run the test again without ignoring errors.
J.D.

In reply to JDWheelis:

Hello JD,
Yesterday the test finished successfully after checking on the "ignore errors" option, but it was certainly because of the PID out was dropping to 0% to turn off the heater when the mpc changed from +5% to -5%. I could do what you suggest however those limits are physical constraints of the process so i guess it is better to leave it like that.

Finally, Thank you all for your will to help and for providing your insights, I am eager to learn more of deltav with help of experts like you.

In reply to Julian Navas:

Julian,
Even though I recommended "ignore errors", you have to be careful about this. If an MV PID loop is low limited on its OUT, and the step test pattern move the MV PID SP lower which further drives teh MV PID OUT to the low limit, the model will not be correct. You can move the MV PID SP up by slightly more than the test SP move so that when test runs, the MV PID SP will be just obove low value to the low value plus 2*step size.
James

In reply to Julian Navas:

Julian,
Since the 20 to 80 degC are physical limits on the MV / SP of the PID, then you shouldn't change them. PredictPro is doing it's job in keeping those limits in play during the test. The other thing you could possibly do is the reduce the step size; instead of a 5% MV change up and 5% down, if a 2% step would cause sufficient movement in the temperature (PID's PV), then sufficient data could be gathered to generate a good model.
As James says, when limits are reached, the model can and most likely will be impacted. Choosing a smaller step size or moving the initial value of the MV as James suggested - or a combination of both - could help reach a good model for the process.
J.D.

In reply to JDWheelis:

James, JD
I think I understand what you mean about moving the MV SP (pid remote set point) so it would not get as low as the PID OUT low limit, however, the pid drops to 0% OUT and this happens no matter what step change I use because, as far as I understand, turning off the heater resistance is the fastest way to cool down the air in order to reach the next set point. In other words, that's the pid's way to deal with the change in set point to cool the air as fast as possible, then it gradually increases the heater power when the temperature profile is getting close to the new (lower) SP.

About the model being impacted, yes, I could see that last night after finishing the test that the model was not good at all (0.46 fit goodness).

I set the initial temperature and the step change size based on the normal temperature range of the dryer operation, which is about 40 to 65°C. I'll try a new test now following your advise of cranking up a little the initial steady state (55C maybe) and do a smaller step change to see if the PID doesn't turn the heater all the way down.

Meanwhile, if you allow me to slide in here another question fairly unrelated to this topic: I'm getting an OPC error 80040154 -class not registered- when trying to connect simca online (x64) to OPC.DeltaV.1 server. Sounds familiar to anyone? should I make another post?

In reply to Lou Heavner:

That's right, this process is non linear, the temperature final steady state depends both on the step change and the initial steady state, and also the process cools slower than it heats. That's the reason I wanted to capture the whole dynamics of the operation range of the dryer with the first set of conditions I used.

In reply to Julian Navas:

Julian, regarding the OPC error, I would suggest another post on that topic. The folks who are likely to have a good answer on OPC probably won't be looking at a post on MPC - I know, it's just one letter different! ;)