[FUN] Binary signals the Archilles' heel of Fieldbus Foundation?

[Stephen Mitschke]

[Verhappen, Ian] I have been asked to post this to the FUN group and mustapologize for not posting it sooner as I am still recovering (digging outfrom under) my e-mails while I was away. Sorry - Ian> Ian,> > Did you receive this mail? We are interessed in the reactions of the> members> of the FUN group?> > Chris> > > Ian,> > In the DSM lab trial tests we found out that there is a major gap> between> > the philosophy and the implementation of FF in the instruments. We> > discussed the results also with Bindert Douma of Shell Global Solutions> > and from that discussion I wrote the memo that you send you with this> > mail. Also Bindert confirmed himself with this memo.> > About this subject I also informed the NAMUR AK Fieldbus .> > Please send this memo to the others members of the FUN group. We are> > interessed in the reactions of the members of the FUN group.> > I am going on a holiday and intent to be back July 9. If you have> > questions please contact Chris Baltus of DSM> > regards> > > > Frans van Laak> > DSM Engineering-Stamicarbon> > > > <<Binary signals the Achilles heel of FF.doc>> > > > Disclaimer> 1. This e-mail is for the intended recipient only. If you have received it> by mistake please let us know by reply and then delete it from your> system;> access, disclosure, copying, distribution or reliance on any of it by> anyone> else is prohibited.> > 2. If you as intended recipient have received this e-mail incorrectly,> please notify the sender (via e-mail) immediately. This e-mail is> confidential and may be legally privileged. DSM does not guarantee that> the> information sent and/or received by or with this e-mail is correct and> does> not accept any liability for damages related thereto.> > <<Binary signals the Achilles heel of FF.doc>>

[Stephen Mitschke]

> Well, that is a bit of a shock, but at least it is an answer to a question> that has been plaguing me for a while; ie how do I handle my binary signal> from/to valves.> > It would seem in my instance, where we have NO continuous processes I> should have chosen Profibus PA instead of the FF which I have now invested> in.> > My installation is a fuel terminal, not processing plant, but even in our> processing plants, there are an insignificant number of analogue valves.> > Russell Mackenzie > Very Sad Engineer

[Stephen Mitschke]

