There are several reasons to consider FI. First, we are vendor neutral. This means that we do not have a particular line of field devices or control systems that we support or promote. Our recommendations and solutions are based on your specific situation - not on what we have to sell. Also, fieldbus technology support and implementation is our specialty. Since we spend our time on industrial communication protocols, we provide objective solutions that save you time and money.

We can help in several ways. First, by educating your project team on fieldbus technology, everyone develops a common understanding of the issues. Then, we develop a set of criteria based on the stated project objects. We work together to develop a specification, and then help you independently evaluate proposals by translating the proposal to match the stated criteria. The bottom line - you add needed fieldbus expertise to your team at the beginning of the project to insure success and lower risk

In many cases, YES. Our experienced engineers can show you how to migrate applications to fieldbus based on your specific needs, budget and project objectives

We specialize in industrial communication protocols. Sorting out which technology is best for you is our specialty. By working together, we develop a communication strategy that identifies the right technology for the right application

Mode is a parameter of four parts: actual mode, target mode, permitted mode and normal mode.
Target mode may be set and monitored by a user. Target mode determines which mode the user wants the block to transfer. Actual mode is set by the block during its execution and reflects the mode used during execution. The allowed target modes are defined by permitted mode. Normal mode is the desired operating mode of the block.

Possible modes supported by devices are:

Remote-Output (Rout)
Remote-Cascade (RCas)
Cascade (Cas)
Automatic (Auto)
Manual (Man)
Local Override (LO)
Initialization Manual (IMan)
Out of Service (O/S)

When a block is in Out of Service, it will not run and the associated data will have a Bad Status. Parameter configurations are usually performed in Out of Service mode so there is no bump in a running process. Before a particular block will be usable in a configuration, the mode must not be Out of Service and block specific parameters may need modification.

Input and Output parameters have a value, and status. The status tells the condition of the value. If the data is Bad, Uncertain, Good (cascade), or Good (non-cascade). A sub-status tells more about the value, such as possible reasons for the status. The Quality narrows the conditions even more.

Channels map transducer block data to function block parameters. Manufacturers determine the value associated with specific data. Users must be aware of the channel associated with the desired data. There are possible manufacturer specific interlocks that allow certain input channels when specific output channels are used.

Virtual Communication Relationship (VCR) are application layer “channels” that provide for the transfer of parameter data and other types of data between devices or a device and host.

Each input and output that enters or leaves a device requires a VCR. Connections between blocks in the same device do not use VCRs. A device must have enough VCRs to connect inputs, outputs, alarms, and trends in a meaningful manner.

Every device must have at least one permanently configured, standardized management VCR. The standardized permanent VCR is for establishing communications with devices. Every fieldbus device has at a minimum one VCR in use at all times. This is a requirement of all FF devices.

The number of VCRs in a device vary by manufacturer, but the number should be similar in same type blocks. The maximum number of VCRs allowed can be used as a comparison of devices.

For any registered Discrete Input or Output block, the number of connections to the outside world are specified.

For a Discrete Output Block, 5 outputs can be linked:
CAS_IN_D
BKCAL_OUT_D
OUT_D
Alarms
Trends

For a Discrete Input Block, 3 outputs can be linked:
OUT_D
Alarms
Trends

For an Analog Output Block, 5 outputs can be linked:
CAS_IN
BKCAL_OUT
OUT
Alarms
Trends

For a Analog Input Block, 3 outputs can be linked:
OUT
Alarms
Trends

For a PID block, 10 outputs can be linked:
IN
CAS_IN
BKCAL_IN
TRK_IN_D
TRK_VAL
FF_VAL
OUT
BKCAL_OUT
Alarms
Trends

Don’t forget that multiple links to one parameter are possible, so VCRs can exceed the numbers listed. In most applications multiple links to a single parameter will not be used. Typical connections are one or two VCRs per block.

Assuming the user configures a single DO with a multi-state discrete channel, the typical discrete device will use one VCR that counts against the DeltaV limits. DeltaV sells more links in packages, so the limit can easily be changed. The permanent management VCR does not count against the maximum number allowed.

