Stephen Mitschke
August 12th, 2003, 12:16 PM
Attached are 2 Word'97 versions of a proposed Fieldbus Data Sheetattachment. Please provide any comments to the list so we can reach aconsensus 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 tobe usedas a specification sheet to indicate the capabilities of a FFdevice?Rick Castaņeda- - - Just a couple of comments that come to my mind (I don't know how much theyfit):- maybe useful to know if a ground terminal is available inside theinstrument. It seems also that some transmitters have a segment terminatorinside, which can be activated if necessary (even if I don't like such ause)- this I'm not sure about: to achieve a real loop synchronisation over thebus, the instrument needs to receive what I believe is called 'FunctionBlock Schedule', that is the amount of time starting from the beginning ofMacrocycle 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 itshould be declared.Glad if this is someway useful,Giorgio- - - - The intent is that this would be a second sheet for each/every Fieldbusdevice, though as you say it could be done by segment or group/class ofdevices. How do others on the list feel about this?It is my understanding that the blocks are in some cases options and inothers part of the 'base' model. Other manufacturers are doing the optionapproach, including the bundling idea. If any manufacturers have othermodels 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 thecapabilitiesof fieldbus devices. Would this data sheet accompany every device(e.g.transmitter) specification, or would it apply to a whole class ofdevices?(e.g., "all temperature transmitters")Do we expect manufacturers to charge "per block", or will we bedealing with"option packages" (power windows, door locks, cruise control, rearwindowdefroster).That said, it looks like you've covered the bases (so far as I know,somethat I don't know).John D Rezabek------Dear Ian,1. To specify block requirements for each tag looks like a lot of work. Iwould imagine that the user would have a generic specification for a devicetype, e.g. pressure transmitters and they would specify there once and forall which blocks they require. Probably a whole lot, and that they areinstantiable. In the data sheet for each tag they would then only specifywhat 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 biddocument. There the customer would put in the execution time as well. Iwould expect that the user would also specify diagnostics based on devicetype rather than each tag. Instantiable blocks is an important feature usersshould ask for.2. I think some of the blocks you mentioned are obsolete. I will find outand 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. Noneed to ask.6. The new revision of the IEC standard demands devices be polarityinsensetive. No need to ask.7. I assume that you are asking about capacitance becase of ISrequirements. Inductance is also a concern. The best thing to do is ask forFISCO certification. This is a new model for IS superior to the entityconcept. To be FISCO certified a device must be less than 5 nF and 10 uH Ithink it is. Once FISCO certified you need not to the troublesome C and Lbudgets.8. What is "segment". Remember that a segment is not identical to anetwork. A network can have many segments if it contains repeaters, e.g. ISbarriers. For non-IS a network typically only has one segment. Most likelyyou are referring to network. I.e. the network connected to the interfaceport. 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 thatISA 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 aschedule. We verify this capability in interoperbility testing. Also, itis possible to download a schedule to a device independent of therunning LAS. Each device has their own schedule based on the macrocyclerunning on the LAS. How each device receives that schedule isindependent of the LAS (usually it is the primary LAS that downloads theschedules to the devices, but it could come from an anotherconfiguration tool). Enjoy,Kurt- - - - > > 3. What is "Fieldbus locator"?Got me...> > 4. Minimum voltage is specified as 9 V in the standard. No need toask.This is correct.> > 5. In rush current is specified as nominal plus 10 mA in thestandard.> > No need to ask.Actually, the device may draw up to plus 20mA during the first 20msec ofpower application (refer to the Physical Layer Test spec). Still thereis no need to ask. If there is a need to ask this question, there is aproblem with the device and it is not in compliance with the PL Test andFF 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 belowSuggest title should be H1 Fieldbus Device Data SheetUntil HSIT is in place and used by hosts it is probably a good idea toidentify the host/linking deviceDD and CCF revision may not be enough if host specific resource fileisrequired for H1 devicesSome host suppliers have additional testing/"certification"required ofH1 devicesMay be some limits on LAS secondary, etc addressing with some hostsIdentification of cabling connections need to be put somewhereCraig- - - - Ian:I have to agree with those who have already voiced the view that to fill outFF data items for "each" field device will not be productive. Thus, Iendorse the concept to have general data sheets that address a type of fielddevice such as a positioner or a pressure transmitter. Also, there are a number of data items that I do not think the user willreally be specifying such as execution time. In fact, most of the dataitems that we probably need to have on a data sheet are data items that weneed the FF device supplier to give us so we can make a good technicalevaluation. This may be different use of a datasheet than what we havetraditionally done with the SP20 data sheets.I will confuse your effort by submitting two additional lists. One list isdata items that I think the user should specify. The other list are the dataitems 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 VCRs3) Function Blocks Provided4) Execution Time (ms) - list for each function blk.5) Block Class (Std, Enhanced, Custom)6) Number of Linkage Objects7) Minimum Cycle Time8) Device Description Provided (Yes / No)9) Device Description Revision Number10) Common File Format File Provided (Yes / No)11) List of all Manufacturer Write Checks12) List and description of all Menus and Methods13) 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 followingdescription seems to be more better.1) Total visible capacitance from Fieldbus.2) Connection to Fieldbus is Polarity Sensitive : YES NO3. 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 BlocksType 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 hisdata sheet. I know I am repetitive on this but I feel strongly about it.The information should include:MANUFAC_IDDEV_TYPEDEV_REVDD_REVRevisionIf the purpose of this sheet is to document each device that is installed Ithink all of the above should be present. If they need to replace a deviceit will come in handy.Tony-----Original Message-----Take a look at this. What would you like to see added. Based on ourproblems I would suggestVCRs - Fixed / VariableYes / No - Instantiation Function BlocksAny others? - - - -Ian,Looks good but, I think we have to deal with two types of Data Sheets, thoseused for procurement and another for configuration.The data sheet used for procurement (Bids) in a project most define the typeof instrument, principle of operation and materials just like the very wellknown from ISA, just add a segment containg important information regardingthe 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 thedevice- 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 minimumrequirements for each device, in many cases it is not possible orient thespecifications 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 jobshere in Mexico.Based on my experience one of the must important issues is the complience onDevice 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 aFoundation Fieldbus device, or series of devices so that the user canproperly identify the necessary information to specify and design a Fieldbussegment/network. I think the responses from others have helped youunderstand this more than my short note. I look forward to any comments youmay have.Ian Verhappen-----Original Message-----Ian,Can you please provide some back ground information on these specsheets?I assume this is something that all vendors shipping FF productwould need tosupply with thier equipment?Best regards,Calvin NicholsonABB Carson City (TBI)- - - - Ian,The type of algorithm utilized in the PID function block and the algorithmwithin 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 backupcontrol will be done within the PID function block. The PID algorithm within the host and the device could be differenttherefore when backup control takes over you will NOT have bumplesstransfer. The datasheet should let the user be aware that the PID controlalgorithm could be different in the device and the host when differentmanufacturers are used. Further engineering is required from the application engineers to providebumpless transfer. i.e. tuning parameters will to be tested etc..In the datasheet you could have a line for all the control algorithms withinthe device and have a checkmark to identify that some of the algorithms aredifferent between the host and the device. If you can identify thedifferences at the initial purchase stage then you can then forecast or planthe engineering efforts involved when doing the detail design.RegardsRaj Khemchandani- - - - IanAs far as I know the function blocks used in Foundation Fieldbus are standarfor all manufacturers, any way the configuration tool must allow the type offunction block you need and source (manufacturer or Fielbus Foundationstandar function block library), may be this feature is not supported bysome 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 prticualrapplication, just like Raj exposed, by using instantiation feature the usermay select the same PID in both devices (Host and Field device).In the other hand, several times users ask me how to handle redundancy onPID, this is tipycal for traditional centralized control systems, by usingFoundation 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 noneed to have redundant PID function block, as long as the final controlelement works properly everthing is Ok, if the final control elementfails.... well even if you have triple redundant system in your controlthere is nothing you can do. (unless of course you have a redundant finalcontrol element).In all of our applications (in Mexico) we leave the PID at the final controlelement or positioner/converter, we put two xmtrīs as redundant measurement,in the positioner that drives the control valve we attach the PID, AO andone Input Signal Selector, the selection criteria is First Good, this way ifthe selected trasnmitters fails the ISS switches to the other, the PID keepsworking normally, if both transmitters fails then the PID goes to manual andthe operator is alerted, he can manipulate the valve in manual untill thetrasnmitters are replaced.Rick Castaņeda- - - - -Hmmm is backup PID in the field device likely to be a common enough practicefor 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? Ithink 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 somedegradation 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 previousemail addresses the subject. We are introducing instantiation in our devicesnext summer, preserving a default fixed structure. This characteristic givesflexibility, but also brings some problems in terms of maintenancemanagement, 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 solutionis 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 YOULOSE 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 answerit to you, but feel free to copy whoever you want.Raj raised an interesting point: not all PIDs are the same. Even if you havethe 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 theplant. There are considerable differences in the way you tune a series orISA type of algorithm, mainly when the derivative mode is used. There arevery refined details on the way people implement Derivative filters. Somesuppliers, like PLC manufacturers, have no or very simple filters, whereasDCSs have different degrees of sophistication. The dynamic behavior when theDerivative mode is used can be quite different from implementation toimplementation.Although different implementations do affect dynamic performance, only thetype of algorithm may cause real problems. For PID control (not PI or P) thetuning constants will differ and the tuning process will be different. Therefore it is important to select a single type of implementationthroughout 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 ismanipulated. 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 DOther (describe)There are other options in the PID that are nice, but will not be socritical.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 abackup for each other. It is a long and interesting discussion, butredundancy makes more sense in the same "domain". When a transmitter fails,control should go to manual and/or safe position, unless there are redundanttransmitters. If one is using control in the field, the PID in the valvewould go to this condition or, if the PID was in the transmitter, the valvewould 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 andin the field (which is not good). Tuning constants would not work properlyeven if the Control Algorithm is exactly the same.-If you switch from one controller to another, you should always have abumpless transfer. The back calculation path was introduced with thispurpose. If you connect the blocks as recommended, you may have differentdynamic behavior due to different PID implementations, macrocycle etc, butthe 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 willhave to be continually updated(I suggest that the DS form be made active, with a built in forms wizardthat presents a pull-down menu of algorithms and associated parameters; theform should include space for three algorithms)- the form requires a footer for drawing number, sheet, references, revisionnumber, 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 overthe 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 safetysystems 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 sametype of PID used by the Honeywell DCS. Our PID also offers two degrees offreedom for the control deviation. There are different implementationdetails and different options between FR and Honeywell, but the "look andfeel" of the control loop will remain the same. The differences that youwould see are the same type of differences you notice when you use differentscan rates or different instruments and/or instrument installation setups.My concern, in the email below, is with the devices using a very simple PIDimplementation. If you have a device with a parallel implementation and asystem with series, you will have different tuning process and dynamicbehavior mainly when Derivative is used. That's why we, Fisher Rosemount, decided to offer selectable options in ourPID 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 integrityand better performance. You can increase plant availability by keeping somecontrol loops running even if you loose the DCS controller(s) and I/Ocard(s). This is a quite interesting topic. The DCS can be dedicated to moreimportant tasks.If you have any question or if you want to discuss the subject. Feel free togive me a call;(952) 949 7002.Regards,Marcos- - - - > > 3. What is "Fieldbus locator"?Got me... [Verhappen.Ian] Jim Jamison proposed this version of the datasheet so hopefully he can tell us.> > 4. Minimum voltage is specified as 9 V in the standard. No need toask.This is correct. [Verhappen, Ian] Disagree since in many cases ourexperience has shown that the devices will not operate at less than 12volts. Does ITK 4 test this as well? If so you are right it does not need tobe included. > > 5. In rush current is specified as nominal plus 10 mA in thestandard.> > No need to ask.Actually, the device may draw up to plus 20mA during the first 20msec ofpower application (refer to the Physical Layer Test spec). Still thereis no need to ask. If there is a need to ask this question, there is aproblem with the device and it is not in compliance with the PL Test andFF 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. Thisterm is defined on page 27 of FF AG-165, "Fieldbus Installation & PlanningGuide" as:"The design process requires an indicator of which field devices areconnected to which bus segment. This requires that each bus segment isnumbered and that each device connected to the bus is given a number." This item will probably be more understandable if it were called segmentnumber. 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 sincethe actual segment assigns can not be made until well after the fieldinstrument data sheets are done.Regards,Charles- - - - Ian:I have been reading with great interest the discussion about PI FunctionBlock and where they should reside.I want to say that I agree with Mario's overall view that the PID should bein the field device, not the host. Also, the prospect of having PID FB inthe host and then switching to a PID FB in the field device when the hostfails is not very attractive to me especially when I realize the the FB inthe 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 willgive my opinion on this as well. I apologize for being so slow to interacton this subject as I am extremely busy currently in engineering (I'm with anEPC company)and advising on FF issues to 2 very large FF based projects inthe Oilsands world. I am the one who originally raised the issue of modifying FF InstrumentData Sheets with Ian and submitted the markup copy for his comments. Hesuggested we plant it out on the FUN list and I'm pleased to see the livelydiscussions evolving around it!In the EPC business where we are dealing currently with over a thousand FFpoints per project, we must identify both devices and segments in a logicalmanner for incorporation into the Instrument Data Bases (IDBs) whichgenerate many project deliverables such as Instrument Indexes, InstrumentData Sheets, Loop Sheets, Segment Drawings, etc etc. plus other non-IDBdocuments (layouts, wiring schedules, termination dwgs., location plans,etc)The FBL, as Charles mentions, is mentioned in FF AG-165 which is actuallyfrom the British document EEMUA Pub. # 189 "A Guide to Fieldbus Applicationfor the Process Industry"(1997). I know the principal author, Graeme Woodfrom my standards work on SP50 and IEC6-1158. This document is a goodstarting point for all EPC companies involved in FF applications but it isgetting a bit dated.My contact at the Fieldbus Foundation, Kurt, informed me that they arenot really pushing the use of this document currently and that otherdocuments will be forthcoming..ie: the document we all have been looking atgenerated by Ian and the FF EUC!!For example, there are references in the old document FBL section to "240devices max. per "Network" "...this all goes back to when Graeme wrote thedocument and there were no hosts available. Obviously, the limitation onthe max. number of devs., etc. rests with the vendor of the various hostsand H1 I/F cards.Now, specifically to the FBL, we have come up with an FBL composed ofPlant#, Unit/Area#, Sub-Area#, Controller/Processor#, Chassis#, Card/Slot#,Port#, Physic.Dev#. [note Phys Dev # NOT same as run-time Dev # but usefulin proj. doc'n.] This would symbolically look like this: PPUSCCMXXPDD. The Segment Numberis the first 10 digits of the FBL.Some of this involves manufacturer-specific info. In the case of ourFoxboro host on one of our projects (Fox IA with FBM 221 H1 I/Fs), simplyuse the Fox Letterbug addr as the main part of the FBL. In the case ofHoneywell and Delta V, we use the above mentioned FBL system, especiallyin 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 theoriginal D/S issue but could be in the IDB for later issues, if required.Best Regards,JimJ.E. (Jim) Jamison, P.Eng.- - - -This convention may work for your projects . . . if you have resolved tokeep segments "pure" and not have cross-area devices on segments. However,sometimes it's very practical . . . for example, if you tag utilities (likea cooling water or condensate flow) with a different Unit or Areadesignation than core process units, such utilities could very likely end up"geographically" amongst process unit devoted devices, and far from "likeunit / 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 remotejunction box.You may even decide that, philosophically, you have improved fault toleranceif 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) andalso by controller-card-port.We have to be careful when we direct EPC firms, because at some level thethinking stops and "blinders-on" application of rules takes over . . .especially when the Project Manager is pushing for another tick on theS-curve.I agree that the data on the proposed FF sheet is appropriate for theinstrument data base, index, etc., maybe later included on loop sheets orsegment diagrams (if you choose to have any "paper" ones). Much of it is notefficient or perhaps necessary for device procurement specifications, exceptmaybe on a "general classification" ("all pressure transmitters shall have .. . ") level. Then at least those suppliers that don't conform are obligedto 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 potentialconsultant 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 fixedfunction blocks would be good. As well a place for I.S. and Expcertificates.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 andthe> best I've worked with lists only the most commom function blocks. Thistype> of data-sheet can also group several tags to identify identicaldevices.> I've noted also that a special care with the word "segment" should betaken.> 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 Spraguedocument got me thinking that perhaps we should configure the data sheet toindicate which function blocks are available AND which function blocks areconfigured.Should we do both and if not which one should we use (configured oravailable)?Ian- - - - - Good idea Raj, except if we specify that the device must be FF registeredand the associated ITK rev number this will by default indicate that allblocks indicated as available on the data sheet are interoperable. Unless ofcourse you meant that we change the 'heading' 'available' to 'FFregistered'.Ian-----Original Message-----I don't know it this was mentioned but how about adding which functionblocks are FF registered on the datasheet. Knowing what is FF registeredwill assist in interoperability problems in the future.Raj KhemchandaniFieldbus Knowledge ManagerHoneywell 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 yoursRaj