Dispelling a Rules of Thumb in Foundation Fieldbus Segment Sampling Rate

On the Fieldbus Foundation Forums is a recent post, Macrocycle for control in the controller. The post begins:

I have seen many posts about scheduling and macrocycle calculation for control-in-the-field (CIF). I have some doubts about control-in-the-controller (CIC) application. Unfortunately, there is no other option in the project I am working for.

The question asks about acyclic vs. cyclic communications, macrocycle communications, and loop response time.

ISP Lima Process Control Specialist and Control magazine contributing editor, John Rezabek, contributed to the conversation. He referenced a post I had done previewing one of the Emerson Exchange presentations, Control Response Period for Foundation Fieldbus Control-in-the-Field Loops. This presentation was given by Emerson fieldbus consultants
Dan Daugherty, Ferrill Ford, and control performance consultant, Mark Coughran.

Here’s their presentation, which tested and compared control performance for CIC and CIF:

Dan shared a few thoughts with me that I wanted to pass along specific to control in the controller and control in the field considerations. He said most process control engineers don’t know how slow the modes they need to control are. The performance for control loops where control is performed within a Foundation fieldbus (FF) device will always be better, but if the engineer imposes reasonable rules on the use of CIC, it will work well.

Some want to do CIC to avoid the fieldbus segment design calculations and others encounter problems once they do the calculations and commission the segment. In some automation systems like the DeltaV system, the Foundation fieldbus H1 card can run the control loop. Since it’s directly connected to the fieldbus segment, the latency of passing information up to the controller is avoided. This significantly reduces the number of applications requiring CIC.

Dan takes issue with rule of thumb developed over the years where the segment-sampling rate is 2X the controller update rate. He believes this is a misapplication of Shannon’s sampling theorem. The problem is not that it doesn’t work; it’s that it increases the cost of project due to fewer devices per fieldbus segment.

Deciding that none of their theoretical arguments, diagrams, and Laplace transforms was having an impact with the 2X sampling belief, Dan, Mark, and Ferrill performed tests in the Fisher Marshalltown flow lab. Dan summarized the most important thing he learned from the test:

Once the loop control mode frequencies are identified, then you choose your control settings so the closed loop transfer function attenuates that frequency. And you need your control update rate to be somewhat faster than that. When we were looking at update rates in the ¼ and ½-second range, we essentially had an update rate that was 25 to 50 times the frequency of the mode we wanted to control, and 2.5 to 5 times 10x the frequency we were trying to control.

He concluded:

It’s true that CIF, with super precise determinism, gave the very best control. But CIC gave pretty good control. So, it wasn’t really a question of whether or not to use CIC or CIF (because CIF is clearly better), but if circumstances made it necessary to use CIC whether or not it was better to oversample at a slow update rate or to get one-to-one sampling at a faster control update rate. It turns out the faster control update rate gives you more for the money than oversampling at a slower control update rate does. However, note that this line of reasoning applies mainly to continuously changing disturbances.

So, first you need to understand what you are really trying to control, and how good is good enough. That determines your control update rate. Second, once you have a control update rate, then see how much you are willing to load the segment (devices per segment, for economic reasons). If you are forced to use CIC, and if that maximum loading doesn’t allow oversampling, then don’t oversample. If you are forced to use CIC, and if that if the maximum loading allows oversampling, then by all means oversample.

If you are using CIC, then what you gain by oversampling is a slightly better attenuation of the disturbance frequency, AND a significant improvement in end-to-end response time. So, if you have a process that is mostly flat lined, but every once in a while some rather sudden change occurs, an oversampled segment will have an initial response that is a little quicker than one that isn’t oversampled, and if you are using any discrete logic, then you will have a little quicker end-to-end response to the field input.

As for estimating “required” macrocycle times, that varies by method used (number of compel data communications required), speed of devices, and number of devices. CIC requires more compel data per macrocycle, so it will tend to make the macrocycle about 2x longer than if CIF were used.

Our interest in the experiment wasn’t to see if CIF or CIC was better, but to determine if oversampling was worth it. Given the already longer macrocycle with CIC, in my opinion, it is a needless self-imposed penalty to oversample, which (for same number of devices) now takes your control update rate out to 4x what you could get with CIF. So, you get worse control because it is CIC, and worse again on top of that because you slowed down even more to oversample.

GreenPodcast.gif MP3 | iTunes

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

Leave a Reply