Step7 - Funny problem with FB41 CONT_C

I'm using FB41 in a current projrct to control a Steam Pressure loop. During testing everything seem to be working fine until suddenly the output to the regulator valve went to FFFF (-1) and stayed there. After playing around for a while unsuccessfully I finally deleted the Instance DB and recreated and downloaded it and thereafter everything seemed to be back to normal. Unfortunately, the problem came back again late yesterday afternoon and this time recreating and downloading the Instance DB (and the FB41 block itself) didn't help.

One thing I should mention, the program was created using the customer's Step7 V5.4, but I also did a bit of work at home using Step7 V5.3 before going back to the customer and carring on using V5.4 again. I didn't do any work in the area of the controllers at home though.

Anybody seen anything like this before and more to the point has anybody any ideas how I can get the controller to start working again? This equipment is the customers first time using Siemens for the PLC and since it's destined for Pakistan, to say he's a little worried is major understatement!

Hi Roy.

Is it correct from the screenshot that the SP=0.839353 and the PV=0.0121528. Then the output should increase.
What are the integration and derivative parts (is TI=4e20 or what does that mean ?)
Maybe you can upload the IDB and then zip and post the project here.

It is also difficult to figure out with static data only.
If you have some trends with all the relevant data, it will also help.

Yes, as you say the output should increase to 100% eventually, but I assumed that would be the usual 27647 (or whatever it is). Once it gets into this state you can change the SP (and the PV) any way you like and the output doesn't move. Unforuntately we'd only just started testing this, so we've no trends, but while it was working (about an hour or two) it looked fine and reacted exactly as expected to any parameter changes that we made.

I'm not going to be back at the customer's site until Monday, but I've got a copy of the archive with me so I'll try and hang it on.

Hmm, the archive is about 100kB too big, I'll have to try stripping it down a bit first.

Looking in the help for CONT_C it does not look like it has bumpless transfer (!). From the diagram it looks like the MAN switch simply selects the calculated output or a manual value to be passed through. I would check if the MAN switch also resets the accumulated values so that it doesnt regulate wildly or becomes saturated when it goes back to auto.

If you can switch back and forth between manual and auto, then you can also try that.

edit: The above is wrong. See later post. The diagram is too simplistic to tell everything.

Also, is there a way to avoid anti-reset windup ?

I'll ask the customer to check that out, if he's got time, otherwise I'll have a look myself on Monday.

Under normal circumstances when the plant starts up I'm running a 6-stage ramp from the value of the initial PV, so the non-bumpless transfer shouldn't be a problem in real life. However, during testing we were using a 4 - 20 mA source which in one mode bumps the output up or down in 4 mA steps, so maybe we confused something in the process, but I still can't understand why we can't get rid of the problem by downloading again. I think I'll try completely deleting the online blocks and download the whole program again, on Moday.

It should be possible.
According to the online help:
"Manual Value
It is possible to switch over between a manual and an automatic mode. In the manual mode, the manipulated variable is corrected to a manually selected value. The integrator (INT) is set internally to LMN - LMN_P - DISV and the derivative unit (DIF) to 0 and matched internally. This means that a switchover to the automatic mode does not cause any sudden change in the manipulated value."

So it should be possible to switch to manual, turn down the output, and then observe how it regulates when you switch back to auto.

Also, did you specify LMN_HLM and LMN_LLM ? Manipulated value high and low limits. I think that these will protect against antireset windup.

Also, did you specify LMN_HLM and LMN_LLM ?

Click to expand...

No, we're not limiting the output on this loop, the customer is of the opinion that it is not usually necessary. The plant is a caustic soda recovery plant of which many have been produced using PMA controllers, but their customer for this plant has insisted on a Siemens PLC (actually it's overkill for this job!).

If there is an integrating part in your PID, and there is as far as I can see, then you will need to do something about antireset windup.
It can well be that the problem you see is a PID that has saturated and cannot come back to realistic values again.

I'm not having much joy trying to reduce the size of the program by conventional means. Are there any directories whose contents I can simply delete which will not have any effect on the project as such, perhaps because the data is basic Siemens S/W which is common to all projects and can simply be copied back in afterwards?

Roy,

Create a new project with no hardware config. Copy the blocks from your project to the new project and then archive that - should be much smaller.

Simon

Thanks Simon, that did the trick - just scraped in a couple of kB under the limit!

RMA said:

Anybody seen anything like this before and more to the point has anybody any ideas how I can get the controller to start working again? This equipment is the customers first time using Siemens for the PLC and since it's destined for Pakistan, to say he's a little worried is major understatement!

Click to expand...

Hi RMA
The reason why this happens -> some of your input value is in WRONG format and perhaps negative (ex. value should be REAL but it is DINT). I mean, inside the PID- happens multiply/divide operation by ZERO and "game is lost". Only way what you can do -> download the instance-db and PID- starts working again.
You can test this -> set the GAIN value in douple integer format "-1" -> and supprise, supprise...

My advise for this problem -> check all your variables they must be in right format!

Pete

Roy, I've simulated the project you posted and the only way I can get the output to go to FFFF is as [FIN]Pete reports. The integral term goes to DW#FFFFFFFF when the gain is a not a valid floating point number so restoring the gain to a correct value does not allow the system to recover. Is there an MMI that is used to set the gain and could the MMI be responsible for an overlapping write ? Suggest you put in some code to monitor the gain in DB4.DBD18 and compare it with 0.73 and then sound a klaxon or the like when it changes - you might find out out what else was being done at the same time (Give the MMI references a good check as well of course)

Any indirect addressing being done in this instance ? - sorry, couldn't resist

Simon and Pete, thanks a lot - there is an HMI being used on the project and it's a non-Siemens one. The customer has used it before with his PMA controllers, but I've already noticed that he doesn't really understand the difference between INT, DINt and REAL. We were playing about with inputting the PID values from the OP when this happened - now I know where to look on Monday.

And no, I'm glad to say there's no indirect addressing needed for this job! As I mentioned, even the 315 is overkill really.