Stephen Mitschke
August 12th, 2003, 01:28 PM
Please note that you MUST be an FF member to access this portion of thebulletin Board.Ian-----Original Message-----Per an action item from the December 5 EUC meeting at Lee College; Ihave posted the Transducer Block Application Process (TBAP) Part I andPart II Preliminary Specifications (Version 2.0) to the Download folderin the EUC Conference on the FF BBS.The TBAP - Part I specification describes the Transducer Block model.Part II specifies the first five standard transducer blocks: Flow,Level, Pressure, Temperature, and Valves.There is growing interest from the End Users in this area. I think thefollowing FUN messages from Herman Storey and Tom Boyd sums up theinterest in, and the current status of, these specifications.Dave GlanzerDirector of Technology DevelopmentFieldbus Foundation================ Begin FUM message from Herman Storey ==========From: Verhappen, Ian Sent: Thursday, December 13, 2001 8:42 AMSubject: [FUN] 3rd Party Valve Positioner Software Connectability viaHostWe had a short discussion of this topic at the FF End User Councilmeeting at Lee College last week. I will pass along some of my ideasand discussion from last week.First, the diagnostics available from Transducer blocks is still asubject of R&D and the vendors would like to capture some return ontheir R&D investment. I support the concept of vendors getting a returnon R&D investment because I want them to keep on investing. However, Ibelieve that some of the proprietary nature of display software isdriven by the desire to capture return.Second, the displays look different because the Transducer blocks aredifferent. They are different because the Transducer block standards atFF were never finished. There are drafts of transducer blocks for Flow,Level, Temperature, Pressure, and Valves as I understand it - in draftform. I think that transducer blocks would be much easier to display ifthese drafts were adopted and enforced. Vendors could still add neatstuff, but a lot of the basics would fit a standard format.FF offered to put the drafts on their bulleting board for members toreview possible action. I doubt any action will happen without a enduser push.Third, I have generally been able to see most of the transducer blockinformation by one means or another. The problem is that all the goodinformation may be in a less than user friendly form (like a big longparameter list that is a bit cryptic). So the information may beavailable in a from that is useless to maintenance technicians oroperators.If you can't see the transducer block information at all on your host,you have a host problem. If it is there but not user friendly, that issomething else again.Fourth, some of the features and functions in Transducer blocks don'thave a standard interface unless Menus and Methods are used. Somevendors have not made use of Menus and Methods. They are optional atthis time, but I would encourage vendors to support this functionality.I think that users could drive for more standardization in transducerblocks. There are many functions that look very similar between vendorsin these blocks, and there is no good reason to have some of the currentdifferences that lead to difficulty in displays.I do not believe that any effort outside the Fieldbus Foundation willhave a significant effect on compatibility of Transducer Block functionsand features. I think someone (probably an end user) who is afoundation member needs to lead this effort. I am not volunteering.Herman StoreyWTC - Automation Engineering======= End of FUN message from Herman Storey ================ Begin FUN message from Tom Boyd, Fieldbus Inc. =====From: Verhappen, Ian [verhappen.ian@syncrude.com]Sent: Monday, December 17, 2001 11:45 AMSubject: [FUN] 3rd Party Valve Positioner Software Connectability viaHostAs the most recent editor of the Transducer Block specification as wellas being a device developer, I would like to point out a few things. Ihave considered the Transducer Block specifications 'finished' for manyyears now. Whenever applicable we at Fieldbus Inc. follow them as ifthey were accepted specifications. The only reason they were neverbrought forward out of draft status was due to a lack of interest fromthe developers and the end-users. I for one would welcome input fromend-users and developers to update the specifications as necessary, andrelease them as specifications. Of course, the Foundation needs to bethe ones to push this forward officially, but if there is anything I cando to help, please let me know.Tom BoydFieldbus Inc.===============End of FUN Comment from Tom Boyd ========================