Foundation fieldbus output blocks have a READBACK parameter. For different CHANNELs it may show different values. Control schemes may use the READBACK value to reflect the actual state of the affected controlled element.

To enable READBACK in any standard Foundation fieldbus output block two options must be verified.

In the RESOURCE block, FEATURE_SEL must include bit 5-"Out readback"
(FEATURE_SEL && 0x20) To change FEATURE_SEL, the RESOURCE block must
be in Out Of Service.

In the Discrete Output block, the IO_OPTS Bit 9-"Use PV for BKCAL_OUT"
must not be selected. Be sure the DO block is in Out Of Service before
modifying IO Options.

OEM is revision C, Development is revision B. Development boards require additional 3V of power to burn. The power must be applied via the BDM plug.

The optimum timing is supposed to be as fast as possible. The Fieldbus Foundation provides default bus timing values. The FF default timing is the slowest allowable bus timing. Most manufacturers have devices that run faster than these settings. The bus timing must be slowed to the slowest device on the bus. defaults were much faster than the FF defaults. Devices operating slower than a host can create serious problems, so it is best to start the host slow and adjust to the faster settings of the devices. A device, no matter how fast it runs, must function on a slower network, since it is possible that a device may be used on a network with slower devices.

T1 is a parameter that describes the expected response delay of the device at a given address. Normally, you will not need to increase this parameter; however, if it appears that your interface card is not seeing the device's responses related to setting addresses, you can increase this value. The correct value for this parameter can be dependent on the number of devices on the link. For example, if you are using a bus monitor, you might see a WHO_HAS_PD_TAG request going to the device to start the Set Address sequence, and an IDENTIFY response coming back, but with the host never continuing on to the next step of the protocol (the SET_ADDRESS packet). This would probably mean that your T1 value is too small and should be increased.

T3 is a parameter that describes the expected time for the device to respond at its new address. This parameter is highly dependent on the number of devices on the link, and the number of addresses being polled (see "Setting Number of Polled Addresses" later in this file for instructions on how to set the number of polled addresses). If you are using a bus monitor, you may be able to see the host identify a device (with the IDENTIFY packet) at the new address, BEFORE the devices has sent its probe response (PR) packet to the host. This is an error that is indicative of a T3 value that is too small; if this occurs, increase your T3 value until the IDENTIFY to the new address occurs AFTER the PR.

All of the System Management Info timers are in units of 1/32 of a millisecond; for instance, T3=32000 units means that T3=1 second.

1) The PCMCIA card is not compatible with Windows 2000
2) Be sure to use the PCMCIA.sys driver from Microsoft. Sometimes vendors replace this driver with their own version. Verify from WinNT I386\system32\drivers\pcmcia.sys
3) Verify hardware revision on back of card, under bar codes is a number #####X-##. If X is B, then card should be returned to NI for upgrade.
Some notebook computers use a 3.3V cardbus, but support PCMCIA up to 5V. Be aware that the NI H1 PC card draws 500mA @ 5V, this exceeds the available power on some notebooks. Check with the notebook vendor before making the purchase.
4) After starting WinNT, the card must be started manually. Choose Start Menu, Settings, Control Panel, Devices. Scroll down to NIFB, if the service is unavailable, reinstall the software. If the status of the NIFB device is no started, then choose Start, wait for the device to start, then Close.
5) Verify the card is installed. Select Interface Config from the National Instruments Menu. If a Board is present, select it, then select Edit. If the board is not selected as PCMCIA, delete it and choose Add Interface Board.
6) After verifying the NIFB device started, start NIFB.exe from the NIFBUS menu.

Repeaters are active bus powered, or non-bus powered devices, used to extend a fieldbus network. A maximum of four (4) repeaters and/or active couplers can be used between any two devices on a fieldbus network. Using four repeaters, the maximum distance between any two devices on that network is 9500 meters (31,168 ft. or 5.9 miles). Repeaters are discussed in IEC/ISA Physical Layer Standard, Section 22.2.2 and briefly in Fieldbus Foundation Application Guides FD-043 Revision 2.0 (Technical Overview) and AG-140 Revision 1.0 (31.25kbit/s Wiring and Installation).

