Control in the field

[b_dolan]

I'd like to attempt my first control loop with control in the field device, but need a little help. The host is DeltaV and I don't know if I need to use a control module like I would normally with control in the controller. And if so, then is the module assigned execute in a device instead of the controller? If anyone has a little tutorial on this it would be greatly appreciated.

[dhobart]

Assuming you wish to implement a PID loop, you will need to activate a PID function block in either the valve positioner or the transmitter. I believe in Emerson's case, this involves getting a key from Emerson. Generally, the valve positioner is preferred because location for the PID block as it uses only one VCR in each device for the control loop. However, if execution time is a conideration, you may want to check the execution time for the PID block in each of the devices. This is available in their *.cff files.

Once the PID block is activated, it is a matter of configuring it through your engineering tool. Note, if the control loop requires other function blocks, you will want to verify if field devices and your engineering tool support their implementation in the field. There is a wide range in vendor supported field function blocks.

Good luck. You will find the loop performance will improve significantly. When all the function blocks are on the "wire", their execution is contolled by the LAS and consequently their execution will be deterministic.

[rezabejd]

b,

Did your Emerson office show you how to use "books online"? It is essentially the online help / documentation for DeltaV and is usually very useful.

Open books online, click the "search" tab and type "using fieldbus technology" (with quotes). Various other searches are possible.

I find Emerson's recommendations to be a little conservative. Here's what I would do, assuming you are doing a simple PID or cascade slave:

1) Set up the function blocks as you normally would for non-FF devices. There are templates that got installed when you installed DeltaV if you want to use one (there's even a "FF_PID_LOOP" template, under Library\module templates\analog control).

For the AI and AO, be sure you have "channels", l_type (linearization type), and xd_scale set up appropriately. Certain devices will only accept certain units, for example 3051's will use "psi" but not "psig" or "psia".

If you used the template, it already has the blocks "wired" correctly. If you didn't use the template, you may want to have a look at it. This is really pretty simple here.

"Assign" the function blocks (including the PID) to field devices. We usually put the PID in the final control element (valve positioner) because "manual" mode is less complicated when you take the transmitter offline for some reason.

If you started with a "controller resident" PID, you may notice that the PID block gets "smaller" when you assign it to an FF device. This because not every parameter / option that DeltaV supports is available in field devices. Differential Gap, for example (non-linear gain modification) is typically not natively supported, except maybe by Smar. The "Structure" parameter, while supported by many devices, isn't "settable" from DeltaV, although some configurators can access it and modify it (like if you want "integral only action on a SP change").

Anyhow you may wish to examine the "transformed" PID to see if anything you really liked or needed goes away. Note also, if you chose to "expose" any parameters and "wire" to them, these go away. Only the parameters that participate (or are available to use) in the "publish-subscribe" deterministic part of the FF macrocycle are there.

You can use work-arounds to write to the same parameters, but you need to be careful. If you write to some of these every macrocycle, you can wear out the device's non-volatile RAM. It's covered in books online.

Once the blocks are assigned, you just need to download the module. If your process is "live" (running) you may want to look at the modes and valve positions of the blocks you're downloading. When in doubt about the effect a download might have, I have set the mode of the FF AO to "auto" and set a setpoint (valve position). Once the module is downloaded, the PID will initialize to the AO setpoint and you can put it back in "CAS" (its normal mode).

I take issue with the recommended settings for module execution versus macrocyle time. It's true that, once the PID is running in the field, the execution is determined by the macrocyle and you don't need to run the host module as fast. The problem we see, is when operators want to make rapid mode, output, and / or setpoint changes (for example, during a process upset) - these changes are made to the "host" and propogate more slowly to the field devices. If they want to shut a valve in a hurry, they don't want to sit and watch the faceplate for 5 seconds waiting for it to show "MAN" mode.

For the most part, we set module execution = macrocyle (typically one second).

I would be doing all this on some little-used or peripheral loops until you get comfortable with it.

There are more resources here:
DeltaV site (http://www.easydeltav.com/keytechnologies/fieldbus/whitepapers.asp)

Hope this helps
John Rezabek
ISP

[b_dolan]

Thanks John and Dave; your commentary is very informative. I have been successful in getting our first loop on the wire and so far it's working well. There are other loops that I would consider migrating to the wire but I see that there's not always a device resident equivalent function block. Is the FF technology moving in a direction that would allow all or the most common function blocks to be available at the device level?

[IanVerhappen]

The EUAC is working with the Foundation to release several additional blocks this year Bill, starting with a list of who has what. Hopefully this will be completed by March and I will keep the list informed. - Ian



Thanks John and Dave; your commentary is very informative. I have been successful in getting our first loop on the wire and so far it's working well. There are other loops that I would consider migrating to the wire but I see that there's not always a device resident equivalent function block. Is the FF technology moving in a direction that would allow all or the most common function blocks to be available at the device level?