> Hi Ian,> > One thing that is pretty important that DSM left out is MIO and FFB> devices. They currently aren't registered, but they are scheduled in> before the end of the year. Both of these would solve their problem. > > Also, if their vendor had put DI's (2 DI's for every DO) in their (DI)DO> box they wouldn't have any problems with response time. Instead they> tried to bring in the DI's through traditional I/O in the DCS and then> send the info on to the DO in the field. With this method the BEST round> trip time would be 4-5 sec's. By using a true DI/DO box (say 2 DI's, one> for Open, one for Close and the associated DO) the response time would> be in tens of milli seconds or faster. The actual delay would be the> execution time of the DI/DO blocks (somewhere around 10-20ms for both> blocks to execute) internal to the device, no communication over the> bus.> > So the problem isn't the FF technology itself, it is a lack of needed> instrumentation to solve "real" discrete applications. It is WAY beyond> me why vendors don't make a bus powered DI/DO box (say 8 DI's and 4> DO's)... It sure as heck isn't hard to do... you just have to watch the> current draw of the device... Only one VCR used for Client/Server and no> Pub/Sub VCR needed.> > The users of this group need to DEMAND solutions from the FF vendors...> > -Kurt

[Stephen Mitschke]

> Dear FUN members,> > This report is very interesting, and it may be good to mention that Smar > has just released a device like to one requested. 16 Discrete inputs and 8> > discrete outputs can be connected to the DC302. The DC302 also has > functions blocks to perform PLC like logic, including a flexible function > block that can programmed by a structured text based language, giving > extremely flexibility and power to this device, and keeping the single> loop > integrity concept.> The DC302 is externally powered, so even if the FF H1 network goes down> the > DC302 will keep working, it could even sense the network problem and take > some corrective actions.> > Best Regards,> > Claudio Fayad> > -----Original Message-----> From: Verhappen, Ian [SMTP:verhappen.ian@syncrude.com]> Sent: Monday, June 25, 2001 11:13 AM> Subject: [FUN] Binary signals the Archilles' heel of Fieldbus Foundation?> > > [Verhappen, Ian] I have been asked to post this to the FUN group and must> apologize for not posting it sooner as I am still recovering (digging out> from under) my e-mails while I was away. Sorry - Ian> > > Ian,> >> > Did you receive this mail? We are interessed in the reactions of the> > members> > of the FUN group?> >> > Chris> >> > > Ian,> > > In the DSM lab trial tests we found out that there is a major gap> > between> > > the philosophy and the implementation of FF in the instruments. We> > > discussed the results also with Bindert Douma of Shell Global> Solutions> > > and from that discussion I wrote the memo that you send you with this> > > mail. Also Bindert confirmed himself with this memo.> > > About this subject I also informed the NAMUR AK Fieldbus .> > > Please send this memo to the others members of the FUN group. We are> > > interessed in the reactions of the members of the FUN group.> > > I am going on a holiday and intent to be back July 9. If you have> > > questions please contact Chris Baltus of DSM> > > regards> > >> > > Frans van Laak> > > DSM Engineering-Stamicarbon> > >> > > <<Binary signals the Achilles heel of FF.doc>>> > >> > Disclaimer> > 1. This e-mail is for the intended recipient only. If you have received > it> > by mistake please let us know by reply and then delete it from your> > system;> > access, disclosure, copying, distribution or reliance on any of it by> > anyone> > else is prohibited.> >> > 2. If you as intended recipient have received this e-mail incorrectly,> > please notify the sender (via e-mail) immediately. This e-mail is> > confidential and may be legally privileged. DSM does not guarantee that> > the> > information sent and/or received by or with this e-mail is correct and> > does> > not accept any liability for damages related thereto.> >> > <<Binary signals the Achilles heel of FF.doc>>> > << File: Binary signals the Achilles heel of FF.doc >>

[Stephen Mitschke]

> Dear All,> > I hope that many manufacturers of switches, on/off valves and variable> speed> drives are following this thread. The FOUNDATION(tm) technology and> architecture supports discrete devices of the kind the author calls for.> Manufacturers have been slow putting discrete devices on the market.> However, over the past few months things have changed with exciting new> products from Smar and others.> > Let me bring you all up to speed with some new information that I hope put> the situation in a more favorable light:> > 1. Discrete points exist but will be reduce. This is because valve> limit> switches are built into the Fieldbus positioners. Low-cost pressure> transmitters are used instead of pressure switches because on on/off> signal> has no diagnostics and is therefore dangerous. Reversible electrical> actuators are available from several manufacturers.> > 2. Recently devices for "simple" discrete I/O have been introduced. At> Smar> we make one called DC302 that has 16 DI and 8 DO. It can do logic using> local I/O or I/O communicated over the bus, a bit like a PLC as requested.> Local I/O need not be communicated over the bus therefore reducing links> (CDs and VCRs) minimizing impact on communication cycle.> > 3. I agree bringing discrete I/O to the host or remote I/O is Stone> Age.> However, when the discrete I/O is made available as regular FOUNDATION(tm)> DI and DO blocks they integrate homogenously into the FOUNDATION(tm)> programming language without mapping to proprietary languages. I.e. you> can> for example connect a discrete input to the TRK_IN_D input of a PID block> with great ease. This works pretty OK.> > 4. Field mounted converters from Fieldbus to 4-20 mA, from 4-20 mA to> Fieldbus and for Fieldbus to 3-15 psi have been available since Fieldbus> devices were first released. We make these at Smar called FI302, FI302 and> FP302 respectively. These are ideal for integrating existing equipment and> device types not yet available in Fieldbus versions, such as a variable> speed drive for instance. However, these have been looked upon as> "transitional" products or "hybrids" and never got much limelight because> they are not purebred Fieldbus. I agree with the author that this approach> is better than using conventional I/O in the host.> > 5. These analog and discrete converters can be connected one the same> network, just like "regular" Fieldbus devices. They use the standard> function blocks and integrate seamlessly in the network architecture and> control strategy. You get single loop integrity.> > 6. Now that the HSE technology has been out for more than a year the> first> registered products are already in the market. Hopefully we will see> variable speed drives based on H1 or HSE in a not too distant future.> > 7. A few of the function blocks in the FOUNDATION(tm) programming> language> handle discrete logic. In addition, the flexible function block (FFB)> allows> other programming languages to be integrated with the standard> FOUNDATION(tm) blocks, e.g. the standard IEC 61131-3 languages that> include> the loved and hated ladder diagram.> > 8. I don't get to the same conclusion. The PROFIBUS-DP discrete boxes I> have> seen at exhibitions are remote I/O units for PLCs, i.e. a second> conventional infrastructure wires to these boxes before they get on the> network. I see the DP network as remote-I/O level bus. As the author> pointed> out in the aticle, remote I/O has disadvantages similar to direct host> connection so I don't see the advantage (nor drawback) of PROFIBUS for> conventional I/O. Are there any PROFIBUS-DP proximity switches? Moreover,> DP> is not as sophisticated as PA (or FF-H1). DP does not have the concept of> physical, transducer and function blocks to keep the information valuable> for maintenance etc. The discrete devices existing for PROFIBUS-PA appear> to> be available in an FF-H1 version too. You can do fast remote-I/O with> existing HSE products too - plug in the conventional I/O modules and put> it> in the field. Use a fiber optic transceiver if the distance is long.> > My conclusion is that all need to do some homework: FF needs some variable> speed drives. PROFIBUS needs to merge the capability of PROFIdrive> (publisher-subscriber and time-synch) and PA (acyclic and blocks) with> PROFInet (Ethernet+TCP/IP) and ensure products are made available with the> standard EDDL (device description) or DTM (configuration tool ActiveX).> > Again, many of these points have emerged very recently. Only a few months> back FF was indeed significantly weaker in discrete.> > Jonas

[Stephen Mitschke]

> Please understand that I am no expert in either Foundation Fieldbus or> Profibus. I am an expert in ISA/ANSI S50.02 and IEC 61158 the fieldbus> standards. > > Naturally it is possible to missuse Foundation Fieldbus. While the> standards were drafted to apply to all applications, Foundation Fieldbus> was drafted to solve the one problem of replacement of 4-20mA analog with> digital data for process control applications. Many of the features of> the standard were not used to handle discrete controls as for factory> automation or batch process control.> > The current problem exists when the digital data is present in more than> one network node, requiring several data accesses to get the data. Our> original intent was that such an installation is not compatible with a> fieldbus. We always intended that digital data be aggregated into field> instrumentation or valve positioners. If this is the case, the digital> data is simply an extension of the normal data structure and is accessed> as the LSAP (Link Service Access Point), the buffer of structured data> obtained during the publishing cycle scheduled by the LAS. No additional> data scans are necessary. At worst, a whole digital PLC-like node would> be available to be able to access binary data in buffer sets like Profibus> accesses data. A digital node was defined in TR50.02 (the process control> function block report) that allowed buffers of tag-named digital data to> be published as a single LSAP in a single transfer. FF attempts to> address digital data by tag name, while PB only addresses registers of> data allowing the host to decode the register to get the desired bit. > > So, the foundation only needs to define a digital block as defined in the> ISA publication of TR50.02. > > Dick Caro > ARC Advisory Group

[Stephen Mitschke]

> Hi Ian,> > One more thing I want to add. There are already registered device> solutions available for discrete valve operations. There are discrete> valves already registered and there is also a retrofit solution> available for existing pneumatic On/Off valves (Pepperl+Fuchs model> FD0-VC-Ex4.FF, info available on the FF web site). The P+F solution is> pretty cool... as far as I know it's the only one of it's kind> available...> > -Kurt

[Stephen Mitschke]

IanSyncrude Canada Ltd.PO Bag 4009, MD 0032Fort McMurray, AB T9H 3L1P 780 790-4079, Cell -799-6017F 780 799-5190verhappen.ian@syncrude.com> -----Original Message-----> From: Peluso, Marcos [FRCO/RTC] [SMTP:Marcos.Peluso@EmersonProcess.com]> Sent: Tuesday, June 26, 2001 2:45 PM> To: 'Verhappen, Ian'> Subject: RE: [FUN] Binary signals the Archilles' heel of Fieldbus> Foundati on?> > FUN members,> > There are several Fieldbus devices being released for discrete Inputs and> Outputs. These devices can publish the information of individual points or> they can have fan in /fan out capability, i.e., several points combined in> the same message.> Important point is to have control logic capability at the device level. A> lot of the processing can be done locally, very fast. The bus would be> used> only for monitoring or to transfer data to other devices when needed.> The Flexible Function block, Multiple Input/Output blocks are there to> address these issues. Even DIs and DOs were designed to send more than> just> one bit of information. The Device Control Function block explain how it> works.> The logic calculation part should run fast. Output updates should not wait> for the macro cycle.> Rosemount will be releasing a device with 8 Inputs and 4 Outputs. The> first> release will be a four wire device that can drive standard solenoid> valves.> The second release will be a two wire, Intrinsically safe device.> > Regards,> > Marcos- - - - - - - - - - - -FYI: We (Emerson Process Management) have a single device that is a 8 DINand 8 DO. Gary would know how this is powered.Duncan<<DIDO.jpg>>

[Stephen Mitschke]

I also think we need to have manufacturers look at how to minimize theexecution time of their function blocks as a way to reduce the overallcycle. This also becomes relevant for fast executing analogue loops as well.Ian> Fieldbus Inc. has considered this issue and continues to develop products> to fill the needs of fieldbus users. We are pleased that our latest> product, the Discrete Control Block device, can serve a variety of> discrete control applications. For more information visit the Fieldbus> Inc. website at http://www.fieldbusinc.com> > Best Regards,> Sean Vincent> Fieldbus Inc.

[Stephen Mitschke]

> Dear All,> > I hope that many manufacturers of switches, on/off valves and variable> speed> drives are following this thread. The FOUNDATION(tm) technology and> architecture supports discrete devices of the kind the author calls for.> Manufacturers have been slow putting discrete devices on the market.> However, over the past few months things have changed with exciting new> products from Smar and others.> > Let me bring you all up to speed with some new information that I hope put> the situation in a more favorable light:> > 1. Discrete points exist but will be reduce. This is because valve> limit> switches are built into the Fieldbus positioners. Low-cost pressure> transmitters are used instead of pressure switches because on on/off> signal> has no diagnostics and is therefore dangerous. Reversible electrical> actuators are available from several manufacturers.> > 2. Recently devices for "simple" discrete I/O have been introduced. At> Smar> we make one called DC302 that has 16 DI and 8 DO. It can do logic using> local I/O or I/O communicated over the bus, a bit like a PLC as requested.> Local I/O need not be communicated over the bus therefore reducing links> (CDs and VCRs) minimizing impact on communication cycle.> > 3. I agree bringing discrete I/O to the host or remote I/O is Stone> Age.> However, when the discrete I/O is made available as regular FOUNDATION(tm)> DI and DO blocks they integrate homogenously into the FOUNDATION(tm)> programming language without mapping to proprietary languages. I.e. you> can> for example connect a discrete input to the TRK_IN_D input of a PID block> with great ease. This works pretty OK.> > 4. Field mounted converters from Fieldbus to 4-20 mA, from 4-20 mA to> Fieldbus and for Fieldbus to 3-15 psi have been available since Fieldbus> devices were first released. We make these at Smar called FI302, FI302 and> FP302 respectively. These are ideal for integrating existing equipment and> device types not yet available in Fieldbus versions, such as a variable> speed drive for instance. However, these have been looked upon as> "transitional" products or "hybrids" and never got much limelight because> they are not purebred Fieldbus. I agree with the author that this approach> is better than using conventional I/O in the host.> > 5. These analog and discrete converters can be connected one the same> network, just like "regular" Fieldbus devices. They use the standard> function blocks and integrate seamlessly in the network architecture and> control strategy. You get single loop integrity.> > 6. Now that the HSE technology has been out for more than a year the> first> registered products are already in the market. Hopefully we will see> variable speed drives based on H1 or HSE in a not too distant future.> > 7. A few of the function blocks in the FOUNDATION(tm) programming> language> handle discrete logic. In addition, the flexible function block (FFB)> allows> other programming languages to be integrated with the standard> FOUNDATION(tm) blocks, e.g. the standard IEC 61131-3 languages that> include> the loved and hated ladder diagram.> > 8. I don't get to the same conclusion. The PROFIBUS-DP discrete boxes I> have> seen at exhibitions are remote I/O units for PLCs, i.e. a second> conventional infrastructure wires to these boxes before they get on the> network. I see the DP network as remote-I/O level bus. As the author> pointed> out in the aticle, remote I/O has disadvantages similar to direct host> connection so I don't see the advantage (nor drawback) of PROFIBUS for> conventional I/O. Are there any PROFIBUS-DP proximity switches? Moreover,> DP> is not as sophisticated as PA (or FF-H1). DP does not have the concept of> physical, transducer and function blocks to keep the information valuable> for maintenance etc. The discrete devices existing for PROFIBUS-PA appear> to> be available in an FF-H1 version too. You can do fast remote-I/O with> existing HSE products too - plug in the conventional I/O modules and put> it> in the field. Use a fiber optic transceiver if the distance is long.> > My conclusion is that all need to do some homework: FF needs some variable> speed drives. PROFIBUS needs to merge the capability of PROFIdrive> (publisher-subscriber and time-synch) and PA (acyclic and blocks) with> PROFInet (Ethernet+TCP/IP) and ensure products are made available with the> standard EDDL (device description) or DTM (configuration tool ActiveX).> > Again, many of these points have emerged very recently. Only a few months> back FF was indeed significantly weaker in discrete.> > Jonas

[Stephen Mitschke]

We're back now until the end of the month.In addition, we now have the FUN list on Archive, so you can follow any ofthe threads and history if you wish. To enter from the BBS log in, selectthe Member Conferences Icon, then the User Forums Icon, and lastly the FUNList Archives Icon to see all the messages.The archives are available on the BBS at this address:http://www.bbs.fieldbus.org/Login/EUC%20Conferences/User%20Forums/EuF%20Fun%20List%20Archives/The above line may be broken by an 'automatic' carriage return so please besure it ends with 20Archives/ NOTE: below that you may also have to create aBBS account to access the web site.The user must have an account on the BBS, since clicking the above link willrequest a username/password. If they don't have a BBS account, direct themto:http://www.fieldbus.org/bbs Ian> -----Original Message-----> > The device is bus powered.> > The field signals use standard DeltaV I/O cards - thus are separately> powered. Can take AC or DC cards> > Gary> > -----Original Message-----> > fyi: We have a single device that is a 8 DIN and 8 DO. Gary would know how> this is powered.> > Duncan

[Stephen Mitschke]

> BP is using the DeltaV "H1 Carrier" in the configuration that was being> sold> in 1q2001.> > Ours is not a "bus powered" device, at least not per my definition. I> suppose the "carrier" itself may be, but the individual I/O cards require> a> separate power supply. Both DI and DO need such a power supply. This> raises> some of the same issues we have with "legacy" remote I/O, for example:> > * Do I want to string my 120 VAC UPS around the plant? (IMHO I'd rather> not)> > * Do I want to string my high-integrity 24 VDC auctioneered I/O power> around> the plant? (not me)> > * Do I want to rely on a "local" 24 VDC power supply and "field" quality> AC?> (Not particularly)> > That said, I am using it with "local" 24 VDC power, hedging that> diagnostics> will tell me when the local power goes down, and this won't happen at the> same instant my control scheme needs this I/O, and also with the> realization> that if the "field" AC goes down, the MOV's I'm moving won't have power> either.> > What would be better would be a purely bus-powered incarnation of this> device (and also one that had interoperability certification). That way, I> can install a suitably redundant (or not) segment power conditioner at the> control house end, and be done with it. I accept that we'll still have> issues with field power of some DO's (due to current limitations) . . .> > John Rezabek