Several companies currently offer fieldbus repeater products. Some repeaters, as other devices, work better in certain applications rather than other applications. It is best to contact each company for specific information on their offerings.

Please note that repeaters are support tools and are not registered products from the Fieldbus Foundation. The Fieldbus Foundation only registers interoperability of devices and verifies some functions of hosts, support products receive no formal review from FF.

In many applications, repeaters are not necessary since there are alternates to using repeaters. One method is to use the Fieldbus Intrinsic Safety Concept (FISCO). FISCO is not yet a complete standard, but the preliminary specification is in review and several manufacturers provide products they claim are conformant to the specification. Another method of increasing the number of devices in IS is to use a high current (10A) explosion proof homerun joined to several IS barriers. In this option, the homerun joins several spurs in an explosion proof housing, each spur has a barrier allowing 3-4 devices. Each device resides on an IS spur of the segment and can still communicate across the barriers. With this option, the limitation is on bandwith of the homerun cable, not on the current limits of the segment.

If set, no writes from anywhere are allowed, except to disable WRITE_LOCK. Block parameters will continue to be updated by transducer values and control will continue. This is useful when a device is configured and you want to prevent anyone from making changes to it. Two steps are required to enable write protection. First, the write_lock jumper must be installed on the device. Second, write_lock must be written to enable. To verify write_lock is active, read the BLOCK_ERR parameter. When write_lock is disabled, the block error will clear. There is only one WRITE_LOCK parameter for the device, it is located in the Resource Block.

Short Answer on SIMULATE and SIMULATE_D:
SIMULATE_D allows the transducer's discrete input or output to the block to be manually supplied when simulate_d is enabled. When simulation is disabled, the simulate value and status track the actual value and status. Each input or output block has an individual simulate parameter and can be enabled or disabled separate from any other block. To enable simulate a two step process is used. First, the simulate jumper must be installed on the device. Second, the simulate must be written to enable. To verify simulate is active, read the BLOCK_ERR parameter. When simulate is disabled, the block error will clear. Simulate should not be used in an operating plant because it was designed for testing only. It does not provide bumpless transfer and should be ignored by users.

All discrete input and output function blocks have a SIMULATE_D parameter. To use the simulate_d parameter, a two step process is necessary.

First, the simulate jumper must be placed on the device. Second, the simulate_d parameter must be enabled.

The simulate_d parameter contains a pair of status and values, and an enable/disable switch. Think of the simulate_d parameter as a switch on the interface between the I/O function block and the associated transducer block or hardware channel.

For inputs, the transducer value and status come from the transducer block or input channel, and contain what will be sent to the input block if the switch is off (disabled). The simulate_d value and status are presented to the input block when the enable switch is on, and the transducer block or input channel is ignored. The status can be used to simulate_d transducer faults. The transducer value and status will always be written with transducer data at each evaluation of the input function block.

For outputs, the simulate_d value and status become the READBACK value and status when the enable switch is on, and the transducer block is ignored. The status can be used to simulate_d transducer faults. The transducer attribute value and status reflect the transducer readback value and status when simulation is enabled and the transducer maintains last output and ignores the OUT of the Output block.

It is necessary to show that a block has a simulate_d value, without touching the status of parameters that may be linked elsewhere. The block error parameter indicates when simulation is active. When disabled, the simulation parameter takes on the value and status it would supply if enabled. It is not possible to provide a bumpless transfer from enabled to disabled. It is not useful to enable simulation in an operating plant, so this is not important. The parameter will always initialize to disabled and will be stored in dynamic memory.

Block Error reflects the error status associated with the hardware or software components associated with a block. Since it is a bit string, multiple errors may be active at the same time. The enumerations for the Block Errors are listed in the FF common definitions known as the Standard Parameters Device Description Language.

0 = Other (LSB)
1 = Block Configuration Error
2 = Link Configuration Error
3 = Simulate Active *
4 = Local Override
5 = Device Fault State Set
6 = Device Needs Maintenance Soon
7 = Input Failure/ process variable has BAD status
8 = Output Failure
9 = Memory Failure
10 = Lost Static Data
11 = Lost NV Data
12 = Readback Check Failed
13 = Device Needs Maintenance Now
14 = Power-up
15 = Out-of-Service

