View Full Version : [FUN] 3rd Party Valve Positioner Software Connectability via Host
Stephen Mitschke
August 12th, 2003, 01:25 PM
Hi Ian,Another FUN list question (that maybe ties in with OPC DX and FDT ?): From my 'users' viewpoint, major FF benefits are interoperability andrich diagnostics. But, currently, it doesn't seem that I can have bothof these benefits at the same time. For example, if I'm using aYokogawa CS3000 FF Host and Fisher DVC FF valve positioners on the H1segments, I want to be able to access ALL Fisher FieldVue diagnosticinformation via the Yoko HOST system (e.g. I don't want to connect alaptop to the segment). But that can't currently be done. Can anyone describe why not? Whatwill it take to get it? Is there work underway to provide thisconnectability? Jim Sprague (Aramco)
Stephen Mitschke
August 12th, 2003, 01:25 PM
We have in depth experience with the various diagnostics tools in FF devicesand the visibility at the different DCS systems. It does not tie in with OPCDX but more with standardising vendor specific FF parameters in templatesand maybe with methods and menus.In our multivendor FF test site we demonstrate why it seems that somediagnostic information is not visible and what can be done to overcome this.But clearly it requires more than what can be communicated through thisforum.Jim do you use only CS3000 or do you also have PRM (without PRM you will nothave a platform for diagnostics similar to AMS).? Come done to A'dam and seewhy and/or how.______________________________________________ _____With kind regards, Met vriendelijke groetenBindert Douma OGESShell Global Solutions International B.V.
Stephen Mitschke
August 12th, 2003, 01:25 PM
Dear Jim,FF provides a standard way to make any data available to the hostsystem, which is the Function Block or a Transducer Block. If you getSmar's FY302 for instance, all the diagnostic information, like traveltime, strokes, mileage and others, are available directly from thetransducer block.The transducer block on its turn, can be read or accessed from any hostsystem.I believe that in your case you have one of two possible scenarios:1. The positioner manufacturer have decided not to make any diagnosticvalue available through FF blocks.2. The Host system you are using is not fully compliant with FF andcannot see all FF blocks available in the positioner you are using.The only thing FF does not provide you is a standard way to see thedata, such as graphics and all. This would have to be set-up in the hostsystem you are using, either on the HMI or on the Device managementsoftware.Best Regards,Claudio Fayad (Smar)
Stephen Mitschke
August 12th, 2003, 01:26 PM
Hi, Jim,Jim>For example, if I'm using aJIm>Yokogawa CS3000 FF Host and Fisher DVC FF valve positioners on the H1Jim>segments, I want to be able to access ALL Fisher FieldVue diagnosticJim>information via the Yoko HOST system (e.g. I don't want to connect aJIm>laptop to the segment).I understand as follows.1) Your concern is the valve helper package such as FIEDVUEvalve link package, VL2000 with valve calibration functionand valve diagnostics function.2) You do not connect a laptop computer including a valve link packageto the H1 segment.3) You hope that the device management package by any vendorintegrates 3rd vendor Helper package.4) For example, you want to access Valve's "Signature" functionfor Fisher's valve via DCS control bus from 3rd vendor Valve Linkpackage on Yokogawa system, PRM .We understand this situation.But item 3) is not easy because the interface isdifferent between the device management package and the3rd vendor helper package.We also have a valve helper package, Yokogawa ValveNaviincluding Valve Signature function for Yokogawa Advanced ValvePositioner, YVP.But this ValveNavi shall not perform on other Vendor device managementpackage at the moment.Bindert>We have in depth experience with the various diagnostics toolsBindert>in FF devices and the visibility at the different DCS systems.Bindert>It does not tie in with OPC DX but more withBindert>standardising vendor specific FF parameters in templatesBindert>and maybe with methods and menus.I agree Bindert's comment. The DD method function for vendor specificFF parameters provides standard templates.Our packages, PRM (Plant Resource Manager) or DMT (Device ManagementPackage) is already supporting the execution function of providedDD Method by device vendor.Also, we can provide the DD method function for Valve Calibration andDiagnostics in our YVP.In addition, if you want to see valve diagnostic parameterswithout using of any package on CENTUM standard displayincluding Graphic Display, Trend Display, Control Faceplate Displayand etc.Now we can provide this function on CENTUM CS3000 R3.I show its example on the attached sheet.(See attached file: Display_Sample.pdf)Best Regards,Takehiro Ishikawa,Yokogawa Electric Co.
Stephen Mitschke
August 12th, 2003, 01:26 PM
We had a short discussion of this topic at the FF End User Council meetingat Lee College last week. I will pass along some of my ideas and discussionfrom last week.First, the diagnostics available from Transducer blocks is still a subjectof R&D and the vendors would like to capture some return on their R&Dinvestment. I support the concept of vendors getting a return on R&Dinvestment because I want them to keep on investing. However, I believethat some of the proprietary nature of display software is driven by thedesire to capture return.Second, the displays look different because the Transducer blocks aredifferent. They are different because the Transducer block standards at FFwere never finished. There are drafts of transducer blocks for Flow, Level,Temperature, Pressure, and Valves as I understand it - in draft form. Ithink that transducer blocks would be much easier to display if these draftswere adopted and enforced. Vendors could still add neat stuff, but a lot ofthe basics would fit a standard format.FF offered to put the drafts on their bulleting board for members to reviewpossible action. I doubt any action will happen without a end user 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 be availablein a from that is useless to maintenance technicians or operators.If you can't see the transducer block information at all on your host, youhave 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't have astandard interface unless Menus and Methods are used. Some vendors have notmade use of Menus and Methods. They are optional at this time, but I wouldencourage 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 vendors inthese 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 will have asignificant effect on compatibility of Transducer Block functions andfeatures. I think someone (probably an end user) who is a foundation memberneeds to lead this effort. I am not volunteering.Herman StoreyWTC - Automation Engineering
Stephen Mitschke
August 12th, 2003, 01:26 PM
Mr. Storey is right. The drafted standard transducer blocks are great.Although these drafts are always extended upon, the standardized part isvery helpful. It appears to me as if many manufacturers have realized this.I look into the pressure transmitters in the SYSTEM302 device library andfound six out of the eight manufacturers I checked follow the standardparameters. One of the other two was only off by two paramters. I guessratifying these specs is no more than a formality.Just to give an idea what these standard parameters do: Diagnostics,Scaling, Perform calibration and review at which calibration last was done,inform minimum span, sensor type, sensor range, sensor serial number, reviewcalibration record including calibration method, calibration location anddate, who performed it. Diaphragm material (pressure), sensor wiring(temperature), fill fluid (pressure) and sensor/cold-junction temperature.BTW. It's in the bookStill, on top of this good stuff, a mechanism for the device manufacturer totell the host to plot a graph or histogram would be good.Best regards,Jonas BergeSmar
Stephen Mitschke
August 12th, 2003, 01:26 PM
As the most recent editor of the Transducer Block specification as well asbeinga device developer, I would like to point out a few things. I haveconsidered theTransducer Block specifications 'finished' for many years now. Wheneverapplicable we at Fieldbus Inc. follow them as if they were acceptedspecifications. The only reason they were never brought forward out of draftstatus was due to a lack of interest from the developers and the end-users.I forone would welcome input from end-users and developers to update thespecifications as necessary, and release them as specifications. Of course,theFoundation needs to be the ones to push this forward officially, but ifthere isanything I can do to help, please let me know.Tom BoydFieldbus Inc.
vBulletin® v3.8.7, Copyright ©2000-2012, vBulletin Solutions, Inc.