[FUN] FF Data Sheets - ARCHIVE

[Stephen Mitschke]

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.

Thanks

> Ian Verhappen

<<Fieldbus Data Sheet.rtf>> <<Fieldbus Data Sheet_JJ.rtf>>

- - - -

Ian,

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

device?

Rick Castañeda

- - -

Just a couple of comments that come to my mind (I don't know how much they

fit):

- 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

use)

- 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,

Giorgio

- - - -

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-----

Ian,

It sounds like you're preparing to be very specific about the

capabilities

of fieldbus devices. Would this data sheet accompany every device

(e.g.

transmitter) specification, or would it apply to a whole class of

devices?

(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

window

defroster).

That said, it looks like you've covered the bases (so far as I know,

some

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

budgets.

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.

Jonas

- - - -

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).

Enjoy,

Kurt

- - - -

> > 3. What is "Fieldbus locator"?

Got me...

> > 4. Minimum voltage is specified as 9 V in the standard. No need to

ask.

This is correct.

> > 5. In rush current is specified as nominal plus 10 mA in the

standard.

> > 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.

- - - -

Ian,

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

is

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

Craig

- - - -

Ian:

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)

Regards,

Charles

- - -- -

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:

Regards,

Toshio Sekiguchi / Flowmeters D&E Yokogawa Electric Corp.

- - -

Bob:

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:

MANUFAC_ID

DEV_TYPE

DEV_REV

DD_REV

Revision

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.

Tony

-----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?

- - - -

Ian,

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

device

- 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

<<FB-PTS_eng.DOC>>

- - - -

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-----

Ian,

Can you please provide some back ground information on these spec

sheets?

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)

- - - -

Ian,

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.

Regards

Raj Khemchandani

- - - -

Ian

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,

etc.

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.

CONTROL IN THE FIELD DEVICES IS ALWAYS SAFER THAN IN THE CONTROL SYSTEM.

WITH BACKUP LAS IN THE FIELD DEVICES, THE CONTROL IS ALWAYS POSSIBLE. IF YOU

LOSE ONE ELEMENT, THERE IS ALWAYS A SAFE ACTION.

Marcos

- - - -

Ian,

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

implementation.

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:

Series,

Ideal or ISA,

Parallel,

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

critical.

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.

Regards,

Marcos

- - - -

Gil:

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.

Monvid.

- - - -

> FIELDBUS DATA SHEET :

>

> 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

- - - -

Marcos,

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

manufacturer.

Rick Castañeda

- - - -

Jim,

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.

Regards,

Marcos

- - - -

> > 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

ask.

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

standard.

> > 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.

- - - -

Ian:

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.

Regards,

Charles

- - - -

Ian:

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.

Regards,

charles

- - - -

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,

etc)

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 forthcoming..ie: 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,

Jim

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

S-curve.

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

certificates.

Fayad

- - - -

> 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,

specially

> 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

the

> best I've worked with lists only the most commom function blocks. This

type

> of data-sheet can also group several tags to identify identical

devices.

> I've noted also that a special care with the word "segment" should be

taken.

> 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)

should

> be in the same sheet. I am attaching an excel file with this idea.

>

> Regards,

>

> William

<<WDFFDataSheet.xls>>

- - - -

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

configured.

Should we do both and if not which one should we use (configured or

available)?

Ian

- - - - -

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

registered'.

Ian

-----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

Raj