*For the resource block, Simulate Active will be used to indicate that the simulate hardware jumper is present. An active state (1) of this attribute will indicate that the jumper is present and that it is possible for the user to enable simulation in an input or output class function block.

Overview
The FAULT_STATE parameter defines the action taken by a block when stale data or communication failure is detected. Fault State is also used when bad or uncertain quality is specified for each block. Function blocks that provide process input will have parameters to allow a special “Fault State” action to be specified on detection of an input with bad or uncertain quality.

Description
The FAULT_STATE parameter is included in the resource block since it is common to function blocks and transducer blocks. The Fault State parameter determines the response of an output block if one or more Fault State conditions are present in the device longer than FSTATE_TIME. Fault State conditions include:
- loss of communications to CAS_IN
- Initiate Fault State status at CAS_IN when the target mode is CAS
- Initiate Fault State status at RCAS_IN when the target mode is RCAS

If the mode is Out Of Service (O/S), the block is not being evaluated. The output of the function block is usually maintained at the last value. If the block is an output function block, then the output may be maintained at the assigned Fault State value or the last value. For the output block, the Fault State might be the last value or a predefined Fault State. Setpoint is maintained at the last value.

If one of the conditions exists longer than FSTATE_TIME, then the block will go to the predefined Fault State. Writing the FAULT_STATE parameter of the resource block may also put this block into the predefined Fault State. The “Fault State to value”
IO_OPTION determines whether the action is simply to hold the current state, or move to FSTATE_VAL. If the IO_OPTION is 0, the value will hold the current (freeze) if a fault is detected. If the IO_OPTION is 1, the output will go to the preset FSTATE_VAL value, if a fault is detected.

The “Target to Manual if IFS” IO_OPTION may be used to latch the Fault State. Setting this IO_OPTION will cause a Fault State block alarm and the target mode to automatically change to manual when a fault is detected. The target mode needs to be manually changed from manual when conditions are corrected.

Control Block
In the backward path, opening the path from the control function block to the actuator can break a loop. There are two responses to the broken loop. The integrator can be limited in one direction, or frozen in place. Lower blocks may provide a back-calculation value and a status that may be used for limiting or locking the output of an integrating controller. Since the status goes from the actuator back to the controller, it is said to go backwards in the loop. In the case of an actuator or control function block in cascade mode, a backward path carries the information about constrained movement back to the function block that is requesting the movement. Also sent backwards is the working setpoint (or process variable) which the requesting function block can use to initialize its output. The quality of this data in the backward path has a state of good (cascade) or bad, never uncertain.

The following condition must be passed from the source of the problem backward along the output path to the first integrating controller on that path:

5. The value is from an output block that has been locally overridden by a local key switch or has Fault State or interlock logic active. The failure of normal control may be propagated to a control block for alarm and display purposes.

Cascade
When configured in a Cascade, the sub-status changes as the cascade is made up when the quality of the cascade parameters is Good(Cascade). The behavior for sub-status of Not Invited can also be applied to Fault State Active or Local Override. The actual mode depends on the target mode and block inputs. When the target is Cascade and the Cascade is Not Invited, the backward path sub-status will be Not Invited. The forward path substatus will be anything but Initialization Acknowledge. The mode of the lower block will be Cascade. The actual mode of the upper block will be IMAN.

Propagation
The manner in which the status of block input parameters is propagated and used in the calculation of the block output status is determined for each function block type. For all blocks, the following three rules apply:
If a block can be used in the forward path of a cascade loop, then it must back propagate limit information using the back-calculation output parameter(s). Examples of blocks that can be used in the forward path are Bias/Gain and Control Selector (see part 2 and 3 for block descriptions). They must also propagate Initiate Fault State to the output block.

Bad - Sub-status indications of sensor failure and device failure are propagated intact through non-control functions. The control function blocks will generate an alert based on the input receiving the failure status. Other bad status indications are propagated as Non-specific. This allows the originating block to show why its value is bad, and following blocks to simply see that the value is Bad, and act accordingly. The control function blocks have an option to propagate Bad on primary input to Initiate Fault State on primary output, and/or to propagate Bad on cascade input to Initiate Fault State on primary output if the target mode is Cas.

