FieldComm Group Forums for FOUNDATION Fieldbus technology  

Go Back   FieldComm Group Forums for FOUNDATION Fieldbus technology > Public Forums > Fieldbus User's Network [FUN]

Fieldbus User's Network [FUN] The Fieldbus User Network List Forum. Post your fieldbus related questions here.

Thread Tools Display Modes
Prev Previous Post   Next Post Next
Old August 12th, 2003, 11:16 AM
Stephen Mitschke's Avatar
Stephen Mitschke Stephen Mitschke is offline
Admin / Fieldbus Staff
Join Date: Jun 2003
Posts: 472
[FUN] FF Data Sheets - ARCHIVE

Attached are 2 Word'97 versions of a proposed Fieldbus Data Sheet
attachment. Please provide any comments to the list so we can reach a
consensus on this form prior to presenting it to the ISA S20 committee.
> Ian Verhappen
<<Fieldbus Data Sheet.rtf>> <<Fieldbus Data Sheet_JJ.rtf>>
- - - -
Is my undersatnding that the documents you sent me are intented to
be used
as a specification sheet to indicate the capabilities of a FF
Rick Castaņeda
- - -
Just a couple of comments that come to my mind (I don't know how much they
- maybe useful to know if a ground terminal is available inside the
instrument. It seems also that some transmitters have a segment terminator
inside, which can be activated if necessary (even if I don't like such a
- this I'm not sure about: to achieve a real loop synchronisation over the
bus, the instrument needs to receive what I believe is called 'Function
Block Schedule', that is the amount of time starting from the beginning of
Macrocycle where execution of Function Block has to be carried out; this
(only) allows a stable loop execution. This schedule is delivered by LAS.
Then, I don't know whether all instruments have such a capability, or it
should be declared.
Glad if this is someway useful,
- - - -
The intent is that this would be a second sheet for each/every Fieldbus
device, though as you say it could be done by segment or group/class of
devices. How do others on the list feel about this?
It is my understanding that the blocks are in some cases options and in
others part of the 'base' model. Other manufacturers are doing the option
approach, including the bundling idea. If any manufacturers have other
models please let us know, without being too commercial that is.
Thanks - Ian Verhappen
-----Original Message-----
It sounds like you're preparing to be very specific about the
of fieldbus devices. Would this data sheet accompany every device
transmitter) specification, or would it apply to a whole class of
(e.g., "all temperature transmitters")
Do we expect manufacturers to charge "per block", or will we be
dealing with
"option packages" (power windows, door locks, cruise control, rear
That said, it looks like you've covered the bases (so far as I know,
that I don't know).
John D Rezabek
Dear Ian,
1. To specify block requirements for each tag looks like a lot of work. I
would imagine that the user would have a generic specification for a device
type, e.g. pressure transmitters and they would specify there once and for
all which blocks they require. Probably a whole lot, and that they are
instantiable. In the data sheet for each tag they would then only specify
what is unique for that point, e.g. expected pressure range and temperature,
display/blind etc.
I.e. firmware capability should be specified as part of the main bid
document. There the customer would put in the execution time as well. I
would expect that the user would also specify diagnostics based on device
type rather than each tag. Instantiable blocks is an important feature users
should ask for.
2. I think some of the blocks you mentioned are obsolete. I will find out
and let you know later.
3. What is "Fieldbus locator"?
4. Minimum voltage is specified as 9 V in the standard. No need to ask.
5. In rush current is specified as nominal plus 10 mA in the standard. No
need to ask.
6. The new revision of the IEC standard demands devices be polarity
insensetive. No need to ask.
7. I assume that you are asking about capacitance becase of IS
requirements. Inductance is also a concern. The best thing to do is ask for
FISCO certification. This is a new model for IS superior to the entity
concept. To be FISCO certified a device must be less than 5 nF and 10 uH I
think it is. Once FISCO certified you need not to the troublesome C and L
8. What is "segment". Remember that a segment is not identical to a
network. A network can have many segments if it contains repeaters, e.g. IS
barriers. For non-IS a network typically only has one segment. Most likely
you are referring to network. I.e. the network connected to the interface
port. I think you should use the term "network" in this case. IEC 61158-2 /
ISA S50.02 uses this definition as does Ethernet etc. It is important that
ISA uses the terminology consistently so that S20 says the same as S50.
- - - -
Hi Giorgio,
All FF devices (Link Master or Basic) have the capability of running a
schedule. We verify this capability in interoperbility testing. Also, it
is possible to download a schedule to a device independent of the
running LAS. Each device has their own schedule based on the macrocycle
running on the LAS. How each device receives that schedule is
independent of the LAS (usually it is the primary LAS that downloads the
schedules to the devices, but it could come from an another
configuration tool).
- - - -
> > 3. What is "Fieldbus locator"?
Got me...
> > 4. Minimum voltage is specified as 9 V in the standard. No need to
This is correct.
> > 5. In rush current is specified as nominal plus 10 mA in the
> > No need to ask.
Actually, the device may draw up to plus 20mA during the first 20msec of
power application (refer to the Physical Layer Test spec). Still there
is no need to ask. If there is a need to ask this question, there is a
problem with the device and it is not in compliance with the PL Test and
FF registration.
> > 6. The new revision of the IEC standard demands devices be polarity
> > insensetive. No need to ask.
- - - -
FISCO and other good points already addressed below
Suggest title should be H1 Fieldbus Device Data Sheet
Until HSIT is in place and used by hosts it is probably a good idea to
identify the host/linking device
DD and CCF revision may not be enough if host specific resource file
required for H1 devices
Some host suppliers have additional testing/"certification"
required of
H1 devices
May be some limits on LAS secondary, etc addressing with some hosts
Identification of cabling connections need to be put somewhere
- - - -
I have to agree with those who have already voiced the view that to fill out
FF data items for "each" field device will not be productive. Thus, I
endorse the concept to have general data sheets that address a type of field
device such as a positioner or a pressure transmitter.
Also, there are a number of data items that I do not think the user will
really be specifying such as execution time. In fact, most of the data
items that we probably need to have on a data sheet are data items that we
need the FF device supplier to give us so we can make a good technical
evaluation. This may be different use of a datasheet than what we have
traditionally done with the SP20 data sheets.
I will confuse your effort by submitting two additional lists. One list is
data items that I think the user should specify. The other list are the data
items that the supplier needs to give the user.
Data Items to be specified by User:
1) Device Performance Availability (e.g. 99.99%)
2) Physical Layer Profile Class(e.g. Class 111, 112, etc)
3) Class (Basic or Link Master Stack)
4) All devices need to be shipped "ready to run" ( Yes / No )
Data Items to be submitted by Supplier:
1) Quiescent Current Draw (mA)
2) Number of Available VCRs
3) Function Blocks Provided
4) Execution Time (ms) - list for each function blk.
5) Block Class (Std, Enhanced, Custom)
6) Number of Linkage Objects
7) Minimum Cycle Time
8) Device Description Provided (Yes / No)
9) Device Description Revision Number
10) Common File Format File Provided (Yes / No)
11) List of all Manufacturer Write Checks
12) List and description of all Menus and Methods
13) Can the device be "online upgradable"? (Yes / No)
14) Does the device support "Incremental DD"? (Yes / No)
15) Are all of the Calibration & Diagnostic information defined in DD?
(Yes / No)
- - -- -
I fully agree with charles, but still some items the specification
may skip.
Rick Castaņeda
- - - -
Dear Ian,
Please find my comment in followings.
1. I could not understand the usage or object of this data sheet.
2. I thought following two need to be described more clearly.
>Device capacitance:
>Polarity Sensitive: YES Ļ NO Ļ
If this is a matter of IS conditions and cabling, a following
description seems to be more better.
1) Total visible capacitance from Fieldbus.
2) Connection to Fieldbus is Polarity Sensitive : YES NO
3. VCR
"Numbers of VCR's and Role of them" are very important.
Numbers of VCR's: Total ##
Role of VCR's:
Publisher: ## Subscriber: ## Server/Client : ##
PS: I'm expecting a numbers should be described.
Role of VCR's are Configurable or Fixed.
Configurable : Fixed :
are my suggestions.
4. Function Blocks
Type of Function Block might be in need.
Standard or Enhanced:
Toshio Sekiguchi / Flowmeters D&E Yokogawa Electric Corp.
- - -
I would suggest that he include ALL of the identifying information on his
data sheet. I know I am repetitive on this but I feel strongly about it.
The information should include:
If the purpose of this sheet is to document each device that is installed I
think all of the above should be present. If they need to replace a device
it will come in handy.
-----Original Message-----
Take a look at this. What would you like to see added. Based on our
problems I would suggest
VCRs - Fixed / Variable
Yes / No - Instantiation Function Blocks
Any others?
- - - -
Looks good but, I think we have to deal with two types of Data Sheets, those
used for procurement and another for configuration.
The data sheet used for procurement (Bids) in a project most define the type
of instrument, principle of operation and materials just like the very well
known from ISA, just add a segment containg important information regarding
the Foundation Fieldbus technology like;
Check boxes for:
- L.A.S. capability required or not
- Function Block instantiation required or not
- List all the standard function blocks and check for those required in the
- Maximum power consumption
- Chanel and segment to be installed
- The execution time may be indicated next to each required function block.
Keep in mind that the data sheet for procurement will indicate the minimum
requirements for each device, in many cases it is not possible orient the
specifications to a specific manufacturer specially in Goverment companies.
The configuration data sheet normally is provied by the manufacturer.
Attached please find the data sheets we are currently using for some jobs
here in Mexico.
Based on my experience one of the must important issues is the complience on
Device Descriptors accordding with the Fieldbus Foundation.
Rick Castaņeda
- - - -
These forms are being proposed as the second sheet to be added to a
Foundation Fieldbus device, or series of devices so that the user can
properly identify the necessary information to specify and design a Fieldbus
segment/network. I think the responses from others have helped you
understand this more than my short note. I look forward to any comments you
may have.
Ian Verhappen
-----Original Message-----
Can you please provide some back ground information on these spec
I assume this is something that all vendors shipping FF product
would need to
supply with thier equipment?
Best regards,
Calvin Nicholson
ABB Carson City (TBI)
- - - -
The type of algorithm utilized in the PID function block and the algorithm
within the controller needs some attention. Let me give you an example:
Manufacturer A is the host
Manufacturer B is the Fieldbus device supplier.
Control application:
Primary PID control will be done within the host controller, however backup
control will be done within the PID function block.
The PID algorithm within the host and the device could be different
therefore when backup control takes over you will NOT have bumpless
transfer. The datasheet should let the user be aware that the PID control
algorithm could be different in the device and the host when different
manufacturers are used.
Further engineering is required from the application engineers to provide
bumpless transfer. i.e. tuning parameters will to be tested etc..
In the datasheet you could have a line for all the control algorithms within
the device and have a checkmark to identify that some of the algorithms are
different between the host and the device. If you can identify the
differences at the initial purchase stage then you can then forecast or plan
the engineering efforts involved when doing the detail design.
Raj Khemchandani
- - - -
As far as I know the function blocks used in Foundation Fieldbus are standar
for all manufacturers, any way the configuration tool must allow the type of
function block you need and source (manufacturer or Fielbus Foundation
standar function block library), may be this feature is not supported by
some manufacturer in their configurtation tool.
A big problem is the fact that not all devices has instantiation capability,
this way the user canīt select the function block he needs for a prticualr
application, just like Raj exposed, by using instantiation feature the user
may select the same PID in both devices (Host and Field device).
In the other hand, several times users ask me how to handle redundancy on
PID, this is tipycal for traditional centralized control systems, by using
Foundation Fieldbus I think we have a new aproach to face this application,
by attaching the PID function block to the final control element there is no
need to have redundant PID function block, as long as the final control
element works properly everthing is Ok, if the final control element
fails.... well even if you have triple redundant system in your control
there is nothing you can do. (unless of course you have a redundant final
control element).
In all of our applications (in Mexico) we leave the PID at the final control
element or positioner/converter, we put two xmtrīs as redundant measurement,
in the positioner that drives the control valve we attach the PID, AO and
one Input Signal Selector, the selection criteria is First Good, this way if
the selected trasnmitters fails the ISS switches to the other, the PID keeps
working normally, if both transmitters fails then the PID goes to manual and
the operator is alerted, he can manipulate the valve in manual untill the
trasnmitters are replaced.
Rick Castaņeda
- - - - -
Hmmm is backup PID in the field device likely to be a common enough practice
for this "generic" data sheet?
Aren't FF function blocks "standard"? So then it's just your favorite host .
. . and how will vendor B know what blocks reside in vendor A's host? I
think when I specify the host, I'll ask the DCS manufacturer for this info.
I'm trying to imagine what circumstances would motivate me to have this
"backup PID" . . . so when the host has a bad day, somehow control goes on?
Certainly not all host algorithms can be backed up by field devices, so some
degradation happens anyhow. Does Honeywell have a slick way of "shedding"
control from Host to Field (or vice-versa), or would you do this with
"custom" blockware?
OK, a little off-thread . . . Just my $0.02(US)
John Rezabek
- - - -
Instantiation does not solve the problem that Raj mentioned. My previous
email addresses the subject. We are introducing instantiation in our devices
next summer, preserving a default fixed structure. This characteristic gives
flexibility, but also brings some problems in terms of maintenance
management, configuration tools, off line configuration etc.
As things mature, we have to further standardize procedures, implementation,
I agree with Rick that in case of redundant transmitters, the best solution
is to have the PID and an Input Selector in the final control element.
- - - -
As I received this from you and I don't have the mailing list, I will answer
it to you, but feel free to copy whoever you want.
Raj raised an interesting point: not all PIDs are the same. Even if you have
the same PID, different scan times may require different tuning parameters.
That is true for DCSs, PLCs and any digital implementation of PID.
It is important for the user to have the same basic PID type across the
plant. There are considerable differences in the way you tune a series or
ISA type of algorithm, mainly when the derivative mode is used. There are
very refined details on the way people implement Derivative filters. Some
suppliers, like PLC manufacturers, have no or very simple filters, whereas
DCSs have different degrees of sophistication. The dynamic behavior when the
Derivative mode is used can be quite different from implementation to
Although different implementations do affect dynamic performance, only the
type of algorithm may cause real problems. For PID control (not PI or P) the
tuning constants will differ and the tuning process will be different.
Therefore it is important to select a single type of implementation
throughout the plant. The data sheet should include the following options:
Ideal or ISA,
Other (describe)
Another important difference is the way the control deviation is
manipulated. Some controllers offer different type of calculations:
PID - All three terms use control deviation [SP-PV]
PI.D - D on PV and PI on [SP-PV]
I.PD - P and D on PV and I on [SP-PV]
I.PD with reference value multipliers for P and D
Other (describe)
There are other options in the PID that are nice, but will not be so
Raj mentioned two things that I am not comfortable with:
- I don't see people using the PID in the devices or in the controller as a
backup for each other. It is a long and interesting discussion, but
redundancy makes more sense in the same "domain". When a transmitter fails,
control should go to manual and/or safe position, unless there are redundant
transmitters. If one is using control in the field, the PID in the valve
would go to this condition or, if the PID was in the transmitter, the valve
would go to that mode/position when the transmitter signal is not present.
If the PID is in the control system, redundancy will occur at that level.
Some control systems work with different control cycle in the controller and
in the field (which is not good). Tuning constants would not work properly
even if the Control Algorithm is exactly the same.
-If you switch from one controller to another, you should always have a
bumpless transfer. The back calculation path was introduced with this
purpose. If you connect the blocks as recommended, you may have different
dynamic behavior due to different PID implementations, macrocycle etc, but
the switching should be smooth and bumpless.
This subject is fascinating and would deserve more discussion somewhere.
- - - -
The major problems with the proposed form are (as I see them):
- as the FF adds more standard algorithms, the visible part of the form will
have to be continually updated
(I suggest that the DS form be made active, with a built in forms wizard
that presents a pull-down menu of algorithms and associated parameters; the
form should include space for three algorithms)
- the form requires a footer for drawing number, sheet, references, revision
number, revision notes and approvals.
- - - -
> Overall comment:
> The format covers most of available types of Foundation Fieldbus Function
> Blocks. The newest sheet as detailed out with the most recent additions
> would be my preference.
> May I suggest that as a template it should just be a listing without the
> Number and Execution Time ( msec ) data on it. This allows for the
> addition of the possible the missing Non-Standard and Enhanced Function
> blocks as per the device supplied. This first page would work as a master
> index covering a wider variety of Foundation Fieldbus devices without
> running out of room for future additions.
> For the UE-1 project I would like to see a master index ( first page)
> showing what comes with the device and a (second page)
> being a detailed table format. The second page would be similar to the
> Appendix 5 data published for each device as initially shown in the
> Foundation Fieldbus - Syncrude Interoperability Test Plan literature. (
> Revision Date 2/18/99 Version : 0.05 ).
> The second page table format would incorporate not eliminate the Number
> and Execution data now showing on page one for the fieldbus device used
> and also include the additional data as shown on the newer proposed
> updated version called the
> " Instrument " Tag Number " data sheet.
> Other changes I would like see on the data sheet could be classified as :
> * simple revision updates to existing data as shown now.
> * new additions
> Simple revision updates include :
> 1) Combine the word Standard to the Basic Fieldbus Function Blocks
> category heading listing :
> Updated shows - " Basic / Standard - Fieldbus Function Blocks "
> verses " Basic Fieldbus Function Blocks "
> 2) The word Advanced could be incorporated with " Enhanced " so that
> the category heading would be :
> Updated shows - " Advanced / Enhanced Fieldbus Function Blocks "
> verses " Advanced Fieldbus Function Blocks ".
> 3) "VCR's : " would change to " Total VCR's " : this is the
> manufacturer's supplied configurable number available for the
> device as supplied. NOT the maximum number of available connections
> possible.
> The maximum number of connections possible shows up in the table (
> and proposed to be used for the UE-1 project ) as shown originally
> in Appendix 5 of the Foundation Fieldbus - Syncrude Interoperability Test
> Plan literature. ( Revision Date 2/18/99 Version : 0.05 ).
> If you have devices that have additional features available and you
> have used up all the available VCR's for your segment / link
> configuration you cannot access these additional features as desired. If
> there is a work-around this, please let me know.
> New additions:
> 1) See bottom section of Appendix 5 table in the original Foundation
> Fieldbus - Syncrude Interoperability Test Plan literature. (
> Revision Date 2/18/99 Version : 0.05 ) for any field device tested.
> Change would be to split out VCR's allotted to the Sink/Source
> category into two categories. Showing the VCR's
> allocated to the Client/Server and Report Distribution/Receiving
> types.
> 2) Other changes could revise the LAS Capability to indicate the
> appropriate Foundation Fieldbus Specification Communication
> Profile for the particular device.
> See Foundation Fieldbus Specification Communication Profiles as
> organized in FF-940 FS 1.4 ( 1996-1999 ).
> Group 1 has Class 11 : Group 2 has Classes 21, 22, 23, 24 : Group 3
> has Classes 31, 32, 33, 34, 35 etc
> In particular Group 3 has the Classes 31 & 32 breakdown for each as
> :
> * Class 31 is 31 P- Pub only , 31 PS - Pub/Sub only , 31
> PSC - Pub/Sub/Client
> * Class 32, 32 L, 32 T or 32 LT : " L" Link Master and/or
> " T " System Time Publisher Capable
> Only Class " 32 L" & " 32 LT " imply LAS capability.
> Just provide a check box with the appropriate number or just circle
> the appropriate class number used from
> a matrix on the table sheet.
> 3) Add Revision of Device itself as well " Device Rev " :
> Regards Andy Halinen
- - - -
One more important point that Fieldbus users must consider is:
When we lose our host, for whatever reason, and our backup LAS takes over
the Fieldbus link, are we willing to operate the plant with a LOSS OF VIEW.
Of course we can mitigate our risks by having fail safe valves and safety
systems but can we really operate a plant without a view.
Something to consider.
Raj Khemchandani
- - - -
Maybe the instantiation will not solve all the problems but I'm sure
will reduce them, In many application we are running in Mexico with
interoperable systems instantiation solve lot's of problems, in my
case I am able to select the same PID block that use other
Rick Castaņeda
- - - -
The Fisher Rosemount PID addresses your concern. You can select the same
type of PID used by the Honeywell DCS. Our PID also offers two degrees of
freedom for the control deviation. There are different implementation
details and different options between FR and Honeywell, but the "look and
feel" of the control loop will remain the same. The differences that you
would see are the same type of differences you notice when you use different
scan rates or different instruments and/or instrument installation setups.
My concern, in the email below, is with the devices using a very simple PID
implementation. If you have a device with a parallel implementation and a
system with series, you will have different tuning process and dynamic
behavior mainly when Derivative is used.
That's why we, Fisher Rosemount, decided to offer selectable options in our
PID block.
As you suspected, we do have the very same block in all instruments,
including Delta V.
The PID in the field devices is a very good choice. It offers loop integrity
and better performance. You can increase plant availability by keeping some
control loops running even if you loose the DCS controller(s) and I/O
card(s). This is a quite interesting topic. The DCS can be dedicated to more
important tasks.
If you have any question or if you want to discuss the subject. Feel free to
give me a call;
(952) 949 7002.
- - - -
> > 3. What is "Fieldbus locator"?
Got me... [Verhappen.Ian] Jim Jamison proposed this version of the data
sheet so hopefully he can tell us.
> > 4. Minimum voltage is specified as 9 V in the standard. No need to
This is correct. [Verhappen, Ian] Disagree since in many cases our
experience has shown that the devices will not operate at less than 12
volts. Does ITK 4 test this as well? If so you are right it does not need to
be included.
> > 5. In rush current is specified as nominal plus 10 mA in the
> > No need to ask.
Actually, the device may draw up to plus 20mA during the first 20msec of
power application (refer to the Physical Layer Test spec). Still there
is no need to ask. If there is a need to ask this question, there is a
problem with the device and it is not in compliance with the PL Test and
FF registration.
[Verhappen, Ian] This information is used for the network design.
> > 6. The new revision of the IEC standard demands devices be polarity
> > insensetive. No need to ask.
- - - -
Here is an answer to the great trivia question of Fieldbus Locator. This
term is defined on page 27 of FF AG-165, "Fieldbus Installation & Planning
Guide" as:
"The design process requires an indicator of which field devices are
connected to which bus segment. This requires that each bus segment is
numbered and that each device connected to the bus is given a number."
This item will probably be more understandable if it were called segment
number. In fact this is the very term that we used on our recent FF project.
I really question if it is appropriate to put this item on a datasheet since
the actual segment assigns can not be made until well after the field
instrument data sheets are done.
- - - -
I have been reading with great interest the discussion about PI Function
Block and where they should reside.
I want to say that I agree with Mario's overall view that the PID should be
in the field device, not the host. Also, the prospect of having PID FB in
the host and then switching to a PID FB in the field device when the host
fails is not very attractive to me especially when I realize the the FB in
the field device is not the same as the FB in the host.
- - - -
Further to Charles' comments and to the FBL (Fieldbus Locator) item, I will
give my opinion on this as well. I apologize for being so slow to interact
on this subject as I am extremely busy currently in engineering (I'm with an
EPC company)and advising on FF issues to 2 very large FF based projects in
the Oilsands world.
I am the one who originally raised the issue of modifying FF Instrument
Data Sheets with Ian and submitted the markup copy for his comments. He
suggested we plant it out on the FUN list and I'm pleased to see the lively
discussions evolving around it!
In the EPC business where we are dealing currently with over a thousand FF
points per project, we must identify both devices and segments in a logical
manner for incorporation into the Instrument Data Bases (IDBs) which
generate many project deliverables such as Instrument Indexes, Instrument
Data Sheets, Loop Sheets, Segment Drawings, etc etc. plus other non-IDB
documents (layouts, wiring schedules, termination dwgs., location plans,
The FBL, as Charles mentions, is mentioned in FF AG-165 which is actually
from the British document EEMUA Pub. # 189 "A Guide to Fieldbus Application
for the Process Industry"(1997). I know the principal author, Graeme Wood
from my standards work on SP50 and IEC6-1158. This document is a good
starting point for all EPC companies involved in FF applications but it is
getting a bit dated.
My contact at the Fieldbus Foundation, Kurt, informed me that they are
not really pushing the use of this document currently and that other
documents will be the document we all have been looking at
generated by Ian and the FF EUC!!
For example, there are references in the old document FBL section to "240
devices max. per "Network" "...this all goes back to when Graeme wrote the
document and there were no hosts available. Obviously, the limitation on
the max. number of devs., etc. rests with the vendor of the various hosts
and H1 I/F cards.
Now, specifically to the FBL, we have come up with an FBL composed of
Plant#, Unit/Area#, Sub-Area#, Controller/Processor#, Chassis#, Card/Slot#,
Port#, Physic.Dev#. [note Phys Dev # NOT same as run-time Dev # but useful
in proj. doc'n.]
This would symbolically look like this: PPUSCCMXXPDD. The Segment Number
is the first 10 digits of the FBL.
Some of this involves manufacturer-specific info. In the case of our
Foxboro host on one of our projects (Fox IA with FBM 221 H1 I/Fs), simply
use the Fox Letterbug addr as the main part of the FBL. In the case of
Honeywell and Delta V, we use the above mentioned FBL system, especially
in the applications where the PID cont. will be done in the FF Device.
Whew!!...sorry about the length, but some of these things should be said.
But, back to the Data Sheet, I only put the FBL in strictly for doc'n.
purposes by the User (EPC). It may not be available at the time of the
original D/S issue but could be in the IDB for later issues, if required.
Best Regards,
J.E. (Jim) Jamison, P.Eng.
- - - -
This convention may work for your projects . . . if you have resolved to
keep segments "pure" and not have cross-area devices on segments. However,
sometimes it's very practical . . . for example, if you tag utilities (like
a cooling water or condensate flow) with a different Unit or Area
designation than core process units, such utilities could very likely end up
"geographically" amongst process unit devoted devices, and far from "like
unit / area" devices. So you can either put it on a segment with the
"process unit" tagged devices, or run a long spur from some more remote
junction box.
You may even decide that, philosophically, you have improved fault tolerance
if the devices on any given segment are spread functionally across units
(depending on your process).
In our case, we tagged segments sequentially (we only have about 70) and
also by controller-card-port.
We have to be careful when we direct EPC firms, because at some level the
thinking stops and "blinders-on" application of rules takes over . . .
especially when the Project Manager is pushing for another tick on the
I agree that the data on the proposed FF sheet is appropriate for the
instrument data base, index, etc., maybe later included on loop sheets or
segment diagrams (if you choose to have any "paper" ones). Much of it is not
efficient or perhaps necessary for device procurement specifications, except
maybe on a "general classification" ("all pressure transmitters shall have .
. . ") level. Then at least those suppliers that don't conform are obliged
to indicate where they differ.
Many of us may end up shoving these guidelines at more (or totally)
inexperienced firms . . . imagine the price inflation if a potential
consultant thinks they have to specify all that data for each instrument.
John D Rezabek
- - - -
I think that a field saying that if the device has instantiable or fixed
function blocks would be good. As well a place for I.S. and Exp
- - - -
> Dear Marcelo,
> It does not make sense to me a data sheet that lists a lot of function
> blocks. This type of data sheet would be very difficult to read,
> in medium or large projects / quotations. I have received tons of data
> sheets here in the quotations we have made these couple of years and
> best I've worked with lists only the most commom function blocks. This
> of data-sheet can also group several tags to identify identical
> I've noted also that a special care with the word "segment" should be
> Some people understand that the entire channel is one segment. Others
> understand that the spur is a segm. and others understand that each is.
> barrier defines a segment. The notes field (except for large notes)
> be in the same sheet. I am attaching an excel file with this idea.
> Regards,
> William
- - - -
This is a subset of a previous thread on data sheets, but Jim Sprague
document got me thinking that perhaps we should configure the data sheet to
indicate which function blocks are available AND which function blocks are
Should we do both and if not which one should we use (configured or
- - - - -
Good idea Raj, except if we specify that the device must be FF registered
and the associated ITK rev number this will by default indicate that all
blocks indicated as available on the data sheet are interoperable. Unless of
course you meant that we change the 'heading' 'available' to 'FF
-----Original Message-----
I don't know it this was mentioned but how about adding which function
blocks are FF registered on the datasheet. Knowing what is FF registered
will assist in interoperability problems in the future.
Raj Khemchandani
Fieldbus Knowledge Manager
Honeywell Ltd
- - - - -
I would change the heading Ian. In that case the data sheet is truthful.
Remember a good fieldbus project is a project with no uncertainty.
My thoughts not yours
Attached Files
File Type: doc FB-PTS_eng.DOC (19.0 KB, 731 views)
File Type: rtf Fieldbus Data Sheet.rtf (23.3 KB, 638 views)
File Type: rtf Fieldbus Data Sheet_JJ.rtf (38.2 KB, 565 views)
File Type: xls WDFFDataSheet.xls (18.0 KB, 587 views)


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
[FUN] FF Cable Types and Calculations - ARCHIVE Stephen Mitschke Fieldbus User's Network [FUN] 3 June 10th, 2008 10:37 AM
[FUN] Ammonia Plant Installation - ARCHIVE Stephen Mitschke Fieldbus User's Network [FUN] 2 April 22nd, 2007 12:56 AM
[FUN] FF Control Algorithms - ARCHIVE Stephen Mitschke Fieldbus User's Network [FUN] 0 August 12th, 2003 11:10 AM
[FUN] Representing Multivariable Tx on P&ID - ARCHIVE Stephen Mitschke Fieldbus User's Network [FUN] 0 August 12th, 2003 10:47 AM

All times are GMT -5. The time now is 02:08 PM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
(c) 2011-2015 by FieldComm Group. All rights reserved.