Open Closed commands over FF

[smr]

I would like to be able to open a valve at a certain tank level and close it at another level. I have not been able to figure out how to do this with standard FF function blocks.

Is there a way to send a 0% or 100% signal to an AO block based on a given AI input? I'm aware it would be much easier to use a PID block and control to a set point, or do the open closed function through a controller, however these are the requirements I'm working to. I would like to avoid custom blocks as not all custom blocks can be instantiated by the control system. Normally a PID with deadband / hysteresis would work but this is not a feature of the standard FF PID block.

[rezabejd]

Well the first question is - what is your host / engineering interface? And what field devices?

The are a number of on-off capable valves that have an FF standard DO block. A few do some tricky things with the "readback" parameter that make it more meaningful, if you want to use it.

I'm pretty sure the FF standard AI block has an "OUT_D" parameter, but not all devices or config tools support it. You could potentially use this to set / reset the valve's DO block CAS_IN_D, set deadband (maybe) as needed. I see out_d parameters on the newer signal-selector blocks (ISEL) - but not sure if these are vendor-specific or standard, or how widely supported they are. If you had them, you could use the out_d of the AI to open the valve and the out_d of the ISEL to close it - assuming your valve was double-acting.

You could also run your 1 / 0 (I think) into an ARTHM block and make it into 0 / 100, which could then drive an FF AO block?

[smr]

My understanding of the ITK program is if you have a certified device and a certified host all of a blocks standard functionality will be available. Any custom features and blocks are use at your own risk. In my experience this seems to be a point that many people miss when the specify equipment. They read the marketing brochure and think that every feature of a device will work under any host. However, Murphy's law applies and unless the host and device are made by the same company the majority of custom features do not work.

My example is an ABB host with a SMAR LD302. The valve is really a 4-20 device that the supplier slapped a StoneL IO block on and called it an FF device. So for the valve I have to deal with an AO block not a DO.

The LD302 has an APID which has the functionality i would need (they call it gap control I say deadband) however it is a nonstandard block and is not supported by the host system. That is why I am looking for a host/manufacturer neutral solution.

The standard AI block does not have an OUT_D. If it does, it is not a feature that is tested by the ITK. I have seen it on a few devices but most do not have it.

As for the areth block, I'm not sure how the FF standard deals with data type conversions between BoolIO and RealIO data types. I have not seen a block for it, and my host system will not let me connect a BoolIO to a pin that is for RealIO. If there is a way to do it let me know.

[WHodson]

While it is true that some hosts do not support custom blocks and extended blocks, please do not condemn them all out-of-hand. The Honeywell Experion-PKS DCS, for example, does support custom blocks and extended block parameters as defined in the field device vendor’s (including non-Honeywell’s) device description files. Ask detailed and pointed questions before you select a host. The hosts that do not support extended parameters to standard blocks or do not support custom blocks are not properly processing the definition information in the device descriptions.

Your complaint regarding two-state valves is well taken. The intent of the function block team was that a single DO block would be used in this case and internal inputs and outputs would be handled by underlying transducer blocks. The DO setpoint and actual positions would simply be ON or OFF. There have been some inappropriate implementations in this area.

The standard AI block does not have an OUT_D indicating an alarm condition because it would have violated the Fieldbus Foundation’s philosophy. (Some vendors added it on their own.) That is, “control” should be configured by a control engineer and the operator should not be able to modify it. If an OUT_D is used as a control variable, it is under the influence of the operator’s latest entry for alarm limits. Instead, a comparator block should be used for that control, so that if an operator moves an alarm limit to avoid nuisance alarms, he/she does not inadvertently change the control action. Unfortunately, FF does not have a standard comparator block yet.

Regarding data type mixing, FOUNDATION™ Fieldbus does not allow connecting discrete outputs to float inputs or vice-versa. That, in general, would be a dangerous game for a novice to play. The standard Input-Selector block does have discrete inputs (DISABLE_n) that serve as disables. By providing such a Boolean connection to the first input and choosing the “First Good” SELECT_TYPE, the Boolean selects between the first and second inputs, either of which may be constants or connected variables. Since the block has at least 4 inputs and 4 disables, more advanced logic can be designed. For example, if SELECT_TYPE is “Mid” and one input is a high clamp, a second limit is a low clamp, and a third input is a process variable, the output will be clamped by the block because the limits become the middle value when the process variable exceeds them.

Regarding the desire to drive an AO to a certain value, the PID block has a TRK_VAL (Track value) and TRK_IN_D (track input control). When TRK_IN_D is true, the PID will track its output to TRK_VAL which can be set to 0%, 100%, or anything else. Unfortunately there is no standard comparator block to help you set the TRACK_IN_D Boolean.

Bill Hodson

[rezabejd]

My understanding of the ITK program is if you have a certified device and a certified host all of a blocks standard functionality will be available. Any custom features and blocks are use at your own risk.

Was there some psychoactive substance aflame in the vicinity when you had this vision?:D

The ITK is applied to devices with reasonable uniformity, but the host tests (HIST) have been lacking. The host suppliers foot a lot of the bill for the Foundation, and I think for a while they didn't exactly welcome standardized host testing. There are ENORMOUS differences in the capabilities of various hosts, but some you never knew till you'd owned one for a while. That's why it's great we have this forum.

We (end users) have been complaining about this for years. Finally last year the Foundation released the "HIST 2" test - it's been out for a while - it will be better but I haven't heard of anyone passing it yet.

Thanks Bill for your thoughts from someone close to making the technology function. I like the idea of useing track_in_d; what about setting it to "1" (true) all the time (just make it a constant) and manipulate track_val according to where the AI out is - like you suggested with the ISEL functioning as a limiter maybe.

Part of the problem has been, users default to just using FF for IO and fewer end users experience these frustrations. Without complaining about things like this progress will be slow - and it has been. I waited 5 years for one of our suppliers to finally implement a CSEL block, so I could do some simple limit control in a field-based loop.

[smr]

Fist off John, Bill thanks for the feedback, and sorry for the slow response.

I think if there was only one setpoint this would have been fairly easy to do with an alarm block, a select block and a pid block. However, since the requirement was to fill up to a high level setpoint then let the level fall until it reached a low setpoint and start the filling again I could not come up with a reasonable solution with FF blocks. I do not see a reasonable way to do this without having either a set/reset function or sequence control.

While it is true that some hosts do not support custom blocks and extended blocks, please do not condemn them all out-of-hand. The Honeywell Experion-PKS DCS, for example, does support custom blocks and extended block parameters as defined in the field device vendor’s (including non-Honeywell’s) device description files. Ask detailed and pointed questions before you select a host. The hosts that do not support extended parameters to standard blocks or do not support custom blocks are not properly processing the definition information in the device descriptions.


ABB's host system does support custom blocks and extended block parameters, but they do not support every function block from every manufacturer. Typically I don't see this as a big deal since I try to implement most logic in the host system where you have more flexibility, and an your features will always be there even if an end device gets replaced.

From what I've seen on the interoperability front both parties (host and device manufacturer) have been guilty of causing interoperability issues. This has been improving over the years, and hopefully the new host tests improve this even more.

[rezabejd]

From what I've seen on the interoperability front both parties (host and device manufacturer) have been guilty of causing interoperability issues. This has been improving over the years, and hopefully the new host tests improve this even more.

The Foundation is calling this the "Registered Host" test, and there were some at the recent GA that thought the first two registered hosts might be announced at Interkama (this year).