A control block will switch to an actual mode that avoids the problem, going to Manual for a bad primary input and Auto for bad cascade input. An option is provided in control blocks to propagate Bad from its primary input or cascade input to the primary output, so that an actuator can take Fault State action. The status of the primary output must not be Bad, so Good (Cascade) - Initiate Fault State is used.

Good (Cascade) Sub-status

There are two Fault State options for sub-status with a Good (Cascade) status.

Fault State Active(FSA) is indicated by sub-status 7. This sub-status is used if the value is from a block that has Fault State active. The failure of normal control must be propagated to a PID block for alarm and display purposes. This also implies Not Invited.

Initiate Fault State(IFS) is indicated by sub-status 8. This sub-status is used if the value is from a block that wants its downstream output block (e.g. AO) to go to Fault State. This is determined by a block option to initiate Fault State if the status of the primary input and/or cascade input goes Bad. See the status options table in Part 2 and 3.

Non-Cascade
If Fault State is active in an output and target is O/S, the actual mode will be O/S; for all other targets, the actual will be Local Override.

Block Error
Bit number 5 (6th bit) of Block Error will be set when Fault State is active. This Block Error will remain active until Fault State is no longer active.

FF Alarms
An FF alarm will be generated based on transition to Active Fault State The alarm will be handled using the standard alarm handling mechanism.

Setpoint in Output Blocks
The calculation of the setpoint parameter in output blocks is different from that in the control blocks. A timer will be triggered on detection of one or more of the following conditions; a communications time-out, cascade input with a status of Good (Cascade) - Initiate Fault State, or power failure recovery. If the condition does not clear within a time defined by the FSTATE_TIME parameter, then the setpoint parameter will be automatically driven to the predefined FSTATE_VAL parameter and, optionally, set the target mode to manual. Through the Fault State type parameter, the action to be taken - hold last value or go to the Fault State parameter value - may be selected.

Physical Fault State
A physical (hardware) device error or interaction can produce a Fault State. The Fault State is the same as those generated from software.

Physical Interface
As part of the device profile, a device may have a pair of screw terminals for an external interlock connection. In such cases, the device will include a physical input to detect if an external circuit is opened. On detection of an open circuit, the associated resource Fault State parameter will be set. This will cause the output block setpoint to be set to the Fault State value parameter. When Fault State action is active, the output block actual mode will be local override and no adjustment of the output will be possible. After re-establishment of communication or closing the circuit, which initiated the action, the operator may once again change output and mode of the block.

Resource State
The Resource State parameter reflects the overall status of the function block application resource. This parameter will exist in the resource block. There are 7 resource states (0-6). If the Resource State is 6, this indicates Failure. The only way to transition to the failure state is by the detection of a memory or other hardware failure that would prevent reliable operation. The failure state may be entered from any state except Standby. The failure may pertain either to the whole device or only to the resource. Based on this state being active, an output function block may change its output to a Fault State position. While in the failure state, the hardware status will be tested. If the hardware failure clears, the resource state will transition to Initialization.

If you are interested in building a test for your device hardware, National Instruments includes some sample test code in the "\nifbus\samples" folder. The file NIFBTEST.c is a single threaded example and can be used as a basis for basic testing.

To compile NIFBTEST.c you will need a C++ compiler. This example used Microsoft Developer Studio, but these directions may be modified for your particular compiler choice.

open a new project
add NIFBTest.c to project
select INSERT->FILES INTO PROJECT
choose nifbtest.c from the appropriate folder
add the includes to project
select TOOLS->OPTIONS->DIRECTORIES
scroll to bottom of list
type in path to “\nifbus\includes” folder
add the nifbus library to the project
select BUILD->SETTINGS->LINK
find the object/library modules box
type in the path to “\nifbus\libs\nifb.lib”
set the working output directory
select BUILD->SETTINGS->GENERAL
enter a folder for the intermediate and output files
build the executable version of nifbtest

The nifbtest executable can be run from a command line, or from the development environment. Modify the file as needed to test particular itmes you are interested in.