S7-200 PID to control temperature.

[Ken J]

Has anyone done it with the WinCC Version4 software. In the Siemens manual they recommend using an interrupt routine to read the Analog value. They also recommend using an interrupt routine to do the PID.

My question is it necessary to put them in interrupt routines or can it be done in the main program, OB1?

 

[khalil]

Has anyone done it with the WinCC Version4 software. In the Siemens manual they recommend using an interrupt routine to read the Analog value. They also recommend using an interrupt routine to do the PID.

My question is it necessary to put them in interrupt routines or can it be done in the main program, OB1?

I've never done it before, but in microwin there is a PID wizard that will create the subroutine for you , and all ye have to do is call it on every scan( use sm0.0 bit) and you can read the analog value.


I hope this is help.

best regards.khalil

 

[Ken M]

I assume the reference to WinCC V4 was a typo - it's got nothing to do with S7-200 programming.

One of the key reasons for having the PID control in an interrupt routine is to maintain a fixed calling interval for the PID software. If you call it in OB1 the code has no way of knowing how long has elapsed since it was last called, and almost certainly this will vary on every cycle. When the code does the integral and derivative calculations especially, it needs to know the time period over which any change in error has occured. If this is variable and unpredictable, the calculations will be nonsense. Give it a fixed execution frequency (as in an interrupt routine) and it will be much happier. Similarly, the sampling frequency of your analogue signal should at least give some pretence of matching the use you're making of it. Sure, stick this in OB1, do it every scan whether it's needed or not. But why not stick with the manufacturer's recommendations? Presumably they have some good reason.

Regards

Ken.

 

[RMA]

One of the key reasons for having the PID control in an interrupt routine is to maintain a fixed calling interval for the PID software. If you call it in OB1 the code has no way of knowing how long has elapsed since it was last called, and almost certainly this will vary on every cycle.

Just a thought, since I've never had to program a PID loop in S7 (but often enough in the past, several hundred in DCS systems). Is there a cross-over point if you have a lot of PID loops (whatever "a lot" might be in this context, 10, 50, 200...?), where the disruption to the cycle time of the main program using interrupts might be worse than the slight increase in complexity of using the OB1 #OB1_PREV_CYCLE data to calculate the time base?

Edit: Didn't notice the S7 200 and assumed 300. Does the S7 200 also have the previous cycle time data available?

 

[Ken J]

Thanks for your input Ken M and RMA. Yes, I totally agree with you Ken that the routine belongs in an interrupt due to the effect of the variable scan time on the integral and derivative calculations. I have two PID loops and may be able to get away with reading the analog values in OB1. I'll try it both ways to find out.

 

[Ken M]

Roy

The point is not so much to avoid disruption to the main task, but to give the PID calcs a firm and fixed basis on which to work.

Depending on the complexity of the process, how many loops makes a "lot", and whether they all need to processed on identical intervals can influence the entire approach to this, including selection of hardware. I certainly wouldn't be happy attempting 50 loops in an S7-200!

For the S7-300/400 bigger brothers, you can have multiple timed interrupts so that loops with different execution requirements can be dealt with as required. Even if you find that all, say, 50 need to be executed on the same time basis, you can separate them in different interrupts with identical execution frequencies but phased with respect to one another such that they don't all execute together on the one scan. This is another way of avoiding large bumps in the processing of the main cycle.

Very few PID loops I've come across genuinely require processing every scan of the CPU. If speed/timing is so critical to their successful operation I would consider engineering some slack in to the system by maybe introducing a dedicated PID module into the PLC to handle very high speed loops. This type of thing can keep loops running regardless of what the CPU is up to, even when it's stopped.

Regards

Ken.

 

[RMA]

I was just curious, I'm used to phasing Loops to spread the load from my DCS days, but of course there, you usually have a 1 or 2 sec scan rate anyway, rather than the ms scan of a PLC.

It's just another of those areas where, having been flung in the deep end and having no PLC training, I occasionally have problems - usually because of the cyclical scan!