It has been more than two years since I last discussed flexible function blocks (FFB) in this column, so it is time to provide an update on their capabilities in an industrial setting.
Like all object-based fieldbus function blocks, the FFB is a “wrapper” for the actual functions that reside and execute inside of it. The fieldbus specifications define a set of parameters that must be common to all function blocks to ensure interoperability and communications between the various blocks, devices and host system. Since each component of the fieldbus specification is treated as an object and is, to some extent, similar to a subroutine or function call in a computer program, it is possible for each manufacturer to write its own code for the object to execute, as long as the results are presented in the predefined format. It is this lack of definition for the function itself that makes the FFB possible.
The FFB can be configured by the end-user with any of the IEC 61131-1 languages to whatever function is required. Thus, a device supporting the FFB can be configured or programmed for a variety of purposes from protocol converter to a nano-PLC that performs batch/recipe operations or complex multivariate control calculations such as artificial neural networks or fuzzy logic.
The FFB specification contains many useful function blocks; however, the one developed to help fieldbus in the manufacturing industry–where discrete control is more prevalent–is the device controller, which is intended to control any two- or three-state physical device. The device controller accepts a set point and causes the device to drive to that set point. Time is allowed for the transition, but alarms are generated if the physical device fails to reach the desired state or loses that state after the transition is complete. The DC block has inputs for control of the set point by external logic or commands from a host, as well as permissive, interlock and shutdown logic functions. An operator may temporarily bypass a faulty limit switch after visual confirmation of the state of the physical device. The parameter “DC_STATE” displays one of 14 states that describe the current control condition, while the parameter “FAIL” gives specific reasons for failures.
Unfortunately, the interfaces to program FFB are not yet fully interoperable. This means that an FFB from Manufacturer A must be programmed and configured by the host and software tools of Manufacturer B, and vice versa. However, once the FFB has been prepared and compiled through DD Services–the binary file that is used by field devices and hosts to execute the information from the device description (DD) file–it can be executed by any system supporting the FFB block type.
FFB technology was successfully demonstrated at the International Specialty Products facility in Lima, Ohio in May 2005. The demonstration consisted of converting one of the three filter beds in the process from control in the host to field-based control using linking devices from two manufacturers containing FFBs. The first FFB controlled the 10 quick opening/closing valves (250 milliseconds) on one side of the filter. Then control was transferred to the second linking device and its FFB to control the second bank of 10 valves. After that, control was passed back to the host to control the third filter bedÃs operation.
The linking devices, host and field devices were from different manufacturers, which demonstrates the interoperability of fieldbus at the H1 (Foundation Fieldbus 31.25 kbps communications protocol) level. HSE (high-speed Ethernet communications protocol) interoperability is not yet at the same level as H1, so work is underway at the Fieldbus Foundation to improve the ability for one HSE device to communicate with other HSE devices. This will be a key enabler to the development of Ethernet field devices.
The issue of linking device interoperability is not currently a big challenge because, like PLCs, it is not often that a single site has too many manufacturers’ products on the same process communicating with each other. Of course, PLCs have limited interoperability between manufacturers as well, since each of them has their own preferred communications protocol and hence the need for protocol converters or gateways.
Like any technology, there is room for continuous improvement, and each protocol supporting organization has a mechanism for making suggestions on improvements, reporting bugs or errors, and ensuring compliance for these changes. But that is another topic that I will cover in a future column.
Ian Verhappen is an ISA Fellow, ISA certified automation professional, adjunct professor at Tri-State University and director of Industrial Networks at MTL Instruments, a global firm specializing in fieldbus and industrial networking technologies. E-mail him at Ian.Verhappen@ICE-Pros.com, or visit his website, www.ICE-Pros.com.
- Automation Research Corporation (ARC) recently published a White Paper on the ProfiSAFE protocol and its use in industry. A synopsis of the report can be found on the ARC website at www.arcweb.com.
- The OPC Foundation is presenting a series of free seminars on basic and advanced OPC functionality. For more information, visit www.opcfoundation.org.
- If you havenÃt already seen it, there are some cool things on the IEC website for the centenary. You can find free posters, desktop wallpaper and more at www.iec.ch/100years/coolstuff.
- The OMAC Packaging Workgroup (OPW) has updated the Guidelines for Packaging Automation to Version 3.1. This version includes the guidelines for PackAL, an application library of common software elements used in packaging machinery applications.
- At their recent annual meeting in Hannover, Germany, the members of Interests Group SERCOS interface e.V. (www.sercos.com) changed the name of the association to SERCOS International to reflect the worldwide use and acceptance of the SERCOS interface technology, as well as the global reach of its members. The names of SERCOS InternationalÃssubsidiaries, SERCOS North America and SERCOS Japan, remain unchanged.