BC9050, BC9020, BC9120 - Bus Terminal Controller for Ethernet

BECKHOFF Fieldbus Components

Documentation for

BC9050, BC9020 and BC9120

Bus Terminal Controller for Ethernet

Version: 1.0.0
Date: 2008-05-14

First steps - fast entry


Notes on the documentation

This description is only intended for the use of trained specialists in control and automation engineering who are familiar with the applicable national standards. It is essential that the following notes and explanations are followed when installing and commissioning these components.

Liability Conditions

The responsible staff must ensure that the application or use of the products described satisfy all the requirements for safety, including all the relevant laws, regulations, guidelines and standards.

The documentation has been prepared with care. The products described are, however, constantly under development. For that reason the documentation is not in every case checked for consistency with performance data, standards or other characteristics. None of the statements of this manual represents a guarantee (Garantie) in the meaning of § 443 BGB of the German Civil Code or a statement about the contractually expected fitness for a particular purpose in the meaning of § 434 par. 1 sentence 1 BGB. In the event that it contains technical or editorial errors, we retain the right to make alterations at any time and without warning. No claims for the modification of products that have already been supplied may be made on the basis of the data, diagrams and descriptions in this documentation.

Copyright

© This documentation is copyrighted. Any reproduction or third party use of this publication, whether in whole or in part, without the written permission of Beckhoff Automation GmbH, is forbidden.


Safety Instructions

Safety Rules

The responsible staff must ensure that the application or use of the products described satisfy all the requirements for safety, including all the relevant laws, regulations, guidelines and standards.

State at Delivery

All the components are supplied in particular hardware and software configurations appropriate for the application. Modifications to hardware or software configurations other than those described in the documentation are not permitted, and nullify the liability of Beckhoff Automation GmbH.

Personnel Qualification

This description is only intended for the use of trained specialists in control and automation engineering who are familiar with the applicable national standards.

Description of safety symbols

The following safety symbols are used in this operating manual. They are intended to alert the reader to the associated safety instructions.

Danger This symbol is intended to highlight risks for the life or health of personnel.

Warning This symbol is intended to highlight risks for equipment, materials or the environment.

Note This symbol indicates information that contributes to better understanding.


BC9xx0 - Documentation issue status

BECKHOFF BC9xx0: Foreword

Documentation issue status

Version | Comment
1.0.0 | First version

Firmware BC9050

Firmware | Comment
B0 | First version

Firmware BC9020

Firmware | Comment
B0 | First version

Firmware BC9120

Firmware | Comment
B1 | First version


The Beckhoff Bus Terminal System

Up to 64 Bus Terminals each having 2 I/O channels for each signal form

The Bus Terminal system is the universal interface between a fieldbus system and the sensor / actuator level. A unit consists of a Bus Coupler as the head station, and up to 64 electronic series terminals, the last one being an end terminal. For each technical signal form, terminals are available each having two I/O channels, and these can be mixed in any order. All the terminal types have the same mechanical construction, so that difficulties of planning and design are minimized. The height and depth match the dimensions of compact terminal boxes.

Decentralized wiring of each I/O level

Fieldbus technology allows more compact forms of controller to be used. The I/O level does not have to be brought to the controller. The sensors and actuators can be wired decentrally, using minimum cable lengths. The controller can be installed at any location within the plant.

Industrial PCs as controllers

The use of an Industrial PC as the controller means that the operating and observing element can be implemented in the controller’s hardware. The controller can therefore be located at an operating panel, in a control room, or at some similar place. The Bus Terminals form the decentralized input/output level of the controller in the control cabinet and the subsidiary terminal boxes. The power sector of the plant is also controlled over the bus system in addition to the sensor/actuator level. The Bus Terminal replaces the conventional series terminal as the wiring level in the control cabinet. The control cabinet can have smaller dimensions.

Bus Couplers for all usual bus systems

The Beckhoff Bus Terminal system unites the advantages of a bus system with the possibilities of the compact series terminal. Bus Terminals can be driven within all the usual bus systems, thus reducing the controller parts count. The Bus Terminals then behave like conventional connections for that bus system. All the performance features of the particular bus system are supported.

Assembly on standardized mounting rails

The easy, space-saving, assembly on a standardized mounting rail (EN 50022, 35 mm), and the direct wiring of actuators and sensors, without cross-connections between the terminals, standardizes the installation. The consistent labelling scheme also contributes.

The small physical size and the great flexibility of the Bus Terminal system allows it to be used wherever a series terminal is also used. Every type of connection, such as analog, digital, serial or the direct connection of sensors can be implemented.

Modularity

The modular assembly of the terminal strip with Bus Terminals of various functions limits the number of unused channels to a maximum of one per function. The presence of two channels in one terminal is the optimum compromise of unused channels and the cost of each channel. The possibility of electrical isolation through potential feed terminals also helps to keep the number of unused channels low.

Display of the channel state

The integrated LEDs show the state of the channel at a location close to the sensors and actuators.

K-Bus

The K-Bus is the data path within a terminal strip. The K-Bus is led through from the Bus Coupler through all the terminals via six contacts on the terminals’ side walls. The end terminal terminates the K-Bus. The user does not have to learn anything about the function of the K-Bus or about the internal workings of the terminals and the Bus Coupler. Many software tools that can be supplied make project planning, configuration and operation easy.

Potential feed terminals for isolated groups

The operating voltage is passed on to following terminals via three power contacts. You can divide the terminal strip into arbitrary isolated groups by means of potential feed terminals. The potential feed terminals play no part in the control of the terminals, and can be inserted at any locations within the terminal strip.

Up to 64 terminals can be used within one terminal strip. This count does include potential feed terminals, but not the end terminal.

Bus Couplers for various fieldbus systems

Various Bus Couplers can be used to couple the electronic terminal strip quickly and easily to different fieldbus systems. It is also possible to convert to another fieldbus system at a later time. The Bus Coupler performs all the monitoring and control tasks that are necessary for operation of the connected Bus Terminals. The operation and configuration of the Bus Terminals is carried out exclusively by the Bus Coupler. Nevertheless, the parameters that have been set are stored in each Bus Terminal, and are retained in the event of voltage drop-out. Fieldbus, K-Bus and I/O level are electrically isolated.

If the exchange of data over the fieldbus is prone to errors or fails for a period of time, register contents (such as counter states) are retained, digital outputs are cleared, and analog outputs take a value that can be configured for each output when commissioning. The default setting for analog outputs is 0 V or 0 mA. Digital outputs return in the inactive state. The timeout periods for the Bus Couplers correspond to the usual settings for the fieldbus system. When converting to a different bus system it is necessary to bear in mind the need to change the timeout periods if the bus cycle time is longer.

The interfaces

A Bus Coupler has six different methods of connection. These interfaces are designed as plug connectors and as spring-loaded terminals.


BC9xx0 - Overview

The BC9xx0 series Bus Terminal Controllers have an Ethernet interface and offer a high degree of flexibility. They can also be operated in stand-alone mode.

The BC family Bus Terminal Controllers consist of a programmable IEC 61131-3 controller and the K-Bus interface for the connection of the Beckhoff Bus Terminals and a Ethernet interface.

The Bus Terminals can be connected directly in the usual way. The comprehensive range of different I/Os enables any input signal to be read and any output signal that may be required to be generated. This small controller therefore enables a wide range of automation tasks to be solved, from garage door controllers to autonomous temperature control at injection moulding machines. The BC family is also particularly suitable for a modular machine concept. Within a network, the Bus Terminal Controller can exchange data with other machine components via the fieldbus interfaces.

Note At least one Bus Terminal with process image and one end terminal must be connected to the K-bus of the Bus Terminal Controller.

Fieldbus-interface

The variants of the BC9xx0 series Bus Terminal Controllers have different fieldbus interfaces (with and without switch) and different maximum program size.

  • BC9050: 1 x Ethernet interface, 48 kbyte program memory
  • BC9020: 1 x Ethernet interface, 128 kbyte program memory
  • BC9120: 2 x Ethernet interface, 128 kbyte program memory
  • BX9000: 1 x Ethernet interface, 256 kbyte program memory

Programming

The BC devices are programmed according to the powerful IEC 61131-3 standard. Like for all other Beckhoff controllers, the TwinCAT automation software is the basis for parameterisation and programming. Users therefore have the familiar TwinCAT tools available, e.g. PLC programming interface and System Manager. Data exchange is optionally via the serial port (COM1) or via Ethernet.

Configuration

The configuration is also carried out using TwinCAT. The fieldbus interface can be configured and parameterised via the System Manager. The System Manager can read all connected devices and Bus Terminals. After the parameterisation, the configuration is saved on the BC via the serial interface. The configuration thus created can be accessed again later.

Note BC9050, BC9020, BC9120 are supported from TwinCAT 2.10 build 1322.


BC9050 - Principle of the Bus Terminal

BECKHOFF BC9050: Product overview

Principle of the Bus Terminal

BC9050


BC9020, BC9120 - Principle of the Bus Terminal

BECKHOFF BC9020, BC9120: Product overview

Principle of the Bus Terminal

BC9020, BC9120


BC9xx0 - Technical data - Ethernet

BECKHOFF Bus Terminal Controller: Product overview

Technical data - Ethernet

System data | Ethernet (BC9050, BC9020, BC9120)
Number of I/O modules | depending on controller
Number of I/O points | depending on controller
Data transfer medium | 4 x 2 copper cable (twisted pair); category 5 (100 Mbaud)
Cable length | 100 m between switch and Bus Terminal Controller
Transmission rate | 10/100 Mbaud
Topology | Star wiring (line also possible with BC9120, max. 20 devices per line)
Connections | Ethernet (BC9050, BC9020, BC9120)
Number of ADS connections via TCP/IP | 5
Number of ADS connections via UDP/IP | 1
Number of ModbusTCP connections | 3
SMTP (Simple Mail Transfer Protocol) | yes
SNTP (Simple Network Time Protocol) | yes
BootP/DHCP | yes/yes
UDP socket connections | 3
TCP socket connections | 3
Note The total number of TCP/IP connections should be reduced to a minimum. The smaller the number the more time remains for the actual Controller tasks.
Avoid unnecessary TCP/IP connections. Try using as few TCP/IP connections as possible. If possible use UDP/IP communication instead of TCP/IP, e.g. for ADS.
Use "reasonable" time intervals for communication via the TCP/IP or UDP/IP connection. Example: Controller task time: 20 ms. The minimum client cycle time should be 40 ms.


BC9xx0 - Technical data - Bus Terminal Controller

BECKHOFF Bus Terminal Controller: Product overview

Technical data - Bus Terminal Controller

Technical data | BC9050 | BC9020 | BC9120
Processor | 16 bit micro-controller
Diagnostic LEDs | 2 x power supply, 2 x K-bus, 4 x bus and status LEDs
Configuration and programming software | TwinCAT 2.10 starting with build 1322 or higher
Fieldbus-interface | BC9050 | BC9020 | BC9120
Fieldbus | Ethernet
Interfaces | BC9050 | BC9020 | BC9120
Terminal Bus (K-Bus) | 64 (255 with K-bus extension)
Technical data | BC9050 | BC9020 | BC9120
Digital peripheral signals | 2040 inputs/outputs
Analog peripheral signals | 1024 inputs/outputs
Configuration possibility | via TwinCAT or the controller
max. number of bytes, fieldbus | depending on fieldbus
max. number of bytes, PLC | 2048 bytes of input data, 2048 bytes of output data
Fieldbus connection | RJ45 | RJ45 | 2 x RS45 switch
Power supply (Us) | 24 VDC (-15%/+20%)
Input current (Us) | 65 mA + (total K-Bus current)/4 | 85 mA + (total K-Bus current)/4 | 90 mA + (total K-Bus current)/4
Starting current (Us) | approx. 2.5 x continuous current
K-bus current (5 V) | maximum 1000 mA | maximum 1750 mA | maximum 1750 mA
Power contact voltage (Up) | max. 24 VDC (-15%/+20%)
Power contact current load (Up) | max. 10 A
Dielectric strength | 500 Veff (power contact / supply voltage / fieldbus)
Weight |
Dimensions (W x H x D) |
Operating temperature | 0°C... +55°C
Storage temperature | -25°C... +85°C
Relative humidity | 95 % no condensation
Vibration / shock resistance | conforms to EN 60068-2-6 / EN 60068-2-27, EN 60068-2-29
EMC resistance burst / ESD | conforms to EN 61000-6-2 / EN 61000-6-4
Installation position | any
Protection class | IP20
Mechanical data | BC9050 | BC9020 | BC9120
Mounting | on TS35 with lock
Installation position | any
Connection cross-section | 0.08 mm² .. 2.5 mm² AWG 28-14 8-9 mm strip length


BC9xx0 - Technical data - PLC

BECKHOFF Bus Terminal Controller: Product overview

Technical Data - PLC

PLC data | BC9050 | BC9020 | BC9120
Programmability | via programming interface or fieldbus
Program memory | 48 kbyte | 128 kbyte | 128 kbyte
Source code memory | 128 kbyte | 256 kbyte | 256 kbyte
Data memory | 32 kbyte | 128 kbyte | 128 kbyte
Remanent data | 2 kbyte
Persistent data | 1000 byte
PLC cycle time | approx. 0,85 ms for 1000 IL commands (without I/O cycle)
Programming languages | IEC 6-3 (IL, LD, FBD, ST, SFC)
Run time | 1 PLC task
Online Change | Yes
Up/Down Load Code | Yes/Yes


BC9xx0 - Dimensions

BECKHOFF Bus Terminal Controller: Installation and wiring

Dimensions

The system of the Beckhoff Bus Terminals is characterized by low physical volume and high modularity. When planning a project it must be assumed that at least one Bus Coupler and a number of Bus Terminals will be used. The mechanical dimensions of the Bus Couplers are independent of the fieldbus system.

BC9050
BC9020, BC9120

The total width in practical cases is composed of the width of the Bus Coupler, the width of the bus terminals in use and the KL9010 Bus End Terminal. Depending on function, the Bus Terminals are 12 or 24 mm wide. The front wiring increases the total height of 68 mm by about 5 to 10 mm, depending on the wire thickness.


Installation

The Bus Coupler and all the Bus Terminals can be clipped, with a light press, onto a 35 mm mounting rail. A locking mechanism prevents the individual housings from being pulled off again. For removal from the mounting rail the orange colored tension strap releases the latching mechanism, allowing the housing to be pulled off the rail without any force.

Up to 64 Bus Terminals can be attached to the Bus Coupler on the right hand side. When plugging the components together, be sure to assemble the housings with groove and tongue against each other. A properly working connection can not be made by pushing the housings together on the mounting rail. When correctly assembled, no significant gap can be seen between the attached housings.

Warning Insertion and removal of Bus Terminals is only permitted when switched off. The electronics in the Bus Terminals and in the Bus Coupler are protected to a large measure against damage, but incorrect function and damage cannot be ruled out if they are plugged in under power.

The right hand part of the Bus Coupler can be compared to a Bus Terminal. Eight connections at the top enable the connection with solid or fine wires from 0.08 mm² to 2.5 mm². The connection is implemented with the aid of a spring device. The spring-loaded terminal is opened with a screwdriver or rod, by exerting gentle pressure in the opening above the terminal. The wire can be inserted into the terminal without any force. The terminal closes automatically when the pressure is released, holding the wire securely and permanently.


Potential Groups, Insulation Testing and PE

Potential groups

The Beckhoff Bus Terminals stations usually have three different potential groups:

  • The fieldbus interface is electrically isolated (except for individual Low Cost couplers) and forms the first potential group
  • Bus Coupler / Bus Terminal Controller logic, K-Bus and terminal logic form a second galvanically separated potential group
  • The inputs and outputs are supplied via the power contacts and form further potential groups.

Groups of I/O terminals can be consolidated to further potential groups via potential supply terminals or separation terminals.

Insulation testing

The connection between the Bus Coupler / Bus Terminal Controller and the Bus Terminals is automatically realized by pushing the components together. The transfer of the data and the supply voltage for the intelligent electronics in the Bus Terminals is performed by the K-Bus. The supply of the field electronics is performed through the power contacts. Plugging together the power contacts creates a supply rail. Since some Bus Terminals (e.g. analog Bus Terminals or 4-channel digital Bus Terminals) are not looped through these power contacts (or not completely) the Bus Terminal contact assignments must be considered.

The potential feed terminals interrupt the power contacts, and represent the start of a new supply rail. The Bus Coupler / Bus Terminal Controller can also be made use of to feed the power contacts.

PE power contacts

The power contact labelled PE can be used as a protective earth. For safety reasons this contact mates first when plugging together, and can ground short-circuit currents of up to 125 A.

It should be noted that, for reasons of electromagnetic compatibility, the PE contacts are capacitively coupled to the mounting rail. This can both lead to misleading results and to damaging the terminal during insulation testing (e.g. breakdown of the insulation from a 230 V power consuming device to the PE conductor). The PE conductor to the Bus Coupler / Bus Terminal Controller must be disconnected for the insulation testing. In order to uncouple further feed locations for the purposes of testing, the feed terminals can be pulled at least 10 mm out from the connected group of other terminals. In that case, the PE conductors do not have to be disconnected.

The PE power contact must not be used for other potentials.


BC9050 - Power supply

BECKHOFF Bus Terminal Controller: Installation and wiring

Power supply

BC9050

Bus Terminal Controller supply (Us)

The Bus Terminal Controller requires a supply voltage of 24 VDC.

The connection is made by means of the upper spring-loaded terminals labelled 24 V and 0 V. This supply voltage is used for the electronic components of the Bus Coupler and Bus Terminal Controllers and (via the K-bus) the electronic components of the Bus Terminals. It is galvanically separated from the field level voltage.

Power contacts supply (Up)

The bottom six connections with spring-loaded terminals can be used to feed the supply for the peripherals. The spring-loaded terminals are joined in pairs to a power contact. The feed for the power contacts has no connection to the voltage supply for the BC electronics.

The spring-loaded terminals are designed for wires with cross-sections between 0.08 mm2 and 2.5 mm2.

The assignment in pairs and the electrical connection between feed terminal contacts allows the connection wires to be looped through to various terminal points. The current load from the power contact must not exceed 10 A for long periods. The current carrying capacity between two spring-loaded terminals is identical to that of the connecting wires.

Power contacts

On the right hand face of the Bus Terminal Controller there are three spring contacts for the power contact connections. The spring contacts are hidden in slots so that they can not be accidentally touched. By attaching a Bus Terminal the blade contacts on the left hand side of the Bus Terminal are connected to the spring contacts. The tongue and groove guides on the top and bottom of the Bus Terminal Controllers and of the Bus Terminals guarantees that the power contacts mate securely.


BK9x00/BC9x00 - Ethernet topologies

BECKHOFF Fieldbus Components: Mounting and Wiring

Ethernet topologies

BK9000/BC9000

The BK9000/BC9000 feature a simple Ethernet connection. It can be connected directly to an external switch, so that a typical Ethernet star topology can be created.

BK9100/BC9100

The BK9100/BC9100 feature an internal triple switch with two external ports and one internal port. The internal switch facilitates creation of a line topology. A maximum of 20 BK9100/BC9100s can be connected in series in a physical line. The maximum distance between two BK9100/BC9100s is 100 m. The maximum overall line length is therefore 2 km. No further switches may be included in this line.

Naturally, the BC9100 also enables a classic star topology to be set up.


BX9xx0 - Ethernet connection

BECKHOFF Bus Terminal Controller: Ethernet

Ethernet connection

The connection to the Ethernet bus is made via an RJ45 connector (a Western plug).

BC9000_Connector.jpg (6645 bytes)

Ethernet cabling BC9020 or BC9050

Connection via hub or switch

Connect the PC's network card to the hub/switch using a standard Ethernet cable, and connect the hub/switch, again using a standard Ethernet cable, to the Bus Terminal controller.

Direct connection between PC with Ethernet card and BX9000

Use a crossover Ethernet cable to connect the PC directly with the Bus Terminal Controller.

Ethernet cabling BC9120

Connection via hub or switch

Connect the PC's network card to the hub/switch using a standard Ethernet cable, and connect the hub/switch, again using a standard Ethernet cable, to the Bus Terminal controller.

Direct connection between PC with Ethernet card and BC9120

Any Ethernet cable can be used to connect the PC directly with the Bus Terminal Controller. The internal switch in the BC91x0, BK9100 detects this automatically.

Pin assignment of the RJ45 plug

PIN | Signal | Description
1 | TD + | Transmit +
2 | TD - | Transmit -
3 | RD + | Receive +
4 | - | reserved
5 | - | reserved
6 | RD - | Receive -
7 | - | reserved
8 | - | reserved


Ethernet Cable

Transmission standards

10Base5

The transmission medium for 10Base5 consists of a thick coaxial cable ("yellow cable") with a max. transmission speed of 10 MBaud arranged in a line topology with branches (drops) each of which is connected to one network device. Because all the devices are in this case connected to a common transmission medium, it is inevitable that collisions occur often in 10Base5.

10Base2

10Base2 (Cheapernet) is a further development of 10Base5, and has the advantage that the coaxial cable is cheaper and, being more flexible, is easier to lay. It is possible for several devices to be connected to one 10Base2 cable. It is frequent for branches from a 10Base5 backbone to be implemented in 10Base2.

10BaseT

Describes a twisted pair cable for 10 MBaud. The network here is constructed as a star. It is no longer the case that every device is attached to the same medium. This means that a broken cable no longer results in failure of the entire network. The use of switches as star couplers enables collisions to be reduced. Using full-duplex connections they can even be entirely avoided.

100BaseT

Twisted pair cable for 100 MBaud. It is necessary to use a higher cable quality and to employ appropriate hubs or switches in order to achieve the higher data rate.

10BaseF

The 10BaseF standard describes several optical fiber versions.

Short description of the 10BaseT and 100BaseT cable types

Twisted pair copper cable for star topologies, where the distance between two devices may not exceed 100 meters.

UTP

Unshielded twisted pair
This type of cable belongs to category 3, and is not recommended for use in an industrial environment.

S/UTP

Screened/unshielded twisted pair (screened with copper braid)
Has a general screen of copper braid to reduce influence of external interference. This cable is recommended for use with Bus Couplers.

FTP

Foiled shielded twisted pair (screened with aluminum foil)
This cable has an outer screen of laminated aluminum and plastic foil.

S/FTP

Screened/foiled-shielded twisted pair (screened with copper braid and aluminum foil)
Has a laminated aluminum screen with a copper braid on top. Such cables can provide up to 70 dB reduction in interference power.

STP

Shielded twisted pair
Describes a cable with an outer screen, without defining the nature of the screen any more closely.

S/STP

Screened/shielded twisted pair (wires are individually screened)
This identification refers to a cable with a screen for each of the two wires as well as an outer shield.

ITP

Industrial Twisted-Pair
The structure is similar to that of S/STP, but, in contrast to S/STP, it has only one pair of conductors.


Start-up Behavior of the Bus Terminal Controller

After being switched on, the Bus Terminal Controller checks its state, configures the K-Bus, creates a structure list on the basis of the inserted bus terminals and starts it's local PLC.
The I/O LEDs illuminate and flash as the Bus Coupler starts up. If there are no errors, the I/O LEDs should stop flashing within about 2-3 seconds. In the case of an error, the flash code of the according LED depends on the error type (see Diagnostic LEDs).

At wrong TwinCAT configuration the display will show the error. For the Bus Terminal Controllers of BCxx50,BCxx20 und BXxxxx series the display can be read out also via System Manager.


BC9xx0 - DIP switch

BECKHOFF Bus Terminal Controller: Programming

DIP switch

BC9050 and BC9120/BC9020 feature a DIP switch. This DIP switch has two functions.
1. Setting the IP address or the addressing mode
2. Configuration mode

Mode 1 is activated if Bus Terminals are connected to the K-bus and the Bus Terminal Controller is switched on. Mode 2 is activated if only the end terminal is connected when the Bus Terminals Controller is switched on.

Mode 1 Addressing mode

BC9050 DIP switch

Right switch position on, left switch position off.
DIP switch 1-8 modifies the last byte of the IP address (red DIP switch in the image below). DIP switch 1-2 selects the IP address mode (blue DIP switch in the image below).

DIP 1 | DIP 2 | Meaning
off | off | 172.16.21.xxx (xxx corresponds to DIP switch 1-8), subnet mask 255.255.0.0, default gateway 0.0.0.0
on | off | BootP (DIP 1-8 all off), BootP & Safe (DIP 1-8 all on)
off | on | DHCP
on | on | Configuration via the TwinCAT System Manager

BC9020 and BC9120 DIP switches

Right switch position off, left switch position on.
DIP switch 1-8 modifies the last byte of the IP address (red DIP switch in the image below). DIP switch 9-10 selects the IP address mode (blue DIP switch in the image below).

DIP 9 | DIP 10 | Meaning
off | off | BC9020 172.16.22.xxx (xxx corresponds to DIP switch 1-8), subnet mask 255.255.0.0, default gateway 0.0.0.0 BC9120 172.16.23.xxx (xxx corresponds to DIP switch 1-8), subnet mask 255.255.0.0, default gateway 0.0.0.0
on | off | BootP (DIP 1-8 all off), BootP & Safe (DIP 1-8 all on)
off | on | DHCP
on | on | Configuration via the TwinCAT System Manager

Mode 2 Configuration mode

In the de-energized Bus Terminal Controller only connect the KL9010 end terminal. Set the DIP switch to the required function, then switch on the Bus Terminal Controller. The function is active as soon as the Controller has booted. Continue as usual. In the BC9020 and BC9120 DIP 9 and 10 must be off, in the BC9050 DIP switches 1 and 2 (2-pin DIP switch) must also be off.

Setting |  | Meaning
BC9050 | BC9020 BC9120
99 | 99 | Manufacturer’s settings
98 | 98 | Delete boot project
97 | 97 | Delete TwinCAT Config
99 DIP switches
DIP 1
ON 		DIP 2
ON 		DIP 3
OFF 		DIP 4
OFF 		DIP 5
OFF 		DIP 6
ON 		DIP 7
ON 		DIP 8
OFF
98 DIP switches
DIP 1
OFF 		DIP 2
ON 		DIP 3
OFF 		DIP 4
OFF 		DIP 5
OFF 		DIP 6
ON 		DIP 7
ON 		DIP 8
OFF
97 DIP switches
DIP 1
ON 		DIP 2
OFF 		DIP 3
OFF 		DIP 4
OFF 		DIP 5
OFF 		DIP 6
ON 		DIP 7
ON 		DIP 8
OFF


Bus Terminal Controller - IP address - overview

BECKHOFF Bus Terminal Controller: Parameterization and Commissioning

IP address - overview

The IP address can be set using four different procedures, and these will be described in more detail below.

BX9000: The used addressing method is set by using the navigation switch and the display, or using TwinCAT Config.

Procedure | Explanation | Necessary components
Manual | Addressing via the navigation switch (only BX9000) | none
TwinCAT | Addressing via TwinCAT system manager | PC with network and TwinCAT
BootP* | Addressing via BootP server | BootP server
DHCP* | Addressing via DHCP server | DHCP server
Local IP address* | Locale IP address | if no BootP or DHCP server answers or is available

*) BX9000 from firmware version 1.20


Bus Terminal Controller - Address configuration via TwinCAT System Manager

BECKHOFF Bus Terminal Controller: Parameterization and Commissioning

Address configuration via TwinCAT System Manager

Prerequisites:

  • BX firmware 1.08 or above (see the indication on the BX9000 display after the operating voltage has been switched on).
  • all BC9050, BC9029 and BC9120
  • from TwinCAT 2.10 build 1222

An operable ADS connection is necessary in order to set the IP address through the System Manager. This can be done serially or via Ethernet (see section Searching for the Bus Terminal Controller with the TwinCAT System Manager).

At the BC9x20 the DIP switches 9 and 10 has to be set to ON,
at the BC9050 the switches 1 and 2 of the 2-pole DIP switch has to be set to ON, to enable the IP addressing via System manager.
Then the settings made with the System manager are valid.

You can now read the current settings with Upload. If you have configured the Bus Terminal Controller offline you can establish a connection to the Bus Terminal Controller through the Add Route button. Edit the desired settings, activate the configuration [image], and restart your Bus Terminal Controller through the green TwinCAT icon (or the Ctrl+F4 key combination). If you have entered a new IP address for the Bus Terminal Controller you must enter the new route again (see section Searching for the Bus Terminal Controller with the TwinCAT System Manager).


Bus Terminal Controller - Address configuration via BootP server

BECKHOFF Bus Terminal Controller: Parameterization and Commissioning

Address configuration via BootP server

On the BX9000, the option of allocating the IP address through a BootP server is activated through the Bus Terminal Controller's navigation switch (see the section on the BX-Menu or First Steps).
On the BC9xx0, the option of allocating the IP address through a BootP server is activated through the Bus Terminal Controller's DIP switch

IP address save modes

BootP & Save

If BootP & Save is selected the IP address assigned by the BootP server is stored in the BX. The BootP service is then not requested again at subsequent cold starts.
The address can be cleared again by reactivating the manufacturers' settings (using the KS2000 software or by DIP switch and end terminal).

BootP

The IP address assigned by the BootP server is only valid until the Bus Terminal Controller is switched off. The BootP server must assign a new IP address to the Bus Terminal Controller at the next start.
The address is, however, retained through a software reset of the Bus Terminal Controller.

Beckhoff BootP server

Beckhoff supply a BootP server for Windows 98, ME, NT4.0, NT2000 and XP. You will find the installation version in the Unsupported Utilities folder on the Beckhoff Software Products CD, or on the internet under ftp://ftp.beckhoff.com/.

As soon as the BootP server has started, the New MAC Address window shows all the Beckhoff nodes that are working in BootP mode and still have not received an IP address. The assignment of the MAC-ID to IP address is made with the [<<] button. Successful assignment is displayed in the log window.
To start the BootP server automatically when your PC boots, it is only necessary to provide a shortcut in the Windows autostart folder. Include the /Start parameter in the shortcut (.../TcBootPDlg.exe/start).


Bus Terminal Controller - Address configuration via DHCP server

BECKHOFF Bus Terminal Controller: Parameterization and Commissioning

Address configuration via DHCP server

On the BX9000, the option of allocating the IP address through a DHCP server is activated through the Bus Terminal Controller's navigation switch (see the section on the BX-Menu, or First Steps).
On the BC9xx0, the option of allocating the IP address through a DHCP server is activated through the Bus Terminal Controller's DIP switch.

If DHCP is activated the Bus Terminal Controller is automatically assigned an IP number by the DHCP server. For this purpose the DHCP server must know the Bus Terminal Controller's MAC-ID. The IP address should be set statically.

The DNS name is build out of the type and the last 3 bytes of the MAC-ID. The MAC-ID is printed on the production label of the Bus Terminal Controller.

Example for BX9000
  • MAC ID: 00-01-05-01-02-03
  • DNS name: BX_010203
Example for BC9050
  • MAC ID: 00-01-05-03-02-01
  • DNS name: BC_030201


Auto IP address

Auto IP address is activated if no DHCP or BootP server is found. 1This can take several minutes. The Auto IP address is formed as follows:

In the event of a timeout IP address 169.254.[MAC_05].[MAC06] is generated. If MAC_05 is 0 it is set to 1.

3 ARP probes are then sent. If no response is received a gratuitous ARP is sent and the IP is saved.

If the IP already exists [MAC_05] and [MAC06] [MAC_04] are added up, and another attempt is made.


Subnet mask

The subnet mask is subject to the control of the network administrator, and specifies the structure of the subnet.

Small networks without a router do not require a subnet mask. The same is true if you do not use registered IP numbers. A subnet mask can be used to subdivide the network with the aid of the mask instead of using a large number of network numbers.

The subnet mask is a 32-bit number.

  • Ones in the mask indicate the subnet part of an address region.
  • Zeros indicate that part of the address region which is available for the host IDs.
Description | Binary representation | Decimal representation
IP address | 10101100.00010000.00010001.11001000 | 172.16.17.200
Subnet mask | 11111111.11111111.00010100.00000000 | 255.255.20.0
Network ID | 10101100.00010000.00010000.00000000 | 172.16.16.0
Host ID | 00000000.00000000.00000001.11001000 | 0.0.1.200

Standard subnet mask

Address class | Standard subnet mask (decimal) | Standard subnet mask (hex)
A | 255.0.0.0 | FF.00.00.00
B | 255.255.0.0 | FF.FF.00.00
C | 255.255.255.0 | FF.FF.FF.00

Note Neither subnet 0 nor the subnet consisting only of ones may be used.
Neither host number 0 nor the host number consisting only of ones may be used!

If the IP address is set using the KS2000 configuration software, it is necessary for the subnet mask also to be changed with the KS2000 configuration software.
If ARP addressing is used, the associated standard subnet mask, based on the IP address, is entered.
Under BootP or DHCP the subnet mask is entered by the server.


Overview

Configuration types

At Bus Terminal Controller of BCxx50, BCxx20 and BXxx00 there are two different types of configuration, the DEFAULT CONFIG and the TWINCAT CONFIG.

DEFAULT-CONFIG

Bus Terminals are mapped in the order they are inserted, i.e. first the complex Bus Terminals followed by the digital Bus Terminals.

The complex Bus Terminals are mapped as follows:

  • Word Alignment
  • complex representation
Attention The process image changes if a terminal is added or removed!

The data of the fieldbus slave interface are called PLC variables. The PLC variables have addresses from %QB1000 and %IB1000.

Furthermore the DEFAULT-CONFIG can be used without PLC program, to write or test the connected Bus Terminals. For this at the System Manager the Bus Terminal Controller has to be scanned and the operation mode FreeRun has to be activated (to use this function there must not be any PLC program on the Bus Terminal Controller).

TWINCAT-CONFIG

Bus Terminals and PLC variables can be linked freely in TWINCAT-CONFIG (TC-file required). The configuration is transferred to the coupler via the System Manager and ADS.

The following is required for TwinCAT Config:

  • Via the fieldbus (PROFIBUS, CANopen, Ethernet)
    PROFIBUS: (BC3150, BX3100)
    - PC with FC310x from version 2.0 and TwinCAT 2.9 build 1000
    - BX3100 with firmware from 0.28 with CIF60 or CP5412
    - TwinCAT 2.9 build 946
    (WARNING: only one ADS communication is permitted with the Hilscher PROFIBUS cards, i.e. either System Manager or PLC Control)
    CANopen: (BC5150, BX5100)
    - PC with FC510x from version 1.76 or higher and TwinCAT 2.9 build 1030
    DeviceNet: (BC5250, BX5200)
    - on request
    Ethernet: (BC9050, BC9020, BC9120, BX9000):
    - TwinCAT 2.10 Build xxxx
  • Via serial ADS TwinCAT 2.9 build 1010 for NT4.0, 2000 or XP
    - BX3100 version 1.00
    - BX5100 version 1.00
    - BX5200 version 1.10
    - BX8000 version 1.00
    - BC3150, BC5150, BC5250, BC9050, BC9020, BC9120 from Firmware B0
    - BC8150 TwinCAT 2.10 Build 1244

BCxx50 and BXxx00 can be parameterized via the System Manager of the TwinCAT program.

  • Variable I/O mapping
  • Type-specific PROFIBUS data (only BC3150 or BX3100)
  • RTC (Real Time Clock) (only BX-controller)
  • SSB bus (Smart System Bus) (only BX-controller)
  • PLC settings
  • K-Bus settings

The configuration can be transferred to the BCxx50 or BXxx00 via fieldbus ADS protocol or with the serial ADS protocol.

The TwinCAT configuration can be used to link variables, I/Os and data. The following is possible:

  • PLC - K-BUS
  • PLC - fieldbus (e.g. PROFIBUS slave interface)
  • K-Bus - fieldbus (only the BX-Controller)
  • Support of TwinSAFE terminals (only BX-Controller from Firmware 1.17)

In addition, the TwinCAT configuration can be used to parameterize special behavior, for example whether data are preserved or set to "0" in the event of a fieldbus error.
The real-time clock can be set via a tab in the system manager.

Individual steps
  1. Setting the fieldbus address
  2. Opening the system manager and creating a TC-file
  3. Configuring fieldbus data in the TC-file
  4. Saving the TC-file
  5. Opening a new system manager, creating a PC file and reading in saved TC-file
  6. Creating a link to a PLC task
  7. Saving the configuration
  8. Starting the TwinCAT system
  9. Opening the system manager for the TC-file, completing the configuration and transferring it to the BCxx50, BCxx20 or BXxx00
  10. Transferring the program to the BCxx50, BCxx20 or BXxx00
  11. Creating a boot project


Searching Bus Terminal Controllers with the TwinCAT System Manager

Requirements BX9000:

  • from BX firmware 1.08 (see the indication on the BX9000 display after the operating voltage has been switched on).
  • from TwinCAT 2.10 build 1251

Requirements BC9050, BC9020, BC9120:

  • from Firmware B1
  • from TwinCAT 2.10 Build 1322

An operable ADS connection is necessary in order to set the IP address through the System Manager. This can be done serially or via Ethernet.

A functioning Ethernet connection is necessary for the ADS connection via Ethernet. You can test the IP connection with the PING command. By default, the Bus Terminal Controller is set to 172.16.21.20 with the sub-net mask 255.255.0.0. Set your PC to the same network class, for instance 172.16.21.2 (sub-net mask 255.255.0.0).

Now use PING to test whether a connection exists:

Now start the TwinCAT System Manager, and use the buttons shown on the illustration or press F8 to look for the Bus Terminal Controller:

Now search for the BX9000 via Ethernet:

Now look for your BX9000 using Broadcast Search. If you have more than one Bus Terminal Controller in your network, you can distinguish them through their names.
The name is composed of "BX_" or "BC_" followed by the last three bytes of the MAC-ID. The MAC-ID is printed on the side of the Bus Terminal Controller.
Example: MAC-ID: 00-01-05-00-1D-C3, then the default name is BX_001DC3.

If the Broadcast Search fails to find a device, check the Ethernet connection and the firmware in the controller.

If the Bus Terminal Controller is addressed via DHCP, you can link in the Bus Terminal Controller by clicking the Add Route button in the Host Name dialog.

If the Bus Terminal Controller is addressed manually, or using BootP, you choose the assigned IP address; when a password is requested you simply close the dialog without entering anything. No password is either necessary for or supported by the Bus Terminal Controller.

Now select the BX9000 to which you want to connect, and scan the devices (SSB, K-Bus) connected to it. The BX9000 must be in configuration mode for this purpose (Shift+F4).


Bus Terminal Controller - Creating a TwinCAT configuration

BECKHOFF Fieldbus Components: Parameterization and Commissioning

Creating a TwinCAT configuration

For configuring a Bus Terminal Controller of BCxx50, BCxx20 or BXxx00 series a BX file has to be created in the System Manager. To simplify matters, files for the basic units have already been prepared. Open the respective BX Controller via New from Template.

Select the associated BX Controller.

All BX Controller components are now available.

  • Fieldbus interface
  • K-Bus Interface
  • PLC Program
  • SSB (only BX-Controller)

Please refer to the relevant section for device configuration.


Downloading a TwinCAT configuration

The configuration is transferred to the Bus Terminal Controller via ADS.

Serial ADS protocol

(all Bus Terminal Controller of BCxx50 and BXxx00 series)

Enter the serial ADS connection, as described in section Serial ADS.

ADS protocol via fieldbus

(only BC3150, BC5150, BC9x20, BX3100, BX5100, BX9000)

A prerequisite is that TwinCAT operates as the master and data exchange is active, i.e. physical and fieldbus configuration must be completed, and data must be exchanged from the master (e.g. Fieldbus master card) to the Bus Terminal Controller.

Selecting the target system

Select the Bus Terminal Controller to which you wish to download the configuration. F8 opens the dialog for downloading the associated device.

Select the associated Bus Terminal Controller.

The device state (BX) is displayed at the bottom right of the System Manager.

In Config Mode / FreeRun the configuration can now be transferred to the Bus Terminal Controller. If the Bus Terminal Controller is in Stop Mode, ADS communication has not yet been activated. In this case, the configuration cannot be downloaded.

For activating the configuration select Ctrl+Shift+F4 or Activate Configuration.

The current configuration is uploaded to the Bus Terminal Controller. The display of a BXxx00 will show Store Config, and the BUS and I/O LED will flash. After the configuration has been transferred successfully to the Bus Terminal Controller, a BXxx00 display should show TwinCAT Config. The required program can now be transferred to the Bus Terminal Controller (program download via the fieldbus).


Bus Terminal Controller - Uploading a TwinCAT Configuration

BECKHOFF Bus Terminal Controller: Parameterization and Commissioning

Uploading a TwinCAT Configuration

The TwinCAT configuration is transferred to the Bus Terminal Controller via ADS protocol.

Serial ADS protocol

(all Bus Terminal Controller of BCxx50, BCxx20 and BXxx00 series)

Enter the serial ADS connection, as described in section Serial ADS.

ADS protocol via fieldbus

(only BC3150, BC5150, BC9x20, BC9050, BX3100, BX5100, BX9000)

A prerequisite is that TwinCAT operates as the master and data exchange is active, i.e. physical and PROFIBUS, CANopen configuration must be completed, and data must be exchanged from the master (e.g. Fieldbus card) ) to the Bus Terminal Controller.

Selecting the target system

Select the Bus Terminal Controller to which you wish to upload the configuration. F8 opens the dialog for downloading the associated device.

Select the associated Bus Terminal Controller.

The device state (Bus Terminal Controller) is displayed at the bottom right of the System Manager.

Click on the red folder. The TwinCAT configuration will now be uploaded.


Bus Terminal Controller resources

The system manager indicates the memory resources used by the Bus Terminal Controller in the Resources tab of the Bus Terminal Controller.

Mapping code

The mapping code is required for calculating the TwinCAT configuration (see Fig. 1). The percentages are added up. In the example from Fig 1., 8% of the memory is used for the mapping calculation.

Fig. 1: Memory for code mapping

Data memory mapping

Data memory for mapping. The values are to be considered individually, i.e. each value can be up to 100%.

Fig. 2 Data memory mapping

Used code and data memory

Fig. 3 (1): "Used PLC code" in %.
Fig. 3 (2): "Used PLC data" in % of memory.
Fig. 3 (3): "Used PLC Source" in %.

Fig. 3: Code and data memory

Other memory

Fig.4 (1): "Used Near Heap" is required for the COM interface and SSB. % values.
Fig.4 (2): "Used Huge Heap" is required for ADS communication. % values. This value should be less than 30 %.
Fig.4 (3): "Used file Area" is required for TwinCAT configuration, the TSM file and 16kB flash access. % values.

Fig.4: Other memory


Bus Terminal Controller - ADS Connection via Serial Interface

BECKHOFF Bus Terminal Controller: Parameterization and Commissioning

ADS Connection via Serial Interface

(from firmware version 1.xx or 0.99x - Bus Terminal Controller of BX series and at all BCxx50)

for TwinCAT 2.9 build 1010 (TwinCAT level PLC, NC or NCI)

Note To ensure correct function of the serial ADS connection, only one connection is permitted.
After successful configuration via the System Manager, close the System Manager before starting programming.
Note For BX9000
The default AMS Net Id is 172.16.21.20.1.1. If the IP address of the BX9000 is changed, also the AMS Net Id of the BX9000 changes. You can look for the present AMS Net Id on the display by help of the menu.
Example: You change the IP address to 10.2.3.7, so the AMS Net ID changes to 10.2.3.7.1.1.
Für BC9050, BC9020, BC9120

The default AMS Net Id is 172.16.xxx.[DIP-Switch].1.1. If the IP address of the BC9xxx is changed, also the AMS Net Id of the BC9xxx changes.
Example: You change the IP address to 10.2.3.7 so the AMS Net ID changes to 10.2.3.7.1.1.
BC9050: DEFAULT 172.16.21.[DIP-Switch].1.1
BC9020: DEFAULT 172.16.22.[DIP-Switch].1.1
BC9120: DEFAULT 172.16.23.[DIP-Switch].1.1

Initializing the ADS connection

Enter the Bus Terminal Controller in the remote connection under TwinCAT. Click on the TwinCAT icon and open the feature menu. The following settings can be made under the >AMS Remote< tab.

Remote Name: Any
AMS Net Id: 1.1.1.1.1.1 (Default)
Address: Com Port: baud rate, parity, data bits, stop bits
Transport: "COM port" is to be chosen here

If the Bus Terminal Controller is switched on, it has always the AMS Net Id "1.1.1.1.1.1" by default.
You can change this AMS Net ID to any other. But then the new AMS Net Id can not be changed again.

If you want to change the AMS Net Id again, you first have to restart the Bus Terminal Controller, so that the AMS Net Id is set back to default AMS Net ID "1.1.1.1.1.1".
Now you can change the AMS Net ID once again.

Note No strings can be entered under address when the dialog is first called (see above). Enter name, AMS Net ID, and transport type and close the dialog. When the dialog is called again you can enter your COM port.

Communication starts as soon as TwinCAT is in Config or RUN mode. The COM port is not closed until TwinCAT stops, after which it is available for other programs.

Sollte die COM Schnittstelle bei einem TwinCAT-Neustart von einem anderen Programm (z.B. von der Konfigurations-Software KS2000) verwendet werden, so wird kein Hinweis ausgegeben.
If at a TwinCAT restart the COM port is used by another software (e.g. KS2000 Configuration Software), there will be no error note generated.

Note If the Bus Terminal Controller has been accessed via a fieldbus ADS connection before or during the serial ADS connection was used, the System Manager will automatically have changed the AMS Net ID. A new serial ADS connection will only possible if the ADS Net ID is updated.

BX series: Reading the AMS Net ID

The present AMS Net ID can be read from the menu via the display of the Bus Terminal Controller of the BX series.

AMS
1.1.1.1.1.1 		AMS Net ID


Bus Terminal Controller - TwinCAT PLC as master

BECKHOFF Bus Terminal Controller: Parametrization and Commissioning

TwinCAT PLC as master

A PC or a CX can function as the master for the BC9x20/BC9050/BX9000. It then polls the PLC variables, in accordance with the set task time. This makes it possible both to send data from a supervisory system to the BC9x20/BC9050/BX9000 as well as to receive it. The following communication methods are permitted:

  • ADS TCP cyclic or acyclic from the PLC using the ADS READ and WRITE blocks
  • ADS UDP cyclic
  • RT Ethernet (in preparation)
  • ModbusTCP (using the TC Modbus client)
  • Bus Terminal Controller sends or reads data to or from the PLC with the aid of the ADS READ and WRITE blocks

GetHostByName: This function allows the IP address to be searched for by name (only operates when the Bus Terminal Controller received its IP address via DHCP)

PLC variables: Data for the cyclic data connection. This must be linked into at least one task. 256 words of input or output is the maximum. If it is necessary to transfer more data than this, it can be read or written acyclically through the flags region of the Bus Terminal Controller.

Diagnostic Data:

Coupler State: Should always be zero. "1" is set if, for instance, the K-Bus signals an error.
BoxState: See the comment in the dialogue
MissedCnt: This should, if possible, not increment. Because TwinCAT operates in real time, but neither TCP nor UDP are real-time protocols, is not impossible that the counter will increase under certain circumstances. The counter is incremented every time that data that is been transmitted at the beginning of the task has not yet returned by the time the task starts again.

The task time should be set in the following way

For ADS TCP cyclic

Measure the necessary PLC time on the Bus Terminal Controller, add on another 20-30%, and set this as the task time on the Bus Terminal Controller. Now take three times this task time; the result corresponds to the task time on your master controller. If, for instance, the measured PLC time is 5 ms, then set 7 ms as the task time for the Bus Terminal Controller, and 3 x 7 ms = 21 ms for the master PLC. If there is more than one Bus Terminal Controller, the one with the slowest PLC time is the critical one that determines the task time on the master controller.

For ADS UDP cyclic

Measure the necessary PLC time on the Bus Terminal Controller, add on another 20-30%, and set this as the task time on the Bus Terminal Controller. Now take two times this task time; the result corresponds to the task time on your master controller. If, for instance, the measured PLC time is 5 ms, then set 7 ms as the task time for the Bus Terminal Controller, and 2 x 7 ms = 14 ms for the master PLC. If there is more than one Bus Terminal Controller, the one with the slowest PLC time is the critical one that determines the task time on the master controller.

For ModbusTCP cyclic

Measure the necessary PLC time on the Bus Terminal Controller, add on another 20-30%, and set this as the task time on the Bus Terminal Controller. Now take two times this task time; the result corresponds to the task time on your master controller. If, for instance, the measured PLC time is 5 ms, then set 7 ms as the task time for the Bus Terminal Controller, and 2 x 7 ms = 14 ms for the master PLC. If there is more than one Bus Terminal Controller, the one with the slowest PLC time is the critical one that determines the task time on the master controller.

Different PLC cycle times

If the Bus Terminal Controllers of your application need different cycle times for their local PLC processing, you can adjust the time after the higher level TwinCAT PLC calls for every single Bus Terminal Controllers individually.

Divider

Please use the divider for this. It uses the cycle time of the higher level TwinCAT PLC as a basis for this, for example 10 ms. If the divider is set to 2 every 2 x 10 that means every 20 ms a telegram is sent to the Bus Terminal Controller.

Modulo

With Modulo you can specify additionally, when the higher level TwinCAT PLC should do this.
Example:
Divider 3, Modulo 0, means after the 1. task cycle and then after every 3. task cycle a telegram is sent.
If the Modulo is set to 1 only after after the 2. task cycle a telegram is sent and then after every 3. task cycle + 1.
So at many Ethernet nodes you can spread the amount of Ethernet packets better, have a more homogenous network ratio and no peaks in the net work load.


BX-Controller - K-Bus

BECKHOFF Fieldbus Components: Parameterization and Commissioning

K-Bus

Note For operation of a Bust Terminal Controller from BC or BX series, minimum one Bus Terminal with process image and the End Terminal has to be plugged to its K-Bus!

BX Settings tab

Check Terminals during Start-up

When a boot project is created, the current Bus Terminal configuration is stored. The connected Bus Terminals are checked when the BX is restarted. If this option is selected, the Bus Terminal Controller will not commence data exchange. The PLC project will not be started.

Auto K-Bus Reset

After correction of a K-Bus fault, the Bus Terminal Controller will automatically re-commence data exchange.

Warning Ensure that the outputs are reactivated immediately and that analog outputs retain their programmed value, if this is not dealt with in your PLC project.
Clear Outputs on Breakpoint

If break points are set in PLC Control, the K-Bus is no longer processed, i.e. the outputs are set to a safe state (zero).

K-Bus Sync Mode

Writing and reading of the Bus Terminals can occur synchronous with Task1, Task2 or the fieldbus.

K-Bus Re-Trigger

If the processor is busy dealing with the PLC project or the SSB, the K-Bus cannot be processed for a certain amount of time. This leads to triggering of the Bus Terminal watchdog and dropping of the outputs. The Bus Terminal Controller is set to re-trigger the K-Bus watchdog 3 times after 85 ms respectively. The K-Bus watchdog would then be activated.
K-Bus Re-Trigger 0: 100 ms
K-Bus Re-Trigger 1: 2 x 85 ms = 70 ms
K-Bus Re-Trigger 2: 3 x 85 ms = 255 ms
K-Bus Re-Trigger 3: 4 x 85 ms = 340 ms

Reaction on K-Bus Error

In the event of a K-Bus error, the K-Bus inputs are set to "0" or retain their last state.

Response on PLC-Stop

The user can set the behavior of the fieldbus output data in the event of the PLC project being stopped. The master will use these data as input data. In the event of a PLC stop, the data can be set to "0" or remain unchanged.

BX Diag tab

Display of cycle time for task 1, task 2, K-Bus, fieldbus processing and SSB overhead.

Factory Settings - the Bus Terminal Controller is set back to its delivery state. These settings are reactivated via Restart System or by switching the system off and on again (display shows DEFAULT-CONFIG).

K-Bus variables

PLC-Interface: Not supported (only included for moving CX or BX projects)

K-Bus-State: see Diagnostics


Inserting a PLC project

For variable mapping, configuration has to be specified in the system manager. This is where the link between PLC and hardware is specified. The variables can process and link bit, byte, word or data structures. Automatic addressing via the System Manager is possible, but should be checked for offset.

A valid project has to be compiled and saved in PLC Control. These data are saved as a *.tpy file. For inserting a PLC project, right-click on PLC - Configuration. Select your current PLC project.

Link the PLC variable with the hardware (e.g. digital Bus Terminal).

Once all links have been created, activate the configuration Actions/Activate Configuration (Ctrl+Shift+F4) and start TwinCAT Set/Reset TwinCAT to Run Mode. Ensure that the correct target system is selected (bottom right in the System Manager window).


Measuring the PLC Cycle Time

The task time is set in PLC Control. The default setting is 20 ms.

In the default setting, the PLC program is called every 20 ms, as long as the general cycle time is less than 20 ms. The cycle time can be measured in the System Manager in order to determine your system load. To ensure trouble-free operation, the set task time should be 20 to 30 % higher than the measured cycle time. A precise cycle time breakdown can be found under K-Bus tab description.


KS2000 - Configuration software

BECKHOFF Bus Terminal Controller: Parameterization and commissioning

Configuration software KS2000

The KS2000 configuration software makes parameterisation and configuration of the BC9x20 and BC9050 Bus Terminal Controllers unnecessary. The configuration can be carried out with the TwinCAT System Manager.

The KS2000 configuration software offers configuration and diagnostic support for the Bus Terminals attached to the Bus Terminal Controller.
To this end it is advisable to set the baud rate in the KS2000 configuration software to 38,400 baud (8 data bits, even, 1 stop bit).

Note The COM 1 Controller interface features automatic baud rate detection between 9.6 and 38.4 kBaud.
Note Bus Terminal configuration and diagnostics is supported from KS2000 version 4.3.0.65.

In some Bus Terminals (e.g. KL25xx, KL6811, KL6201, KL6401) the following parameters must be set in order to be able to use the configuration dialogs:

  • A PLC project or boot project must be deactivated.
  • The Controller must be in the default configuration. Set the manufacturer’s setting or switch to Config Mode in the TwinCAT System Manager (blue TwinCAT icon).
  • The Controller must be in FreeRun mode. Activate it with the TwinCAT System Manager.

You can now log in with the KS2000 configuration software via ADS (port 100) or the serial cable and use the KS2000 dialogs in the Bus Terminals.


BC9xx0 - PLC features

BECKHOFF Bus Terminal Controller: Programming

PLC features

BC9050

Description | Value
Data memory | 32 kbyte
Program memory | 48 kbyte minus task-configuration minus POUs during online change
Source code memory | 128 kbyte
RETAIN | 2 kbyte
Persistent data | 1000 byte
INPUT | 2 kbyte
OUTPUT | 2 kbyte
FLAG | 4 kbyte
Max. variable size | 16 kbyte
Max. POUs | Limited by memory

BC9020

Description | Value
Data memory | 128 kbyte
Program memory | 128 kbyte minus task-configuration minus POUs during online change
Source code memory | 128 kbyte
RETAIN | 2 kbyte
Persistent data | 1000 byte
INPUT | 2 kbyte
OUTPUT | 2 kbyte
FLAG | 4 kbyte
Max. variable size | 16 kbyte
Max. POUs | Limited by memory

BC9120

Description | Value
Data memory | 128 kbyte
Program memory | 128 kbyte minus task-configuration minus POUs during online change
Source code memory | 128 kbyte
RETAIN | 2 kbyte
Persistent data | 1000 byte
INPUT | 2 kbyte
OUTPUT | 2 kbyte
FLAG | 4 kbyte
Max. variable size | 16 kbyte
Max. POUs | Limited by memory


Bus Terminal Controller - TwinCAT PLC

BECKHOFF Bus Terminal Controller: Programming

TwinCAT PLC

The Beckhoff TwinCAT Software System turns any compatible PC into a real-time controller with a multi-PLC system, NC axis control, programming environment and operating station. The TwinCAT programming environment is also used for programming the BC/BX. If you have TwinCAT PLC (Windows NT4/2000/XP) installed, you can use the fieldbus connection or the serial port for downloading and debugging software.

TwinCAT I/O or TwinCAT PLC can also be used as the Ethernet Master (host), in order to exchange process data with the Bus Terminal Controller. TwinCAT provides you with the System Manager as a configuration tool, as well as the drivers and the ADS protocol.

Bus Terminal Controller of BCxx50, BCxx20 and BXxx00 series

These 2nd-generation Bus Terminal Controllers are configured with the TwinCAT System Manager and programmed with TwinCAT PLC Control. TwinCAT PLC has to be installed (Windows NT4, Windows 2000, Windows XP) for these couplers.

Programming and program transfer

  • via the serial interface
  • via the fieldbus interface (only at Bus Terminal Controllers for PROFIBUS, CANopen and Ethernet)

Online Change

The Bus Terminal Controller of BX series and BCxx50 supports online change. This means that the PLC program is replaced with a new program without interrupting the program. The switch-over to the new program occurs after the task is completed. This means that two versions of the PLC program have to be stored. 512 kB are available, which therefore have to be divided by 2, leaving 256 kB for the actual program. In addition, several kB are required for task configuration etc. During an online change, dynamic data are stored in memory. Should a program approach the memory limit (program size greater than 240 kB), the online change may no longer work, even though the program may still be written to the BX after "Rebuild all".

When is online change not available?

Online change is not available under certain conditions

  • Inserting of a new library
  • Change in task setting
  • "Rebuild all"
  • Controller memory limit is almost reached (PLC program greater than 90%)


TwinCAT PLC error codes

Error type | Description
PLC compiler error | Maximum number of POUs (...) exceeded
PLC compiler error | Out of global data memory ...

Error POUs

For each block one POU (process object unit) is created. 256 blocks are available by default.

If libraries are integrated this value may be insufficient. In this case, the number of POUs should be increased.

To this end, open

the controller settings in the PLC Control under Projects/Options.

Changing these settings will deactivate online changes.

Global memory error

2 x 16 kB of data are available by default. If large data quantities are to be used, this range should be increased. A maximum of 14 data segments are possible for the BX.


Bus Terminal Controller - Remanent data

BECKHOFF Bus Terminal Controller: Programming

Remanent data

2000 Byte of remanent data are available for the BX controller. These data are declared as VAR RETAIN in PLC Control.

Example

VAR RETAIN
Test :BOOL;
Count :INT;
END_VAR

Retain data are located between VAR RETAIN and END_VAR. These data are stored in a NOVRAM and are consistent across the whole 2 kB range. The RETAIN data are stored in the NOVRAM after each cycle. For 2 kB approx. 2 ms are required (for 1 kB approx. 1 ms). The variables can be configured locally or globally. Variables are located (%I...,%Q.., %M...) are not use as a Retain data.

Note VAR_RETAIN should not be used in function blocks. All FB data are copied into the retain memory. This leads to an unnecessary increase in cycle time, and the retain memory is filled with unnecessary data.
Note Variables, they have an address (%I...,%Q.., %M...), are not allowed to declare as a retain variables.

Example for remanent data in the function block

Because all the data in a function block will be saved if even only one remanent bit is included, this should be avoided if at all possible. A programming example can be found below.

Function block Test (no program code required - in ST a semicolon is sufficient)

FUNCTION_BLOCK Test

VAR_INPUT
END_VAR
VAR_OUTPUT
END_VAR
VAR
END_VAR
VAR_IN_OUT
Counter :INT;
END_VAR

MAIN program

PROGRAM MAIN

VAR
fb_Test:Test;
END_VAR
VAR RETAIN
iCounter1:INT;
END_VAR

fb_Test(Counter:=iCounter1);


Bus Terminal Controller - Persistent data

BECKHOFF Bus Terminal Controller: Programming

Persistent data

1000 Byte of persistent data is available on the Bus Terminal Controller.
In difference to the retain data, the persistent data is not deleted at a new project, a reset of the PLC or a new program download.

To be able to use the persistent data, first you have to activate them with a function block from the PLC.

Furthermore the variables have to be within the allocated flag area, but it doesn't matter where exactly in detail.
4 kByte of allocated flags are available, and you can declare 1 kByte of them as persistent.

Example

VAR
Test AT %MX1000 :BOOL;
Count AT %MB1002 :INT;
END_VAR

With Persitent_Data function block you specify the starting address and the length in byte, where the data should be persistent.

With the WriteOffset input variable you specify the byte offset of the flag area, with WriteSize the length in byte.

You can find the function block in the TcSystemBX library. If it is not there, please load it down from this documentation (see libraries).

Example

WriteOffset 1000
WriteSize 10

Then all data in the area %MB1000 - %MB1009 is persistent. It doesn't matter what type of variable it is.

Like the retain data the persistent data is copied into the NOVRAM, so thy can be written in every cycle.

Note The persistent data is supported by all BX controllers from firmware version 1.17 or higher.
Note Writing the data has to be done only once. This data is stored permanently.
Das re-activating of the manufacturer settings deletes them and the persistent date is also deleted.
Example program

Please click on the following symbol [image] to download an example program from this documentation.


Allocated flags

4 kB of allocated flags are available. They can be used to assign different variable types to the same address, e.g. for converting strings to bytes. Data can also be placed here that can be read or written via ADS by the controller.

Note The BX Controllers do not save the allocated variables as remanent data.

Reading/writing of allocated flags via ADS

The flags may also be read via the controller and ADS. In PROFIBUS, the DPV-1 services are used for this purpose, in CANopen SDO communication is used.
The AmsNetId can be taken from the System Manager, or it can be displayed in the BX menu.
The PLC port number is 800.

Index group | Meaning | Index offset (value range)
0x4020 | Flag (only BXxxx0) | 0..4096
Example

BX program

VAR
Flag_01 AT %MB0: WORD;
END_VAR

TwinCAT PC/CX Master Programm

VAR
fbADRSREAD: ADSREAD;
Flag_M: WORD;
END_VAR

fbADRSREAD(
NETID:='172.16.3.0.2.3' ,  (* AMSNetId BX *)
PORT:=800 ,                (* 800 - PLC *)
IDXGRP:=16#4020 ,          (* 0x4020hex
flags *)
IDXOFFS:=0 ,               (* byte offset *)
LEN:=2 ,                   (* Lenght byte *)
DESTADDR:=ADR(Merker) ,
READ:=TRUE ,
TMOUT:=t#1s  );
IF NOT fbADRSREAD.BUSY THEN
fbADRSREAD(READ:=FALSE);
END_IF


Bus Terminal Controller - Local process image in delivery state

BECKHOFF Bus Terminal Controller: Programming

Default Config: Local process image in delivery state

The process image of the Bus Terminal Controller consists of an input, output and flag area. In addition, there are unallocated data without fixed address. They are created without specifying an address. For this type of variable the

  • the BCxx50 offers 48 kByte of memory,
  • the BCxx20 offers 128 kByte of memory and
  • the BXxx00 offers 256kByte of memory.

The maximum size of a variable or structure (array) is 16 kB. For the allocated data 2048 bytes of input data and 2048 bytes of output data are available. The Busklemmen-Controller has 4 kB of memory for the allocated flag area.

In the delivery state (default configuration) of the Bus Terminal Controller, fixed addresses are allocated for all connected Bus Terminals. The data for Ethernet communication start from address offset 1000dec. The length of the Ethernet data depends on how much data has been configured; on the BX9000 it has a maximum length of 1000 bytes.

Inputs | Outputs
Bus Terminal %IB0 ... | Bus Terminal %QB0 ...
Ethernet DATA (PLC variables) %IB1000 ... (Modbus TCP/ADS-TCP/ADS-UDP) | Ethernet DATA (PLC variables) %QB1000 ... (Modbus TCP/ADS-TCP/ADS-UDP)
... %IB2047 maximum | ... %QB2047 maximum

Addressing of the connected Bus Terminals

The default setting is for all the connected Bus Terminals to be assigned to the local process image. Mapping within the Bus Terminal Controller is carried out according to the following rule:
First all the complex Bus Terminals, in the sequence they are physically inserted, followed by the digital Bus Terminals which are filled to a byte. The default mapping of the complex Bus Terminals is:

  • complete evaluation
  • Intel format
  • Word alignment

Example structure

Bus Terminal Controller: 1 x BCxx50, BCxx20 or BXxx00
Position 1: 1 x KL1012
Position 2: 1 x KL1104
Position 3: 1 x KL2012
Position 4: 1 x KL2034
Position 5: 1 x KL1501
Position 6: 1 x KL3002
Position 7: 1 x KL4002
Position 8: 1 x KL6001
Position 9: 1 x KL9010

Process image
Bus Terminal | Position | Input image | Output image | Size
KL1501 | 5 | %IB0...%IB5 | %QB0...%QB5 | 6 Byte
KL3002 | 6 | %IB6...%IB13 | %QB6...%QB13 | 8 Byte
KL4002 | 7 | %IB14...%IB21 | %QB14...%QB21 | 8 Byte
KL6001 | 8 | %IB22...%IB29 | %QB22...%QB29 | 6 Byte
KL1012 | 1 | %IX30.0...%IX30.1 | - | 2 Bit
KL1104 | 2 | %IX30.1...%IX30.5 | - | 4 Bit
KL2012 | 3 | - | %QX30.0...%IX30.1 | 2 Bit
KL2034 | 4 | - | %QX30.2...%IX30.5 | 4 Bit
KL9010 | 9 | - | - | -


Mapping of the Bus Terminals

The precise assignment of the byte-oriented Bus Terminals may be found in the configuration guide for the particular Bus Terminal. This documentation is available on the Beckhoff CD Products & Solutions or on the Internet under http://www.beckhoff.com.

Byte oriented Bus Terminals | Bit oriented Bus Terminals
KL15x1 | KL10xx, KL11xx, KL12xx, KL17xx, KM1xxx
KL25xx | KL20xx, KL21xx, KL22xx, KL26xx, KL27xx, KM2xxx
KL3xxx |
KL4xxx |
KL5xxx |
KL6xxx |
KL8xxx |
 | KL9110, KL9160, KL9210, KL9260


Local process image in the TwinCAT configuration

The TwinCAT configuration (TwinCAT CONFIG) enables free mapping between PROFIBUS / K-Bus / PLC variables. Variables can be linked independent of their address via the System Manager.

In the TwinCAT configuration, all Bus Terminals have fixed addresses. If a Bus Terminal is inserted, the whole address range may be shifted. Many data are unnecessary and take up valuable address memory space. The TwinCAT configuration rectifies this disadvantage. Allocated variables can be linked freely with a Bus Terminal. Parameterization is carried out in the System Manager, and the configuration is then transferred to the BX (see TwinCAT configuration).


Creating a boot project

Approximately 250 kB of flash are available.

For creating a boot project

  • on the Bus Terminal Controller of BX-Series app. 250 kByte of flash are available
  • on the Bus Terminal Controller of BCxx50-Series app. 48 kByte of flash are available

PLC Control

After logging in, a boot project can be created in TwinCAT PLC Control.

  • Opening a PLC project
  • Selecting the target system (or selection the serial interface)
  • BX/BCxx50 login
  • Creating the boot project (Online\Create boot project)

Once a valid boot project is present on the BX/BCxx50 controller, the green PLC LED is on.

At the Bus Terminal Controller of BX-Series the PLC LED will flash orange during the creation of the boot project. If no boot project is available on the BX the PLC LED shines orange.

Deleting a boot project

A boot project can be deleted from the BX/BCxx50. The following steps must be followed:

  • Opening the project
  • BX/BCxx50 login
  • Deleting the boot project (Online\Delete boot project)

Once the boot project was deleted, the PLC LED will be orange.

Note After an online change, the boot project is still the old project. To use the current project (after the online change) as the boot project, the boot project has to be recreated.

Bypassing the start of the boot project*

At the Bus Terminal Controller of BX-Series the start up of an existing boot project can be avoided by pressing the Navi switch during booting. This will not delete the boot project. The project can still be used when the controller is switched on again.

* from version 0.85


Communication between TwinCAT and Bus Terminal Controller

It makes sense to define a data structure for transferring data between TwinCAT and Bus Terminal Controller. Please note the following to account for the differences in data management on the two systems.

  • If two different data types are sent in sequence (e.g. byte and INT), the following variable is set to the next even address offset
  • Boolean variables should never be allocated individually within a structure, since they would invariably occupy 1 byte. Boolean expressions should always be masked in a byte or word.
Example 1: Structure on the BX and on the PC
Variable | BX memory | PC memory (TwinCAT)
Byte | %..B0 | %..B0
INT (1) | %..B2 | %..B1
INT (2) | %..B4 | %..B3

Because the first byte is followed by a different variable type (INT), it was set to the next free even address in the BX/BCxx50. In order to achieve the same data structure on both systems, a dummy byte has to be inserted in the PC project (see example 2).

Example 2: Structure on the BX and on the PC with identical memory allocation
Variable | BX memory | PC memory (TwinCAT)
Byte | %..B0 | %..B0
Byte (Dummy) | %..B1 (not necessarily required, since the system deals with this itself if the variable does not exist) | %..B1
INT (1) | %..B2 | %..B2
INT (2) | %..B4 | %..B4

Data structure

Type PB_Data
STRUCT
wVar_1:WORD;
iValue_1:INT;
iValue_2:INT;
iValue_3:INT;
END_STRUCT
END_TYPE

Creating a variable structure

VAR_Global
strData_Out AT %QB1000:PB_Data; (*PLC Variables *)
bInput_01 AT %IX0.0:BOOL; (* Input from a terminal *)
END_VAR

Small programming example

strData_Out.wVar_1.0:=bInput_01;

Note A mixed data structure should not contain any Real values. If it does, the High and Low word must be swapped in the BX/BCxx50or in the TwinCAT master project. It is better to use an array of Real values or to transfer the Real values individually.
Note It is also possible to transfer larger fieldbus data blocks, in order to leave a reserve for your structure. Disadvantage: These reserves are then transferred with each fieldbus telegram, causing additional load for the fieldbus communication.


Bus Terminal Controller - Up- and downloading of programs

BECKHOFF Bus Terminal Controller: Programming

Up- and downloading of programs

The Bus Terminal Controller has got a memory for the source code. It can be used for storing the program, the task configuration, and the libraries. Should the memory be insufficient, the source code may be stored without task configuration and libraries. This takes up significant less memory space!

General Settings

Under Project/Options you can set at what time the source code should be downloaded to the target system. Please open the menu Options.

Now choose Source download.

Here you can specify at what time and witch parts of the source code should be downloaded to the Bus Terminal Controller.

Source code only: the prx file with information about online change will be transmitted. With this log on via Online Change is possible (the PLC doesn't stop).
All files: Same as Source code only, plus all necessary libraries.
Source code only (excluded compile info): only the prx file is transmitted. Log on is only possible if the PLC stops.

What kind of option is available depends on the size of your project.

Downloading a program

The source code can be transferred to the target system on request. This requires the user to be logged in with his program. Under Online/Sourcecode download the program code can now be transferred to the Bus Terminal Controller.

After a short delay, a window will open that indicates the download progress.

Uploading a program

For uploading the program code again, open a new file in PLC Control. Then click on the PLC button.

Select the data transfer route. For the Bus Terminal Controller
- BCxx50 or BX via AMS, if they are connected via the fieldbus with the BX, or
- BCxx50 or BX via serial, if they are connected via the serial interface.

Then select the device and confirm with OK.

The source code will now be uploaded.

Password

You can protect your project with a password (in PLC Control Project/Options/Passwords).


BC9xx0 - Libraries overview

BECKHOFF Bus Terminal Controller: Programming

Libraries overview

The TwinCAT Automation Software offers various libraries for the BC9xx0 series Bus Terminal Controllers (Bus Coupler with PLC functionality) (see Beckhoff information system).

Download

The libraries are also included in this documentation. For extracting the libraries, click on the disk icon with the left mouse button and copy the libraries into the directory TwinCAT\PLC\LIB.

  • Standard
  • TcSystemBCxx50 [image] TcSystemBCxx50 requires the TcBaseBCxx50 library.
  • TcBaseBCxx50
  • ChrAscBX.lbx
Note Always use the latest libraries in conjunction with the latest BC firmware. If you update the firmware of your Bus Terminal Controller, please also update the libraries. Copy the new libraries into the LIB folder, remove them from your project and re-insert them.

TcSystemBCxx50

ADS | Version | Firmware
 |  | BC9050 | BC9020 | BC9120 | - | -
ADSREAD |  | B0 | B0 | B1 | - | -
ADSWRITE |  | B0 | B0 | B1 | - | -
ADSRDWRT |  | B0 | B0 | B1 | - | -
ADSWRTCTL |  | B0 | B0 | B1 | - | -
ADSRDSTATE |  | B0 | B0 | B1 | - | -
ADSRDDEVINFO |  | B0 | B0 | B1 | - | -
Bit Functions | Version | Firmware
 |  | BC9050 | BC9020 | BC9120 | - | -
CLEARBIT32 |  | B0 | B0 | B1 | - | -
CSETBIT32 |  | B0 | B0 | B1 | - | -
GETBIT32 |  | B0 | B0 | B1 | - | -
SETBIT32 |  | B0 | B0 | B1 | - | -
Controller | Version | Firmware
 |  | BC9050 | BC9020 | BC9120 | - | -
FB_BasicPID | - | B0 | B0 | B1 | - | -
- | - | - | - | - | - | -
File Access | Version | Firmware
 |  | BC9050 | BC9020 | BC9120 | - | -
FB_ReadFromFile |  | - | - | - | - | -
FB_WriteToFile |  | - | - | - | - | -
FB_ReadWriteFile |  | - | - | - | - | -
Memory Functions | Version | Firmware
 |  | BC9050 | BC9020 | BC9120 | - | -
MEMCMP |  | B0 | B0 | B1 | - | -
MEMCYP |  | B0 | B0 | B1 | - | -
MEMMOVE |  | B0 | B0 | B1 | - | -
MEMSET |  | B0 | B0 | B1 | - | -
NOVRAM Functions | Version | Firmware
 |  | BC9050 | BC9020 | BC9120 | - | -
- | - | - | - | - | - | -
SFC | Version | Firmware
 |  | BC9050 | BC9020 | BC9120 | - | -
AnalyzeExpression |  | - | - | - | - | -
AppendErrorString |  | - | - | - | - | -
SFCActionControl |  | - | - | - | - | -
System / Time / TBus | Version | Firmware
 |  | BC9050 | BC9020 | BC9120 | - | -
DRAND |  | B0 | B0 | B1 | - | -
SYSTEMTIME_TO_DT |  | B0 | B0 | B1 | - | -
DT_TO_SYSTEMTIME |  | B0 | B0 | B1 | - | -
GetSysTick |  | B0 | B0 | B1 | - | -
PresetSysTick |  | B0 | B0 | B1 | - | -
Reboot |  | B0 | B0 | B1 | - | -
Debug | Version | Firmware
 |  | BC9050 | BC9020 | BC9120 | - | -
F_ReadDebugTimer |  | B0 | B0 | B1 | - | -
F_StartDebugTimer |  | B0 | B0 | B1 | - | -


Libraries for BX9000, BC9050, BC9120, BC9020 - Overview

Special Function Blocks for the BX9000, BC9020, BC9050 and BC9120 Bus Terminal Controller.

Download

For downloading libraries please left-click on the disk icon. Please copy the libraries to folder TwinCAT\PLC\LIB.

  • TcBaseBX9000
Note The latest firmware requires the latest library. If you update your BX Controller, please also change the libraries.
Copy copy the libraries to folder TwinCAT\PLC\LIB. Then remove these libraries from your project and reinsert them again.

TcBaseBX9000

Services | Version | Firmware
 |  | BX9000 | BC9020 | BC9050 | BC9120
FB_AddDnsServer | 30.05.06 | 1.12 | B0 | B0 | B1
FB_GetHostByAddr | 30.05.06 | 1.12 | B0 | B0 | B1
FB_GetHostByName | 30.05.06 | 1.12 | B0 | B0 | B1
FB_GetNetworkConfig | 30.05.06 | 1.12 | B0 | B0 | B1
FB_SetTargetName | 30.05.06 | 1.12 | B0 | B0 | B1
SMTP | Version | Firmware
 |  | BX9000 | BC9020 | BC9050 | BC9120
FB_SMTP | 30.05.06 | 1.12 | B0 | B0 | B1
SNTP | Version | Firmware
 |  | BX9000 | BC9020 | BC9050 | BC9120
FB_SNTP | 30.05.06 | 1.12 | B0 | B0 | B1
IP-TCP/IP-UDP | Version | Firmware
 |  | BX9000 | BC9020 | BC9050 | BC9120
FB_AddMultiRoute | 26.09.06 | 1.14 | B0 | B0 | B1
FB_DelMultiRoute | 26.09.06 | 1.14 | B0 | B0 | B1
FB_IpClose | 26.09.06 | 1.14 | B0 | B0 | B1
FB_IpEndSession | 26.09.06 | 1.14 | B0 | B0 | B1
FB_IpOpen | 26.09.06 | 1.14 | B0 | B0 | B1
FB_IpReceive | 26.09.06 | 1.14 | B0 | B0 | B1
FB_IpSend | 26.09.06 | 1.14 | B0 | B0 | B1
FB_IpStartSession | 26.09.06 | 1.14 | B0 | B0 | B1
ModbusTCP | Version | Firmware
 |  | BX9000 | BC9020 | BC9050 | BC9120
FB_MBClose | 26.09.06 | 1.14 | B0 | B0 | B1
FB_MBConnect | 26.09.06 | 1.14 | B0 | B0 | B1
FB_MBGenericReq | 26.09.06 | 1.14 | B0 | B0 | B1


Libraries - System Task Info

BECKHOFF Bus Terminal Controller: Programming

System Task Info

VAR_GLOBAL
    SystemTaskInfo 	:  SYSTEMTASKINFOTYPE;
END_VAR

System flags are implicitly declared variables. Using the Input Assistant, a variable SystemTaskInfoArr can be found under system variables. This variable is a field with four structures of type SYTEMTASKINFOTYPE. The structure definition can be found in the system library. The index in this field is the task ID.

Development environment | Target system type | PLC libraries to be linked
TwinCAT v2.9.0 | BCxx50 Controller | TcBaseBCxx50.lbx


Libraries - System Task Info Type

BECKHOFF Bus Terminal Controller: Programming

System task info type

TYPE SYSTEMTASKINFOTYPE
STRUCT
    active			:	BOOL;
    taskName			:	STRING(16);
    firstCycle		:	BOOL;
    cycleTimeExceeded		:	BOOL;
    cycleTime			:	UDINT;
    lastExecTime		:	UDINT;
    priority			:	BYTE;
    cycleCount		: 	UDINT;
END_STRUCT
END_TYPE
Key

active: This variable indicates whether the task is active.
taskName: the task name.
firstCycle: during the first PLC task cycle, this variable has the value TRUE.
cycleTimeExceeded: this variable indicates whether the set task cycle time was exceeded.
cycleTime : set task cycle time in multiples of 100 ns.
lastExecTime: cycle time required for the last cycle in multiples of 100 ns.
priority: set task priority.
cycleCount: cycle counter.

Development environment | Target system type | PLC libraries to be linked
TwinCAT v2.9.0 | BCxx50 Controller | TcBaseBCxx50.lbx


Libraries - System Info

BECKHOFF Bus Terminal Controller: Programming

System Info

VAR_GLOBAL
    SystemInfo     : SYSTEMINFOTYPE;
END_VAR

System flags are implicitly declared variables. Using the Input Assistant, a variable System Info can be found under system variables. The type SYSTEMINFOTYPE is declared in the system library. For accessing the variable, the system library has to be integrated in the project.

Development environment | Target system type | PLC libraries to be linked
TwinCAT v2.9.0 | BCxx50 Controller | TcBaseBCxx50.lbx


Libraries - System Info Type

BECKHOFF Bus Terminal Controller: Programming

System Info Type

TYPE SYSTEMINFOTYPE
STRUCT
    runTimeNo		:	BYTE;
    projectName		:	STRING(32);
    numberOfTasks		:	BYTE;
    onlineChangeCount		:	UINT;
    bootDataFlags		:	BYTE;
    systemStateFlags		:	WORD;
END_STRUCT
END_TYPE
Key

runTimeNo: specifies the number of the runtime system (1).
projectName: project name as STRING.
numberOfTasks: number of tasks contained in the runtime system (max. 1).
onlineChangeCount: number of online changes since the last complete download.
bootDataFlags: Reserved
systemStateFlags: Reserved

Development environment | Target system type | PLC libraries to be linked
TwinCAT v2.9.0 | BCxx50 Controller | TcBaseBCxx50.lbx


BX Controller - Local ADS port numbers - Overview

BECKHOFF BX Controller: Programming

Local ADS port numbers - Overview

Port number | Description
100 dec | Reading and writing of registers and tables from the coupler and the complex Bus Terminals
150 dec | Reading and writing of RTC (real-time clock)
153 dec | SSB - reading of the emergency message
800 dec | Local PLC process image, see Port 801
801 dec | Local PLC process image, see Port 800
0x1000 + Node ID | SSB - SDO communication with CANopen node (slave number)


ADS services

Local Process Image PLC Task 1 Port 800/801

Data can be read from and written to the local process image. If it is necessary for outputs to be written, it is important to ensure that they are not used by the local PLC, because the local controller will overwrite these values. The data are not associated with a watchdog, and therefore must not be used for outputs that would have to be switched off in the event of a fault.

Index group | Meaning | Index offset (value range)
0xF020 | Inputs | 0...2047
0xF021 | Bit inputs | 0...16376
0xF030 | Outputs | 0...2047
0xF031 | Bit outputs | 0...16376
0x4020 | Flags | 0...4095
0x4021 | Flag bit | 0...32760

ADS services

AdsServerAdsState
Data type (read only) | Meaning
String | Start - the local PLC is running Stop - the local PLC is stopped
AdsServerDeviceState
Data type (read only) | Meaning
INT | 0 – Start - the local PLC is running 1 – Stop - the local PLC is stopped
AdsServerType
Data type (read only) | Meaning
String | BX PLC Server
ADSWriteControl
Data type (write only) | Meaning
NetID | Net ID of the BX9000
Port | 800
ADSSTATE | 5 - RUN / 6 - STOP
DEVSTATE | 0
LEN | 0
SRCADDR | 0
WRITE | rising edge starts the block
TMOUT | for example: t#1000ms

Register Access Port 100

On the Bus Terminal Controllers of the BX series, and on the BCxx50, the ADS port number for register communication is fixed at 100.

Index group | Index offset (value range) |  | Meaning
 | Hi-Word | Low Word
0 [READ ONLY] | 0...127 | 0...255 | Registers in the Bus Coupler High word, table number of the Bus Coupler Low word, register number of the table
1...255 | 0...3 | 1...255 | Register of the Bus Terminal High word, channel number Low word, register number of the Bus Terminal
Note When reading the register, the time out for the ADS block has to be set to a time longer than 1 second.
Note When writing to the registers, the password has to be set (see the documentation for the particular Bus Terminal).


BX Debug Function - Overview

These functions can be used for measuring command execution times in a PLC project. The unit is a tick. One tick corresponds to 5.12 µs.

Start Debug Timer function

Calling this function starts the timer. The return value is "0".

Read Debug Timer function

This function reads the timer value. The return value has to be multiplied with 5.12 µs.

Example

VAR
Timer_BX :WORD;
i :INT;
END_VAR

Program

F_STARTDEBUGTIMER();
For i:=0 to 1000 do
;
END_FOR
Timer_BX:=F_READDEBUGTIMER();


Overview: Socket Interface

The socket interface can be used for receiving any Ethernet telegrams or for sending telegrams from the controller. In this way any PLC layer protocols can be programmed in IEC 61131-3.

Supported Ethernet protocols

Type | STREAM | DGRAM | RAW
IP | n.i. | n.i. | n.i.
ICMP | n.i. | n.i. | n.i.
IGMP | n.i. | n.i. | n.i.
TCP | from V1.14 | n.i. | n.i.
UDP | n.i. | from 1.14 | n.i.
RAW | n.i. | n.i. | n.i.

Table 1
n.i. not implemented

Operating principle of a socket-connection

Before a socket can be opened resources for this type of connection must be made available to the controller. This is done by starting a session for specifying the scope. The session can then be used for sending or receiving Ethernet telegrams. The implemented protocols are listed in Table 1.

Client-server relationship

A client is defined as a device that intends to establish a connection and initializes the active part of a connection setup. The server is initially passive and awaits a client query. The server becomes active once a client establishes a connection. Once a connection between client and server has been established, both devices can sending or receive data.

Development environment | Target system type | PLC libraries to be linked
TwinCAT v2.10.0 and above | BX9000 (165) firmware version >=1.14 | TcBaseBX9000.lbx


IP block overview

IP-TCP/IP-UDP | Firmware | Description
FB_IpStartSession | 1.14 | Opening a session
FB_IpEndSession | 1.14 | Closing a session
FB_IpOpen | 1.14 | Opening a TCP/IP connection (not required for UDP communication)
FB_IpClose | 1.14 | Closing a TCP/IP connection (not required for UDP communication)
FB_IpReceive | 1.14 | Receiving TCP or UDP telegrams
FB_IpSend | 1.14 | Sending TCP or UDP telegrams
Multicast blocks | Firmware | Description
FB_AddMultiRoute | 1.14 | Creating a muticast address
FB_DelMultiRoute | 1.14 | Deleting a muticast address


FB_IpStartSession

The block allocates resources on the controller for the Ethernet communication. The block becomes active with bStart. As long as the block is busy bBusy is set. iDevice should always be zero. iPort is used for the local TCP or UDP port number. iMaxConnection indicates the maximum number of connections. The maximum value is 3.

INPUT

VAR_INPUT
   bStart		: BOOL;
   iDevice    	: WORD;
   eSocketType	: E_SocketType;
   eSocketProtocol	: E_SocketProtocol;
   iPort		: WORD;
   iMayConnection	: WORD;
   tTimeout	: TIME;
END_VAR

bStart: A rising edge activates the block.

iDevice: always "0"

eSocketType: For TCP/IP "SOCK_STREAM" should be used. Please note that the data are stored as a byte stream. The length of the data to be received should be known or a protocol with a start/end ID should be used so that the start and end can be identified from the data stream. For UDP/IP "SOCK_DGRAM" should be set. A UDP frame always stored in the memory as a complete entity. 4 memories are available. If the data are not read fast enough from the memory of the PLC by the user program further UDP frames are lost.

eSocketProtocol: For TCP/IP "IPPROTO_TCP" should be used, for UDP/IP "IPPROTO_UDP".

iPort: Sender port number

iMaxConnection: Number of possible connections (max. 3)

tTimeout: Time after which the attempt is aborted.

OUTPUT

VAR_OUTPUT
   bBusy         	: BOOL;
   bError        	: BOOL;
   iErrorId	: WORD;
   iSession	: WORD;
END_VAR

bBusy: This output remains TRUE until execution of the command is complete.

bError: This output is switched to TRUE if an error occurs during the execution of a command. The command-specific error code is contained in iErrorId.

iErrorId: Contains the command-specific error code of the most recently executed command (see table).

iSession: Forwards the session number to all IP blocks for which this connection was created.


FB_IpEndSession

The block closes an open session. A positive edge of bStart closes the session and releases resources.

INPUT

VAR_INPUT
   bStart		: BOOL;
   iSession    	: WORD;
END_VAR

bStart: A rising edge activates the block.

iSession: Is linked with the session number from block FB_IpStartSession.

OUTPUT

VAR_OUTPUT
   bBusy         	: BOOL;
   bError        	: BOOL;
   iErrorId	: WORD;
END_VAR

bBusy: This output remains TRUE until execution of the command is complete.

bError: This output is switched to TRUE if an error occurs during the execution of a command. The command-specific error code is contained in iErrorId.

iErrorId: Contains the command-specific error code of the most recently executed command (see table).


FB_IpOpen

The block is required for opening a TCP/IP connection from the PLC controller. In this case is the controller is the client that actively establishes a connection to a TCP/IP server. With a positive edge of bStart a connection to a server with the IP address from sRemoteIpAddr is established. The recipient port number was specified when the session was started (see FB_IpStartSession). The sender port number is issued by the controller and can be read from iPortNo. The sender port number is required for sending (see FB_IpSend). bBusy is set as long set as the block is active. If bBusy is reset and bError is FALSE the TCP/IP connection was terminated successfully and data can be sent or received.

INPUT

VAR_INPUT
   bStart		: BOOL;
   iSession    	: WORD;
   sRemoteIPAddr	: STRING(15);
END_VAR

bStart: A rising edge activates the block.

iSession: Is linked with the session number from block FB_IpStartSession.

OUTPUT

VAR_OUTPUT
   bBusy         	: BOOL;
   bError        	: BOOL;
   iErrorId	: WORD;
   iPortNo	: WORD;
END_VAR

bBusy: This output remains TRUE until execution of the command is complete.

bError: This output is switched to TRUE if an error occurs during the execution of a command. The command-specific error code is contained in iErrorId.

iErrorId: Contains the command-specific error code of the most recently executed command (see table).

iPortNo: TCP port number that was allocated when the TCP/IP connection was opened (local port number).


FB_IpClose

The block is required for closing a TCP/IP connection from the PLC controller. With a positive edge of bStart a connection with the IP address from sRemoteIpAddr is terminated. The block sends a FIN signal and waits for the confirmation of the disconnection. The partner device and the connection must exist and be operational. If bResetConnection is set the block sends a signal to indicate that the connection was terminated but does not wait for confirmation from the other device. bBusy is set as long as the block is active. If bBusy is reset and bError is FALSE the TCP/IP connection was terminated successfully.

INPUT

VAR_INPUT
   bStart			: BOOL;
   iSession    		: WORD;
   sRemoteIPAddr		: STRING(15);
   iPortNo		: WORD;
   bResetConnection	: BOOL;
END_VAR

bStart: A rising edge activates the block.

iSession: Is linked with the session number from block FB_IpStartSession.

sRemoteIPAddr: IP address of the device with which the connection is to be terminated.

iPortNo: Port number of the device with which the connection is to be terminated.

bResetConnection: FALSE: FIN is sent; TRUE: the TCP/IP connection is closed without waiting for acknowledgement from the partner device. In both cases a new Open is required for re-establishing the connection.

OUTPUT

VAR_OUTPUT
   bBusy         	: BOOL;
   bError        	: BOOL;
   iErrorId	: WORD;
END_VAR

bBusy: This output remains TRUE until execution of the command is complete.

bError: This output is switched to TRUE if an error occurs during the execution of a command. The command-specific error code is contained in iErrorId.

iErrorId: Contains the command-specific error code of the most recently executed command (see table).


FB_IpReceive

The block FB_IpReceice enables receiving of UDP or TCP telegrams. Which of the connections is used is specified in FB_IpStartSession. Received data must be stored in a PLC variable.

To this end a pointer to pBuffAddr is required, and the size of the variable has to be entered in cbBuffLen. A positive edge of bValid indicates that the memory contains data or the data of the associated variable are now valid. A positive edge of bClear indicates that the block is ready to receive data again or, if data are still in the buffer they are copied to the variable next.

With TCP in particular you should monitor how many data were received or are still in the buffer. With TCP/IP data are stored as a "stream", i.e. there is no start or end. With UDP, on the other hand, the content of a UDP frame is always stored in its own buffer.

Up to 4 UDP telegrams can be buffered, further UDP telegrams are lost. cbReceive indicates the number of data in bytes copied into the variable. If the buffer contains more data than were read, the number of remaining data is in cbBytesInStream.

sReceiveIPAddr indicates the IP address of the device that has sent data to the Beckhoff controller and the associated port number iReceivePortNo. Both variables are cleared with bClear. sReceiveIPAddr and iReceivePortNo can be used for sending data back to the device via block FB_IpSend.

INPUT

VAR_INPUT
   bClear		: BOOL;
   iSession    	: WORD;
   sRemoteIPAddr	: STRING(15);
   iPortNo	: WORD;
   pBuffAddr	: DWORD;
   cbBuffLen	: WORD;
END_VAR

bClear: A rising edge clears the memory. The block is then ready to receive data again.

iSession: Is linked with iSession from block FB_StartSession.

sRemoteIPAddr: Can be used as filter for approving only a specific IP address.

iPortNo: Can be used as filter for approving only a specific port.

pBuffAddr: With ADR the pointer to the variable is transferred where the data that were received are to be copied.

cbBuffLen: Size of the variable, can be determined with SIZEOF.

OUTPUT

VAR_OUTPUT
   bValid         	: BOOL;
   bError        	: BOOL;
   iErrorId	: WORD;
   cbReceive	: WORD;
   cbBytesInStream	: WORD;
   sReceiveIPAddr	: STRING(15)
   iReceivePortNo	: WORD;
END_VAR

bValid: A positive edge change indicates that new data were received, which are contained in the variable that is linked via the pointer pBuffAddr.

bError: This output is switched to TRUE if an error occurs during the execution of a command. The command-specific error code is contained in iErrorId.

iErrorId: Contains the command-specific error code of the most recently executed command (see table).

cbReceive: Indicates the number bytes that were copied.

cbBytesInStream: Indicates the data remaining in the memory. This should always be zero. If the value is >0 the variable linked to pBuffAddr is too small. A further read operation is required for obtaining the remaining data.

sReceiveIPAddr: Indicates the IP address of the device that has sent the data. Cleared with positive edge of bClear.

iReceivePortNo: Indicates the port number of the device that has sent the data. Cleared with positive edge of bClear.


FB_IpSend

The block sends data via TCP or UDP. Which of the connections is used is specified in FB_IpStartSession. In pBuffAddr the pointer to the variable containing data for sending is specified via "ADR". cbBuffLen indicates the length of the data. sRemoteIPAddr indicates the IP address to which the data are sent. With iPortNo this is linked with the port number of FB_IpOpen in TCP. With UDP any port number can be used. iPortNo is the sender port number. The block is activated and the data are sent with a rising edge of bStart. bBusy is TRUE as long the block is active. Once the data have been sent bBusy switches to FALSE. bError also remains FALSE. If an error occurs bError is set.

INPUT

VAR_INPUT
   bStart			: BOOL;
   iSession    		: WORD;
   sRemoteIPAddr		: STRING(15);
   pBuffAddr		: DWORD;
   cbBuffLen		: WORD;
END_VAR

bStart: A rising edge activates the block.

iSession: Is linked with the session number from block FB_IpStartSession.

sRemoteIPAddr: IP port number of the device to which data are to be sent.

iPortNo: Sender port number. For TCP the port number from the FB_IpOpen block must be used, for UDP any port number can be used.

pBuffAddr: Pointer to the data to be sent (command: ADR).

cbBuffLen: Length of the data to be sent. The length should always be less or equal the variable to which the pointer of pBuffAddr points (command: SIZEOF)

OUTPUT

VAR_OUTPUT
   bBusy         	: BOOL;
   bError        	: BOOL;
   iErrorId	: WORD;
END_VAR

bBusy: This output remains TRUE until execution of the command is complete.

bError: This output is switched to TRUE if an error occurs during the execution of a command. The command-specific error code is contained in iErrorId.

iErrorId: Contains the command-specific error code of the most recently executed command (see table).


TCP/IP Client

TCP/IP is a connection-oriented communication type (peer-to-peer connection). In this example we illustrate how a connection is established between the Beckhoff controller and a server. The required blocks are FB_IpStartSession, FB_IpOpen, FB_IpSend and optionally FB_IpReceive, FB_IpClose and FB_IpEndSession.

It is advisable to program a step sequence as illustrated in the example below.

In this case the Beckhoff controller is the client and the partner device a TCP server. The server is a VB6 program.

Step 1

FB_IpStartSession

The block allocates resources on the controller for the TCP/IP communication. The block becomes active with bStart. As long as the block is busy bBusy is set. iDevice should always be zero. iPort is used for the local TCP/IP port number. iMaxConnection indicates the maximum number of connections. The maximum value is 3.

INPUT

bStart: A rising edge activates the block.

iDevice: always "0"

eSocketType: For TCP/IP "SOCK_STREAM" should be used. Please note that the data are stored as a byte stream. The length of the data to be received should be known or a protocol with a start/end ID should be used so that the start and end can be identified from the data stream.

eSocketProtocol: For TCP/IP "IPPROTO_TCP" should be used

iPort: Sender port number

iMaxConnection: Number of possible connections (max. 3)

tTimeout: Time after which the attempt is aborted.

OUTPUT

bBusy: This output remains TRUE until execution of the command is complete.

bError: This output is switched to TRUE if an error occurs during the execution of a command. The command-specific error code is contained in iErrorId.

iErrorId: Contains the command-specific error code of the most recently executed command (see table).

iSession: Forwards the session number to all IP blocks for which this connection was created.

Step 2

FB_IpOpen

Received data must be stored in a PLC variable. To this end a pointer to pBuffAddr is required, and the size of the variable is specified in cbBuffLen. A positive edge of bValid indicates that the memory contains data or the data of the associated variable are now valid.

INPUT

bClear: A rising edge clears the memory. The block is then ready to receive data again.

iSession: Is linked with iSession from block FB_StartSession.

sRemoteIPAddr: Can be used as filter for approving only a specific IP address.

eSocketProtocol: For TCP/IP "IPPROTO_TCP" should be used

iPort: Local port number

iMaxConnection: Number of possible connections (max. 3)

tTimeout: Time after which the attempt is aborted.

OUTPUT

bBusy: This output remains TRUE until execution of the command is complete.

bError: This output is switched to TRUE if an error occurs during the execution of a command. The command-specific error code is contained in iErrorId.

iErrorId: Contains the command-specific error code of the most recently executed command (see table).

iSession: Forwards the session number to all IP blocks for which this connection was created.

Data can be returned as soon as the first data have been received. This functionality is optional and is used in the example.

Example

VB6 program as TCP/IP server [image] Zip file
TwinCAT project as TCP/IP client [image] prx file


TCP/IP Server

TCP/IP is a connection-oriented communication type (peer-to-peer connection). In this example we illustrate how an external connection is established with the Beckhoff controller. The required blocks are FB_IpStartSession, FB_IpReceive and optionally FB_IpSend, FB_IpClose and FB_IpEndSession.

It is advisable to program a step sequence as illustrated in the example below.

The Beckhoff controller acts as server and the partner device as TCP client. The client is a VB6 program.

Step 1

FB_IpStartSession

The block allocates resources on the controller for the TCP/IP communication. The block becomes active with bStart. As long as the block is busy bBusy is set. iDevice should always be zero. iPort is used for the local TCP/IP port number. iMaxConnection indicates the maximum number of connections. The maximum value is 3.

INPUT

bStart: A rising edge activates the block.

iDevice: always "0"

eSocketType: For TCP/IP "SOCK_STREAM" should be used. Please note that the data are stored as a byte stream. The length of the data to be received should be known or a protocol with a start/end ID should be used so that the start and end can be identified from the data stream.

eSocketProtocol: For TCP/IP "IPPROTO_TCP" should be used

iPort: Receiving port number

iMaxConnection: Number of possible connections (max. 3)

tTimeout: Time after which the attempt is aborted.

OUTPUT

bBusy: This output remains TRUE until execution of the command is complete.

bError: This output is switched to TRUE if an error occurs during the execution of a command. The command-specific error code is contained in iErrorId.

iErrorId: Contains the command-specific error code of the most recently executed command (see table).

iSession: Forwards the session number to all IP blocks for which this connection was created.

Step 2

FB_IpReceive

Received data must be stored in a PLC variable. To this end a pointer to pBuffAddr is required, and the size of the variable is specified in cbBuffLen. A positive edge of bValid indicates that the memory contains data or the data of the associated variable are now valid.

INPUT

bClear: A rising edge clears the memory. The block is then ready to receive data again.

iSession: Is linked with iSession from block FB_StartSession.

sRemoteIPAddr: Can be used as filter for approving only a specific IP address.

eSocketProtocol: For TCP/IP "IPPROTO_TCP" should be used

iPort: Local port number

iMaxConnection: Number of possible connections (max. 3)

tTimeout: Time after which the attempt is aborted.

OUTPUT

bBusy: This output remains TRUE until execution of the command is complete.

bError: This output is switched to TRUE if an error occurs during the execution of a command. The command-specific error code is contained in iErrorId.

iErrorId: Contains the command-specific error code of the most recently executed command (see table).

iSession: Forwards the session number to all IP blocks for which this connection was created.

Example

VB6 program as TCP/IP client [image] Zip file
TwinCAT project as TCP/IP server [image] prx file


UDP/IP connection

UDP is a very simple Ethernet connection. UDP data are sent without a mechanism for determining whether the telegram has arrived or not. For UDP communication to work the port number on both sides must be known.

The BX9000 controller from Beckhoff sends data to a VB6 program which then returns these data.

Step 1: Preparation of the UDP communication

FB_IpStartSession

The block allocates resources on the controller for the UDP/IP communication. The block becomes active with bStart. As long as the block is busy bBusy is set. iDevice should always be zero. iPort is used for the local UDP port number of the BX9000. iMaxConnection indicates the maximum number of connections. The maximum value is 3. The eSocketType should be set to "SOCK_DGRAM". eSocketProtocol must be set to "IPPROTO_UDP" for UDP communication. tTimeOut is not used for UDP communication. The iSession must be linked with the following FB_IpSend and FB_ipReceive blocks.

Step 2: Sending of UDP frames

FB_IpSend

A UDP frame is sent with a positive edge of bStart. The IP address is described with sRemoteIPAddr and the destination UDP port number with iPortNo. The sender UDP port number was already configured in the FB_IpStartSession. If bBusy is reset by the block the command was executed.

Step 3: Receiving of UDP frames

FB_IpReceive

This block is used for receiving data. When the block is called the block monitors the arrival of UDP frames. Up to 4 UDP frames are buffered, further UDP frames are discarded. sRemoteIPAddr can be used to set up an IP address filter for receiving data only from a certain device. To receive all UDP frames enter an empty string or leave the variable open. If an IP address filter was configured the port number can also be filtered. Simply enter the corresponding port number in variable iPortNo. To receive all UDP data leave the variable open.
If data are received the variable bValid is set to TRUE. The data are now valid. If the value of the variable cbBytesInStream is not zero, the variable linked with the block is too small and data remain in the buffer.

Example program

Example

VB6 program as TCP/IP server [image] Zip file
BX9000 TwinCAT project as TCP/IP client [image] prx file


ModbusTCP Client

Via the ModbusTCP client the BX9000 can establish a connection to a ModbusTCP server. 3 blocks are available. Fb_MBConnect for establishing a TCP/IP connection, FB_MBGenericReq for the sending and receiving of any Modbus functions, and FB_MBClose for closing the TCP/IP connection. The maximum number of simultaneous client connections is 3. The option of closing and re-opening a TCP/IP connection means that the number of ModbusTCP servers that are accessible is almost unlimited.

FB_MBConnect

FB_MBConnect connects the BX9000 with another device via ModbusTCP. A connection is established with rising edge of bExecute. The IP address is set via sIPAddr. The TCP port number to be used is set via nTCPPort (usually set to 502 for ModbusTCP). bBusy is set as long the block is active. If the ModbusTCP connection was initialised successfully bBusy is set to FALSE and the bError flag is FALSE. If the bError flag is TRUE be, the connection attempt has failed and the associated error code is stored in variable nErrId. nHandle must be connected with blocks FB_MBGernericReq and FB_MBClose.

INPUT

VAR_INPUT
   sIPAddr	: STRING(15);
   nTCPPort    	: UINT;
   bExecute	: BOOL;
   tTimeout	: TIME;
END_VAR

sIPAddr: IP address of the ModbusTCP-server (slave device) with which a Modbus connection is to be established.

nTCPPort : ModbusTCP port number, for ModbusTCP usually 502dec.

bExecute: A rising edge activates the block.

tTimeout: Time after which the attempt is aborted.

OUTPUT

VAR_OUTPUT
   bBusy         	: BOOL;
   bError        	: BOOL;
   iErrId		: WORD;
   nHandle	: UINT;
END_VAR

bBusy: This output remains TRUE until execution of the command is complete.

bError: This output is switched to TRUE if an error occurs during the execution of a command. The command-specific error code is contained in iErrorId.

iErrorId: Contains the command-specific error code of the most recently executed command (see table).

nHandle: Handle that must be connected with blocks FB_MBGernericReq and FB_MBClose.

FB_MBGENERICREQ

Block FB_MBGENERICREQ enables sending and receiving of any ModbusTCP functions. With rising edge of bExecute the block becomes active, bBusy is set and the data contained in pReqBuff are sent. The block reads the length of the data to be sent from variable cbReqLen. Variable nHandle must be linked with the variable from block FB_MBOpen nHandle. The response from the ModbusTCP server (slave) is stored in pResBuff. The size of the variable should be adequate for receiving all data of a ModbusTCP telegram. If the ModbusClient does not receive a response within tTimeOut, bBusy is set to FALSE and bError is set. Variable nErrId contains the error code. cbResponse contains the number of received bytes. This number can be compared with the buffer size of cdResLen. If cbResponse is greater than dResLen data are lost and a larger buffer should be chosen.

INPUT

VAR_INPUT
   nHandle	: UINT;
   pRecBuff	: DWORD;
   cbReqLen    	: WORD;
   pResBuff	: DWORD;
   cbResLen	: WORD;
   bExecute	: BOOL;
   tTimeout	: TIME;
END_VAR

nHandle: Handle - linked with blocks FB_MBOpen.

pReqBuff: Pointer to the data to be sent.

cbReqLen: Length of the data to be sent.

pResBuff: Pointer to the data to be received. The size of the variable must be adequate.

cbResLen: Length of the data to be received. The length must be adequate.

bExecute: A rising edge activates the block.

tTimeout: Time after which the attempt is aborted.

OUTPUT

VAR_OUTPUT
   bBusy         	: BOOL;
   bError        	: BOOL;
   iErrId		: WORD;
   cbResponse	: WORD;
END_VAR

bBusy: This output remains TRUE until execution of the command is complete.

bError: This output is switched to TRUE if an error occurs during the execution of a command. The command-specific error code is contained in iErrorId.

iErrorId: Contains the command-specific error code of the most recently executed command (see table).

cbResponse: Number of bytes that were received.

FB_MBCLOSE

Block FB_MBCLOSE enables closing of a TCP/IP connection. The block is activated with a rising edge of bExecute. As long as the block is busy bit bBusy is set. nHandle must be connected with block FB_MBOpen nHandle. If an error occurs bError is set to TRUE. The error code can be found in nErrId. If the block was called without error a new socket can be opened with FB_MBOpen.

INPUT

VAR_INPUT
   nHandle	: UINT;
   iFlags		: UINT;
   bExecute	: BOOL;
   tTimeout	: TIME;
END_VAR

nHandle: Handle - linked with blocks FB_MBOpen.

iFlags: 0 - TCP/IP connection is closed even if the partner device cannot be reached, 1 - TCP/IP connection is terminated with "FIN"; for the block to be able to close the TCP/IP connection without error it must exist and communication must be operational. It is recommend to use 0 because in this case the TCP/IP connection is always closed, irrespective of the state of the partner device.

bExecute: A rising edge activates the block.

tTimeout: Time after which the attempt is aborted.

OUTPUT

VAR_OUTPUT
   bBusy         	: BOOL;
   bError        	: BOOL;
   iErrId		: WORD;
END_VAR

bBusy: This output remains TRUE until execution of the command is complete.

bError: This output is switched to TRUE if an error occurs during the execution of a command. The command-specific error code is contained in iErrorId.

iErrorId: Contains the command-specific error code of the most recently executed command (see table).

Example

For the example you need two BX9000 or a BC9x00 instead of a BX9000.

The first BX9000 acts as ModbusTCP client
The second BX9000 (or a BC9x00) acts as ModbusTCP server

Development environment | Target system type | PLC libraries to be linked
TwinCAT v2.10.0 and above | BX9000 (165) firmware version >=1.14 | TcBaseBX9000.lbx


FB_Smtp

This function block uses the SMTP protocol (simple mail transfer protocol) to send e-mails. The function block can, for instance, be used to send errors, diagnostic information, or warnings in the form of e-mails. The recipients' addresses are passed as strings to the sTo, sCc, sBcc and sSubject input variables. The maximum string length for recipients' addresses is limited to 80 characters in order to save resources. The string with the mail text itself may, however, be longer.

VAR_INPUT

VAR_INPUT
    bStart		: BOOL;
    sSmtpServer	: STRING(15);
    sFrom		: STRING;
    sTo		: STRING;
    sCc		: STRING;
    sBcc		: STRING;
    sSubject		: STRING;
    pMail		: DWORD;
    tTimeOut		: TIME;
END_VAR

bStart: The function block is activated by a rising edge at this input.

sSmtpServer: IP address of the SMTP server as a string.

sFrom: A string containing the e-mail address of the sender. If the string supplied is empty, then the Bus Controller generates an e-mail address from the name of the Bus Controller and the MAC ID. The maximum string length is limited to 80 characters. It is possible to enter multiple recipient addresses separated by semicolons.

sTo: A string containing the e-mail address of the recipient. A valid e-mail address must be given. The maximum string length is limited to 80 characters. It is possible to enter multiple recipient addresses separated by semicolons.

sCc: A string containing the e-mail address of a further recipient (Cc = carbon copy). This string can also be empty. A copy of the e-mail is sent to this recipient. The e-mail address of this recipient is visible to other recipients. The maximum string length is limited to 80 characters. It is possible to enter multiple recipient addresses separated by semicolons.

sBcc: A string containing the e-mail address of a further recipient (Bcc = blind carbon copy). This string can also be empty. A copy of the e-mail is sent to this recipient. The e-mail address of this recipient is not visible to other recipients. The maximum string length is limited to 80 characters. It is possible to enter multiple recipient addresses separated by semicolons.

sSubject: A string containing the e-mail's subject line. This string can also be empty. The maximum string length is limited to 80 characters.

pMail: The address (a pointer) to a null-terminated string containing the e-mail text. This string can also be empty. The address of the string can be determined with the ADR operator.

tTimeOut: Maximum time allowed for the execution of the command.

VAR_OUTPUT

VAR_OUTPUT
    bBusy		: BOOL;
    bError		: BOOL;
    iErrorId		: WORD;
END_VAR

bBusy: This output remains TRUE until the block has executed a command, but at the longest for the duration supplied to the tTimeOut input.

bError: This output is switched to TRUE if an error occurs during the execution of a command. The command-specific error code is contained in iErrorId.

iErrorId: Contains the command-specific error code of the most recently executed command (table).

Error code (hex) | Description
0x8000 | SMTP server not found.
0x8001 | Resource error.
0x8002 | Socket resource error.
0x8003 | Connection fault.
0x8004 | Communication fault.
0x8005 | Rx error. Communication time exceeded.
0x8006 | Rx error. Communication fault.
0x8007 | Rx error. Frame error.
0x8008 | Communication error. Wrong response.
0x8009 | Tx error. Communication fault.
0x800A | Communication shutdown error.
0x800B | Communication timeout.
0x8010 | Invalid parameter.

Example of a call in FBD

PROGRAM MAIN
VAR
    fbSMTP	: FB_Smtp;
    bSend	: BOOL;
    sMsg 	: STRING(100):='Test';
    bBusy 	: BOOL;
    bError 	: BOOL;
    nErrId 	: UDINT;
END_VAR

In this example, a rising edge at the bStart input sends a mail to 4 recipients.

Development environment | Target platform | PLC libraries to be linked
TwinCAT v2.10.0 and above | BX9xxx (165) firmware version >=1.12 | TcBaseBX9000.lbx


Time protocol (SNTP)

(from firmware version 1.12)

The Simple Network Time Protocol is used to synchronize clocks via the internet. The BX9000 can be synchronized with a time server.

FUNCTION_BLOCK FB_SNTP

If an IPAdresse is entered the Bus Terminal controller uses the SNTP protocol. If an empty string is transferred, the time protocol (UDP port 37) is used.

VAR_INPUT

bStart :BOOL;
sSntpServer :STRING(15);
tTimeOut :TIME;

bOpen: Rising edge starts the block
sSntpServer: SNTP server entry. If an empty string is entered, the time protocol is used (UDP port 37)
tTimeOut: TMOut after which the process is to be terminated

VAR_OUTPUT

bBusy :BOOL;
bError :BOOL;
iErrorId :WORD;
tTime :DT;
cCurrSntpServer :STRING(15);

bBusy: The block is active as long it is TRUE.
bError: Error bit.
iErrorId: Error number.
tTime: Time and date.
sCurrSnptServer: IP address of the SMTP server.

Return parameter iErrId | Meaning
0 | No error
> 0 | Error number (#not documented#)

Example:


FB_AddDnsServer

Up to a maximum of three DNS servers can be passed to the Bus Controller with this function block.

INPUT

VAR_INPUT
   bStart      : BOOL;
   sDNSServer  : STRING(15);
END_VAR

bStart: The function block is activated by a rising edge at this input.

sDNSServer: A string containing the IP address of the DNS server.

OUTPUT

VAR_OUTPUT
   bBusy       : BOOL;
   bError      : BOOL;
   iErrorId    : WORD;
END_VAR

bBusy: This output remains TRUE until execution of the command is complete.

bError: This output is switched to TRUE if an error occurs during the execution of a command. The command-specific error code is contained in iErrorId.

iErrorId: Contains the command-specific error code of the most recently executed command (see table).

Development environment | Target platform | PLC libraries to be linked
TwinCAT v2.10.0 and above | BX9xxx (165) firmware version >=1.12 | TcBaseBX9000.lbx


FB_GetHostByAddr

This function block can determine the host name associated with a specified IP address.

INPUT

VAR_INPUT
   bStart          : BOOL;
   sIPAddr         : STRING(15);
   pHostName       : DWORD;
   cbMaxNameLen    : WORD;
END_VAR

bStart: The function block is activated by a rising edge at this input.

sIPAddr: A string containing the IP address of the host.

pHostName: Contains the address of a string buffer into which the host name that has been found is written. It is the programmer who is responsible for dimensioning the buffer appropriately so that cbMaxNameLen bytes can be removed from it. The address can be determined with the ADR operator.

cbMaxNameLen: Contains the length, in bytes, of the buffer into which the host name that has been found is to be written.

OUTPUT

VAR_OUTPUT
   bBusy           : BOOL;
   bError          : BOOL;
   iErrorId        : WORD;
END_VAR

bBusy: This output remains TRUE until execution of the command is complete.

bError: This output is switched to TRUE if an error occurs during the execution of a command. The command-specific error code is contained in iErrorId.

iErrorId: Contains the command-specific error code of the most recently executed command (see table).

Development environment | Target platform | PLC libraries to be linked
TwinCAT v2.10.0 and above | BX9xxx (165) firmware version >=1.12 | TcBaseBX9000.lbx


FB_GetHostByName

This function block can determine the IP address associated with a specified host name.

INPUT

VAR_INPUT
bStart        : BOOL;
pHostName     : DWORD;
END_VAR

bStart: The function block is activated by a rising edge at this input.

pHostName: Contains the address of a string variable with the host name. The address of a string variable can be determined with the ADR operator.

OUTPUT

VAR_OUTPUT
   bBusy      : BOOL;
   bError     : BOOL;
   iErrorId   : WORD;
   sIPAddr    : STRING(15);
END_VAR

bBusy: This output remains TRUE until execution of the command is complete.

bError: This output is switched to TRUE if an error occurs during the execution of a command. The command-specific error code is contained in iErrorId.

iErrorId: Contains the command-specific error code of the most recently executed command (see table).

sIPAddr: When successful, this variable contains the IP address of the host.

Development environment | Target platform | PLC libraries to be linked
TwinCAT v2.10.0 and above | BX9xxx (165) firmware version >=1.12 | TcBaseBX9000.lbx


FB_GetNetworkConfig

This function block can determine information on the current network configuration.

INPUT

VAR_INPUT
   bStart             : BOOL;
END_VAR

bStart: The function block is activated by a rising edge at this input.

OUTPUT

VAR_OUTPUT
   bBusy              : BOOL;
   bError             : BOOL;
   iErrorId           : WORD;
   sMacId             : STRING(17);
   sIPAddr            : STRING(15);
   sSubnetMask        : STRING(15);
   sDefaultGateway    : STRING(15);
   sDnsServer         : STRING(15);
   sTargetName        : STRING(20);
END_VAR

bBusy: This output remains TRUE until execution of the command is complete.

bError: This output is switched to TRUE if an error occurs during the execution of a command. The command-specific error code is contained in iErrorId.

iErrorId: Contains the command-specific error code of the most recently executed command (see table).

sMacId: Returns the MAC ID of the Bus Controller, for example '00-01-05-13-45-63'.

sIPAddr: Returns the IP address of the Bus Controller.

sSubnetMask: Returns the SubNet mask.

sDefaultGateway: Returns the default gateway.

sDnsServer: Returns the default DNS server (assigned by the DHCP server).

sTargetName: Returns the Bus Controller's current target name.

Development environment | Target platform | PLC libraries to be linked
TwinCAT v2.10.0 and above | BX9xxx (165) firmware version >=1.12 | TcBaseBX9000.lbx


FB_SetTargetName

With this function block a target name can be assigned to the Bus Controller.

INPUT

VAR_INPUT
   bStart           : BOOL;
   sTargetName      : STRING(20);
END_VAR

bStart: The function block is activated by a rising edge at this input.

sTargetName: A string containing the new target name of the Bus Controller.

OUTPUT

VAR_OUTPUT
   bBusy            : BOOL;
   bError           : BOOL;
   iErrorId         : WORD;
END_VAR

bBusy: This output remains TRUE until execution of the command is complete.

bError: This output is switched to TRUE if an error occurs during the execution of a command. The command-specific error code is contained in iErrorId.

iErrorId: Contains the command-specific error code of the most recently executed command (see table).

Development environment | Target platform | PLC libraries to be linked
TwinCAT v2.10.0 and above | BX9xxx (165) firmware version >=1.12 | TcBaseBX9000.lbx


Error codes

Hex | Description
0x8010 | invalid parameter
0x8011 | DNS server list is full
0x801F | Resource error (internal)
0x8020 | invalid host length
0x8021 | no hostname founded
0x802E | Heap error (internal)
0x802F | Resource error (internal)
0x8030 | invalid parameter
0x8031 | invalid hostname
0x8032 | Hostname too long
0x803F | Resource error (internal)
0x804F | Resource error (internal)
0x8050 | no valid IP-Address
0x8052 | no class-D IP-Address
0x8055 | Error inside stack (internal)
0x805F | Resource error (internal)
0x8100 | invalid parameter
0x8102 | no open connection
0x8104 | no remote data
0x8106 | Buffer overrun (only UDP)
0x8200 | Connection already opened
0x8201 | Connect error
0x8202 | Timeout
0x8203 | Resource error (internal)
0x8300 | Timeout
0x8301 | Remote connection shutdown
0x8302 | Internal error
0x8303 | Resource error (internal)
0x8304 | no remote connection
0x8400 | Connection not opened
0x8401 | Timeout
0x8800 | no valid network configuration, for example DHCP is still active
0x8F10 | Session not activated
0x8F11 | Session not ready
0x8F12 | invalid session ID
0x8F13 | invalid state (intern)
0x8F20 | no free slot. There are 2 sessions activated
0x8F21 | Error during task initialization
0x8F22 | Session is already closed


Program transfer via Ethernet

TwinCAT offers a facility for transferring the user program to the Bus Terminal Controller over the fieldbus. The BC/BX can be selected as the target system in PLC Control, after saving in the registry and restarting the TwinCAT system. The TwinCAT-level TwinCAT PLC is necessary.

Minimum requirements:

  • TwinCAT 2.10 build 1251

Initializing the Bus Terminal Controller

Method 1: If you use TwinCAT as a polling PLC.
The coupler must first be made known to the system before it can be selected in PLC Control.
Enter the Bus Terminal Controller in the System Manager, specify type, quantity and size of the fieldbus variables and link them with a task. Save your settings and activate the configuration. Then start the TwinCAT system and the cyclic task.

Method 2: If you only use TwinCAT for programming or configuring:
Click the TwinCAT and icon, and open the features. You can enter the BX 9000 under the AMS router.
Name: any
AMS Net Id: IP address plus ".1.1"
IP address: IP address of the BX9000
Transport type: TCP/IP

Now start TwinCAT, either in the configuration mode (the blue TwinCAT icon) or in the RUN mode (the green TwinCAT icon)

TwinCAT System Manager

PLC Control

When TwinCAT PLC Control is restarted, TwinCAT asks for the target platform, i.e. the device on which the user program is later to run. TwinCAT offers two target platforms as controller, the PC or the Bus Terminal Controller.

Two options are available to you for transmission to the Bus Terminal Controller:

  • AMS for BCxx00 (Bus Terminal Controller without online change)
  • AMS for BCxx50 and BX (Bus Terminal Controller with online change)
  • BC serial – the serial cable for communication via the RS232 interface of the PC and the programming interface of the Bus Terminal Controller

After your program has been created, select the target system under the Online toolbar. TwinCAT must be running to do this. In the example, this is the Ethernet card with Box 1 and the Runtime 1 of the Bus Terminal Controller.


Bus Terminal Controller - Programming via Serial Interface

BECKHOFF Bus Terminal Controller: Programming

Programming via Serial Interface

Every Bus Terminal Controller can be programmed via the PC's RS232 interface.

Select the serial interface in TwinCAT PLC Control.

The settings for the serial interface, port number, baud rate etc. are found under Online/Communication parameters in PLC Control.

The Bus Terminal Controller requires the following setting:

  • Baud Rate: 9600/19200/38400/57600 baud (automatic baud rate detection)
  • Stop bits: 1
  • Parity: even

Programming via the serial interface and ADS

The Bus Terminal Controller can be programmed via the PC's RS232 interface. Before it can be used, the TwinCAT has to be made aware of the Bus Terminal Controller (see serial ADS).

Select the ADS connection in TwinCAT PLC Control.

PLC Control can be accessed via Online/Communication Parameters....


BX9000 - Fieldbus Process Image

BECKHOFF BX9000: Parameterization and Commissioning

Fieldbus Process Image

There are two types of configuration on the BX Controller. You can read which of these two is active on the display of the BX after it has booted.

Default Config

The fieldbus data is located in the Default Config, starting from address 1000. (%IB1000... and %QB1000).

TwinCAT Config

In the TwinCAT Config, fieldbus data is not bound to specific addresses, but has a location that depends on how it has been linked.

The fieldbus process image is independent of which Ethernet protocol is in use.


Ethernet

Ethernet was originally developed by DEC, Intel and XEROX (as the DIX standard) for passing data between office devices. The term nowadays generally refers to the IEEE 802.3 CSMA/CD specification, published in 1985. Because of the high acceptance around the world this technology is available everywhere and is very economical. This means that it is easy to make connections to existing networks.

There are now a number of quite different transmission media: coaxial cable (10Base5), optical fiber (10BaseF) or twisted pairs (10BaseT) with screen (STP) or without screen (UTP). A variety of topologies such as ring, line or star can be constructed with Ethernet.

Ethernet transmits Ethernet packets from a sender to one or more receivers. This transmission takes place without acknowledgement, and without the repetition of lost packets. To achieve reliable data communication, there are protocols, such as TCP/IP, that can run on top of Ethernet.

MAC-ID

The sender and receiver of Ethernet packets are addressed by means of the MAC-ID. The MAC-ID is a 6 byte identification code unique to every Ethernet device in the world. The MAC-ID consists of two parts. The first part (i.e. the first 3 bytes) is a manufacturer identifier. The identifier for Beckhoff is 00 01 05. The next 3 bytes are assigned by the manufacturer and implement a unique serial number. The MAC-ID can, for example, be used for the BootP protocol in order to set the TCP/IP number. This involves sending a telegram containing the information such as the name or the TCP/IP number to the corresponding node. You can read the MAC-ID with the KS2000 configuration software.

The Internet Protocol (IP)

The internet protocol (IP) forms the basis of this data communication. IP transports data packets from one device to another; the devices can be in the same network, or in different networks. IP here looks after the address management (finding and assigning MAC-IDs), segmentation and routing. Like the Ethernet protocol, IP does not guarantee that the data is transported - data packets can be lost, or their sequence can be changed.

TCP/IP was developed to provide standardized, reliable data exchange between any number of different networks. TCP/IP is thus substantially independent of the hardware or software being used. Although the term is often used as if it were a single concept, a number of protocols are layered together: e.g. IP, TCP, UDP, ARP and ICMP.

Transmission Control Protocol (TCP)

The Transmission Control Protocol (TCP) which runs on top of IP is a connection-oriented transport protocol. It includes error detection and error handling mechanisms. Lost telegrams are repeated.

User Datagram Protocol (UDP)

UDP is connectionless transport protocol. It provides no control mechanism when exchanging data between sender and receiver. This results in a higher processing speed than, for example, TCP. Checking whether or not the telegram has arrived must be carried out by the higher-level protocol.

Protocols running on top of TCP/IP and UDP/IP

The following protocols can run on top of TCP/IP or UDP:

  • ADS
  • ModbusTCP

Both of these protocols are implemented in parallel on the Bus Coupler, so that no configuration is needed to activate the protocols.

ADS can be used on top of either TCP or UDP, but ModbusTCP is always based on TCP/IP.


ModbusTCP Protocol

The Ethernet protocol is addressed by means of the MAC-ID. The user does not normally need to be concerned about this address. The IP number has a length of 4 bytes, and must be parameterized by the user on the Bus Coupler and in the application. In ModbusTCP, the TCP port is set to 502. The UNIT can be freely selected under ModbusTCP, and does not have to be configured by the user.

ModbusTCP.jpg (33151 Byte)

TCP port number

The TCP port number for ModbusTCP has been standardized to 502.

Modbus-Unit

The unit is returned by the slave.

ModbusTCP Protocol

Byte | Name | Description
0 | Transaction identifier | Is returned by the slave
1 | Transaction identifier | Is returned by the slave
2 | Protocol identifier | Always 0
3 | Protocol identifier | Always 0
4 | Length field | 0 (if the message is less than 256 bytes in length)
5 | Length field | Number of following bytes
6 | UNIT identifier | Is returned by the slave
7 | Modbus | The Modbus protocol with the function follows


ModbusTCP Interface

BECKHOFF Fieldbus Components: ModbusTCP

Modbus TCP interface

Address |  | Description
0x0000 0x00FF |  | Process data interface Inputs
0x0800 0x08FF |  | Process data interface Outputs
0x1000 0x1006 | Read only | Bus Coupler identification
0x100A |  | 2 byte PLC interface
0x100B |  | Bus terminal diagnosis
0x100C |  | Bus Coupler status
0x1010 |  | Process image length in bits, analog outputs (without PLC variables)
0x1011 |  | Process image length in bits, analog inputs (without PLC variables)
0x1012 |  | Process image length in bits, digital outputs
0x1013 |  | Process image length in bits, digital inputs
0x1020 |  | Watchdog, current time in [ms]
0x110A | Read/Write | 2 byte PLC interface
0x110B |  | Bus terminal diagnosis
0x1120 |  | Watchdog, pre-defined time in [ms] (Default value: 1000)
0x1121 |  | Watchdog Reset Register
0x1122 |  | Type of watchdog | 1 | Telegram watchdog (default)
 |  |  | 0 | Write telegram watchdog
0x1123 |  | ModbusTCP mode** | 1 | Fast Modbus
 |  |  | 0 | Normal Modbus (default)
0x4000 0x47FF |  | Flags area (%MB..)*

* BC 9000 only
** for BC9000 with firmware B7 and BK9000 with firmware B5

Watchdog

The watchdog is active under the factory settings. After the first write telegram the watchdog timer is initiated, and is triggered each time a telegram is received from this device. Other devices have no effect on the watchdog. A second approach, which represents a more sensitive condition for the watchdog, is for the watchdog only to be re-triggered after each write telegram. To do this, write a zero into register 0x1122 (default value "1").
The watchdog can be deactivated by writing a zero to offset 0x1120. The watchdog register can only be written if the watchdog is not active. The data in this register is retained.

Watchdog register

If the watchdog timer on your slave has elapsed it can be reset by writing twice to register 0x1121. The following must be written to the register: 0xBECF 0xAFFE. This can be done either with function 6 or with function 16.

The Bus Coupler's status register

Bit | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
Name | FB | - | - | - | - | - | - | - | - | - | - | - | - | - | CNF | KB
Key
Bit | Name | Value | Description
15 | FB | 1bin | Fieldbus error, watchdog time elapsed
14...2 | - | - | reserved
1 | CNF | 1bin | Bus Coupler configuration error
0 | KB | 1bin | Bus Terminal error

ModbusTCP mode

The fast Modbus mode should only be used in small local networks. The fast ModbusTCP is not active under the default settings. If problems are found to occur with this type of communication, the Bus Coupler should be switched to "normal" ModbusTCP communication. The mode is set in the Modbus interface, offset 0x1123. It is necessary to reset the coupler (e.g. using ModbusTCP function 8) after the change. It is not permitted to send more than one Modbus service within one Ethernet frame in fast Modbus mode.

2 byte PLC interface

Registers in the complex terminals and Bus Terminal Controller registers can be both read and written using the 2 byte PLC interface. The complex terminal registers are described in the associated terminal documentation. The Bus Coupler registers can be used, for example, to read terminal bus diagnostics data, the terminal composition or the cycle times, and the programmed configuration can be written. It is also possible for a manual terminal bus reset to be carried out. The 2-byte PLC interface requires two bytes each of input and output data; a special protocol is processed via these 2 bytes. A description of the 2 byte PLC interface, the registers available in the Bus Couplers and of function blocks for various PLC systems that support the 2 byte PLC interface can be supplied on request.

2 byte diagnostic interface

The terminals' error messages can be sent over the 2-byte diagnostic interface. Terminal bus diagnostics must however be activated for this purpose. The 2-byte diagnostic interface occupies two bytes each of output and input data. A special protocol is processed via these two bytes. A description of the 2 byte-diagnostic interface can be supplied on request.


ModbusTCP Error Answer

BECKHOFF Fieldbus Components: ModbusTCP

ModbusTCP slave error answer (BK9000, BC9000, IP/ILxxxx-B/C900)

When the user sends the slave either a request or information that the coupler does not understand, the slave responds with an error report. This answer contains the function and the error code. 0x80 is added to the value returned by the function.

Code | Name | Meaning
1 | ILLEGAL FUNCTION | Modbus function not implemented
2 | ILLEGAL DATA ADDRESS | Invalid address or length
3 | ILLEGAL DATA VALUE | Invalid parameter - Diagnostic functions - Incorrect register
4 | SLAVE DEVICE ERROR | Watchdog or K-Bus error
6 | SLAVE DEVICE BUSY | Output data is already been received from another IP device


Read Holding Register (Function 3)

The Read Holding Register function can be used to read the input and output words and the registers. The inputs have offsets 0 - 0xFF while the outputs have offsets 0x800 - 0x8FF.

The first two analog outputs are read in this example. The analog outputs begin at offset 0x800. The length indicates the number of channels to be read.

Query

Byte Name | Example
Function code | 3
Start address high | 8
Start address low | 0
Count high | 0
Count low | 2

The fieldbus coupler answers with byte count 4, i.e. 4 bytes of data are returned. The query was for two analog channels, and these are distributed over two words. In the analog output process image, the first channel has the value 0x3FFF, while the second channel has the value 0x0.

Response

Byte Name | Example
Function code | 3
Byte Count | 4
Data 1 high byte | 63
Data 1 low byte | 255
Data 2 high byte | 0
Data 2 low byte | 0


Read Input Register (Function 4)

The Read Input Register function reads the analog inputs.

In this example the first two analog inputs of slave number 11 are read. The analog outputs start at an offset of 0x0000. The length indicates the number of words to be read. A KL3002 has two words of input data, which is why the value to be entered in Count low is two.

Query

Byte Name | Example
Function code | 4
Start address high | 0
Start address low | 0
Count high | 0
Count low | 2

The fieldbus coupler answers with byte count 4, i.e. four bytes of data are returned. The query was for two analog channels, and these are now distributed over 2 words. In the analog input process image, the first channel has the value 0x0038, while the second channel has the value 0x3F1B.

Response

Byte Name | Example
Function code | 4
Byte Count | 4
Data 1 high byte | 0
Data 1 low byte | 56
Data 2 high byte | 63
Data 2 low byte | 11


Preset Single Register (Function 6)

The Preset Single Register function can be used to access the output process image or the flag process image (only at the controller) and the Modbus TCP interface.

The first analog output is written with function 6. The analog outputs start at an offset of 0x0800. Here again the offset always describes a word. This means offset 0x0803 refers to the fourth word in the output process image.

Query

Byte Name | Example
Function code | 6
Start address high | 8
Start address low | 0
Data high | 63
Data low | 255

The Fieldbus Coupler replies with the same telegram and confirmation of the received value.

Response

Byte Name | Example
Function code | 6
Start address high | 8
Start address low | 0
Data high | 63
Data low | 255


Preset multiple register (Function 16)

The Preset Multiple Register function can be used to write a number of analog outputs. The first two analog output words are written in this example. The analog outputs start at an offset of 0x0800. Here the offset always describes a word. Offset 0x0003 writes to the fourth word in the output process image. The length indicates the number of words, and the Byte count is formed from the combination of all the bytes that are to be written.

Example: 4 words – correspond to a byte count of 8

The data bytes contain the values for the analog outputs. In this example, two words are to be written. The first word is to receive the value 0x7FFF, and the second word is to receive the value 0x3FFF.

Query

Byte Name | Example
Function code | 16
Start address high | 8
Start address low | 0
Length high | 0
Length low | 2
Byte Count | 4
Data 1 byte 1 | 127
Data 1 byte 2 | 255
Data 2 byte 1 | 63
Data 2 byte 2 | 255

Response

The coupler replies with the start address and the length of the transmitted words.

Byte Name | Example
Function code | 16
Start address high | 8
Start address low | 0
Length high | 0
Length low | 2


Read or Write Registers (Function 23)

A number of analog outputs can be written and a number of analog inputs read with one telegram using the Read / Wrrite Registers function. In this example the first two analog output words are written, and the first two analog inputs are read. The analog outputs start at offset 0x0800, while the inputs start at offset 0x0000. Here the offset always describes a word. Offset 0x0003 writes to the fourth word in the output process image. The length indicates the number of words, and the Byte count is formed from the combination of all the bytes that are to be written. Example: 4 words – correspond to a byte count of 8

The data bytes contain the values for the analog outputs. In this example, two words are to be written. The first word is to receive the value 0x3FFF, and the second word is to receive the value 0x7FFF.

Query

Byte Name | Example
Function code | 23
Read start address high | 0
Read start address low | 0
Read length high | 0
Read length low | 2
Write start address high | 8
Write start address low | 0
Write length high | 0
Write length low | 2
Byte Count | 4
Data 1 high | 63
Data 1 low | 255
Data 2 high | 127
Data 2 low | 255

Response

The coupler replies with the start address and the length of the bytes to be transferred in Byte count. The data information follows. In this example the first word contains 0x0038 while the second word contains 0x3F0B.

Byte Name | Example
Function code | 23
Byte Count | 4
Data 1 high | 0
Data 1 low | 56
Data 2 high | 63
Data 2 low | 11


ADS Communication

The ADS protocol (ADS: Automation Device Specification) is a transport layer within the Beckhoff TwinCAT system. It was developed for data exchange between the different software modules, for instance the communication between the NC and the PLC. This protocol offers the freedom of using other tools to communicate with any point in TwinCAT. If it is necessary to communicate with another PC or device, the ADS protocol is used on top of TCP/IP. This means that in a networked system, all the data is accessible from any desired point.

The ADS protocol runs on top of the TCP/IP or UDP/IP protocols. It allows the user within the Beckhoff system to use almost any connecting route to communicate with all the connected devices and to parameterize them. Outside the Beckhoff system a variety of methods are available to exchange data with other software tools.

Software interfaces

ADS-OCX

The ADS-OCX is an Active-X component. It offers a standard interface to, for instance, Visual Basic, Delphi, etc.

ADS-DLL

You can link the ADS-DLL (DLL: Dynamic Link Library) into your C program.

OPC

The OPC interface is a standardised interface for communication used in automation engineering. Beckhoff offer an OPC server for this purpose.


ADS Protocol

The ADS functions provide a method for accessing the Bus Coupler information directly from the PC. ADS function blocks can be used in TwinCAT PLC Control for this. The function blocks are contained in the PLCSystem.lib library. It is also equally possible to call the ADS functions from AdsOCX, ADSDLL or OPC. It is possible to access all the data through ADS port number 300, and to access the registers of the Bus Coupler and Bus Terminals through ADS port number 100.

AMSNetID

The AMSNetID provides a reference to the device that is to be addressed. This is created from the set TCP/IP address and an additional 2 bytes. These additional 2 bytes consist of "1.1", and can not be altered.
Example:
IP address 172.16.17.128
AMSNetID 172.16.17.128.1.1

Port number

The port number distinguishes sub-elements in the connected device.
Port 100: Register access
Port 300: Fieldbus process data
Port 800: Local process data (BC90x0 only)

Index group

The index group distinguishes different data within a port.

Index offset

Indicates the offset, the byte from which reading or writing is to start.

Len

Gives the length of the data, in bytes, that that is to be read or written.

TCP port number

The TCP port number for the ADS protocol is 48898 or 0xBF02.


BX9000 - Diagnostics

BECKHOFF Fieldbus Components: Error handling and diagnosis

Diagnostics

Ethernet State

In many cases it is important to know whether the communication with the higher-level master is still OK. To this end, link the FieldbusState variable with your PLC program.

Fig. Ethernet fieldbus state

Fieldbus State

Error number | Description | Remedy
0 | No error | -
1 | Watchdog error | Communication interrupted

Ethernet Type

Here it is possible to determine which Ethernet protocol is accessing the PLC variables, and thereby triggering the watchdog (for example, the data in the Default Config area starting from addresses %IB1000 and %QB1000).

Diagnosis number | Description | Remedy
0x0000 | No protocol is accessing the PLC variables | -
0x0001 | ADS TCP | Communication via ADS TCP/IP
0x0002 | ADS UDP | Communication via ADS UDP/IP
0x0010 | ModbusTCP | Communication via Modbus TCP/IP

Reading fieldbus state by ADS

The fieldbus status can be read through ADSREAD in the default configuration or in the TwinCAT configuration (under development).

Parameter ADSREAD block | Description
NetID | local – empty string
Port |
IndexGroup |
IndexOffset |
LEN |

State of the K-Bus

An internal bus or Bus Terminal error is indicated in the K-Bus state. A more precise fault description can be obtained via a function block (in preparation). To this end, link the K-Bus state variable with your PLC program.

Error bit | Description | Error type
0 | No error | No ERROR.
Bit 0 | K-Bus error | ERROR
Bit 2 | K-Bus is re-triggered | NOTE

Reading K-Bus state by ADS

In default or TwinCAT configuration the fieldbus state can be read via ADSREAD.

Parameter ADSREAD block | Description
NetID | local – empty string
Port | 1
IndexGroup | 16#0006
IndexOffset | 16#000C_9000
LEN | 1


BC9xx0 - Diagnostic LEDs

BECKHOFF Fieldbus Components: Error handling and diagnosis

Diagnostic LEDs

The Bus Terminal Controllers have status LEDs.

BC9050

LEDs for power supply diagnosis

LED (Power LEDs) | Meaning
Power LED Us off | Bus Coupler has no voltage 24 VDC
Power LED Up off | No 24 VDC power supply connected to the power contacts

LEDs for K-bus diagnostics

LED (K-bus) | Meaning
K-bus RUN | on or flashing - K-bus running
K-bus ERR | flashing (see error code)

LEDs for Ethernet diagnostics

LED (Ethernet) | Meaning
LINK/ACT | on - LINK available, flashing - LINK available and communication
ERROR | flashing - DHCP or BootP active. Waiting for an IP address
COM | Communication with controller available

LEDs for PLC diagnostics

LED (Ethernet) | Meaning
PLC | on - PLC running, flashing - cycle time is exceeded, off - cycle time exceeded permanently or PLC stopped
TC/DC | on - TwinCAT configuration active, off - Default configuration active, flashing TwinCAT configuration faulty

BC9120

LEDs for power supply diagnosis

LED (Power LEDs) | Meaning
Power LED Us off | Bus Coupler has no voltage 24 VDC
Power LED Up off | No 24 VDC power supply connected to the power contacts

LEDs for K-bus diagnostics

LED (K-bus) | Meaning
K-bus RUN | on or flashing - K-bus running
K-bus ERR | flashing (see error code)

LEDs for Ethernet diagnostics

LED (Ethernet) | Meaning
LINK/ACT | on - LINK available, flashing - LINK available and communication
10/100Mbaud | on - 100 Mbaud, off - 10 Mbaud
ERROR | flashing - DHCP or BootP active. Waiting for an IP address
COM | Communication with controller available

LEDs for PLC diagnostics

LED (Ethernet) | Meaning
PLC | on - PLC running, flashing - cycle time is exceeded, off - cycle time exceeded permanently or PLC stopped
TC/DC | on - TwinCAT configuration active, off - Default configuration active, flashing TwinCAT configuration faulty

Error code for K-Bus diagnosis

Error
code 		Error
argument 		Description Remedy
- flashing continuously EMC problems
  • Check power supply for overvoltage or undervoltage peaks
  • Implement EMC measures
  • If a K-Bus error is present, it can be localized by a restart of the coupler (by switching it off and then on again)
1 | 0 | EEPROM checksum error | Enter factory settings with the KS2000 configuration software
1 | Code buffer overflow | Insert fewer Bus Terminals. The programmed configuration has too many entries in the table
2 | Unknown data type | Software update required for the Bus Coupler
2 - Reserve -
3 0 K-Bus command error
  • No Bus Terminal inserted
  • One of the Bus Terminals is defective; halve the number of Bus Terminals attached and check whether the error is still present with the remaining Bus Terminals. Repeat until the defective Bus Terminal is located.
4 | 0 | K-Bus data error, break behind the Bus Coupler | Check whether the n+1 Bus Terminal is correctly connected; replace if necessary.
n | Break behind Bus Terminal n | Check whether the Bus End Terminal KL9010 is connected.
5 | n | K-Bus error in register communication with Bus Terminal n | Exchange the nth bus terminal
6 | 0 | Error at initialization | Exchange Bus Coupler
1 | Internal data error | Perform a hardware reset on the Bus Coupler (switch off and on again)
2 | DIP switch changed after a software reset | Perform a hardware reset on the Bus Coupler (switch off and on again)
7 0 Note: Cycle time was exceeded Warning: the set cycle time was exceeded. This indication (flashing LEDs) can only be cleared by booting the Bus Coupler again.
Remedy: increase the cycle time
9 | 0 | Checksum error in Flash program | Transmit program to the BC again
1 | Incorrect or faulty library implemented | Remove the faulty library
10 | n | Bus Terminal n is not consistent with the configuration that existed when the boot project was created | Check the nth Bus Terminal. The boot project must be deleted if the insertion of an nth Bus Terminal is intentional
14 | n | nth Bus Terminal has the wrong format | Start the Bus Coupler again, and if the error occurs again then exchange the Bus Terminal
15 | n | Number of Bus Terminals is no longer correct | Start the Bus Coupler again. If the error occurs again, restore the manufacturers setting using the KS2000 configuration software
16 | n | Length of the K-Bus data is no longer correct | Start the Bus Coupler again. If the error occurs again, restore the manufacturers setting using the KS2000 configuration software


BC9xx0 - First steps

Necessary components

  • A BC9xx0
  • KL1114
  • KL2134
  • KL9010
  • A 24 V DC power supply unit plus cabling material
  • An Ethernet cross cable for a 1:1 connection between PC and BC9020 or BC9050 (without switch)
  • A "normal" Ethernet cable between PC and BC9120

DIP switch settings

Set DIP switch 1 to ON, leave all other DIP switches OFF. A fixed IP address is used. Restart the BC after setting the DIP switches.
BC9050 has IP address 172.16.21.1
BC9020 has IP address 172.16.22.1
BC9120 has IP address 172.16.23.1

Set a suitable IP address on your programming PC, e.g. 172.16.100.100 (SubNetMask 255.255.0.0).

Use the >Ping< command to check whether TCP/IP communication is available. Open the prompt (DOS box) and enter the following, e.g. if a BC9050 is used: Ping 172.16.21.1. If the ping is successful you can continue. If the ping is not answered the communication is faulty. Check the Ethernet connection - right cable, the Controller DIP switch is switched on correctly, the IP address on the PC has changed.

Search BC via the System Manager

Start the System Manager. Select a new target system.

Click Search (Ethernet)...

Then click Broadcast Search. The BC now appears in the window. The host name is formed based on BC plus the last 3 bytes of the MAC ID and is therefore unique in your system. The MAC ID is printed on a label below the Bus Terminal Controller. Set the options button to IP Address and click Add Route. The Connected field should show a cross or "X". If a password query appears confirm with OK (leave blank). The password function is not implemented in the Bus Terminal Controller.

You can now select the Bus Terminal Controller. Click on the BC and confirm with OK.

Your BC with name and IP address is shown in red at bottom left in the System Manager. The field next to it should be blue and show Config Mode. If this is the case you can now scan the device. Right-click on IO Devices then Scan Devices.

The System Manager should find 2 devices, i.e. the Ethernet interface and the K-bus interface with the connected Bus Terminals.

Ethernet interface

Click on Upload to upload the current IP configuration.

PLC configuration

Append your PLC program here. First open the following example: . Save the file locally on your computer.

Recompile the file.

Re-save.

Change back to the System Manager and append your PLC program (right-click on PLC Configuration).

Search for your file (file type: tpy). Then open the tree. You will see all allocated data. Select the variables and link them with your Bus Terminals.
bIN_1 with KL1104 channel 1
bOUT_1 with KL2134 channel 1
bOUT_2 with KL2134 channel 2
bOUT_3 with KL2134 channel 3

After being linked you should now see the following.

Now activate the configuration in the System Manager. Click on [image] to download the configuration to the Bus Terminal Controller. Acknowledge all messages with OK. Finally you will be asked to restart the system. The BC will then reboot. The System Manager will lose the connection with the Bus Terminal Controller. Wait until the System Manager has re-established the connection. After a few seconds the status field at the bottom left of the System Manager should turn green [image]. If it is blue the BC has restarted in Config mode. Check your configuration.

Switch back to PLC Control. Go online and select the target system.

Log in and start the program.


Moving between the controllers

Moving from BCxx00 to BCxx50/BCxx20

File names

At Bus Terminal Controller of BCxx50 and BCxx20 series, libraries are called *.lbx, and programs are saved as *.prx.

Flag variables

The flag variables

  • of BCxx00 are allocated from %MB0...%MB511 (except BC9000/BC9100: %MB0...%B4095)
  • of BCxx20 are allocated from %MB0...%MB4095
  • of BCxx50 are allocated from %MB0...%MB4095

Status information such as K-Bus/fieldbus status or cycle tick is not copied to the BCxx50/BCxx20. For BCxx50/BCxx20 this information is available as a function in the TcSystemBCxx50.lbx library.

The allocated flags don't operate as retain variables.

Retain data

The retain data have to be declared as VAR_RETAIN. Up to 2 kByte are available.

PLC variables

In the default configuration, the PLC variables start at %IB1000 and %QB1000.

Large model

Not available for BCxx50 and BCxx20.

Maximum memory:

  • BCxx50: 48 kByte
  • BCxx20: 128 kByte

Task time

The task time is specified in the PLC Control. It should be set to a realistic value (measuring of PLC cycle time and K-Bus). The background time is no longer used.

Task configuration

A maximum of one task is available. This task has to be configured.

PLC and Field Bus Terminals

On standard bus terminal controllers (BCxx00) it was possible to choose if a bus terminal is allocated to the fieldbus or to the local PLC.

In default configuration of an BCxx50/BCxx20 all bus terminals are allocated to the local PLC. An allocation to the fieldbus is not possible here.

Moving from BCxx00 to BXxx00

File names

At Bus Terminal Controller of BXxx00 series, libraries are called *.lbx, and programs are saved as *.prx.

Flag variables

The flag variables

  • of BCxx00 are allocated from %MB0...%MB511 (except BC9000/BC9100: %MB0...%B4095)
  • of BXxx00 are allocated from %MB0...%B4095

Status information such as K-Bus/fieldbus status or cycle tick is not copied to the BXxx00. For BXxx00 this information is available as a function in the TcSystemBX.lbx library.

The allocated flags don't operate as retain variables.

Retain data

The retain data have to be declared as VAR_RETAIN. Up to 2 kByte are available.

PLC variables

In the default configuration, the PLC variables start at %IB1000 and %QB1000.

Large model

No available for BXxx00. Maximum memory: 256 kByte

Task time

The task time is specified in the PLC Control. It should be set to a realistic value (measuring of PLC cycle time and K-Bus). The background time is no longer used.

Task configuration

A maximum of one task is available. This task has to be configured.

PLC and Field Bus Terminals

On standard bus terminal controllers (BCxx00) it was possible to choose if a bus terminal is allocated to the fieldbus or to the local PLC.

In default configuration of an BXxx00 all bus terminals are allocated to the local PLC. An allocation to the fieldbus is not possible here.

Moving from PC to BCxx50/BCxx20/BXxx00

File names

At Bus Terminal Controllers of BCxx50/BCxx20 and BXxx00 series, libraries are called *.lbx, and programs are saved as *.prx.

Allocated variables

The Bus Terminal Controllers of BCxx50/BCxx20 and BXxx00 series offers a limited number of allocated data:

  • Inputs 2kB, %IB0..2048
  • Outputs 2 kB, %QB0..2048
  • Flags 4 kB, %MB0..4095

Task configuration

A maximum of one task is available. A sensible task time should be selected. Adjust the task time to your application by measuring the required system time (PLC + K-Bus + fieldbus + other).

Retain data

The Bus Terminal Controllers of BCxx50/BCxx20 and BXxx00 series offer up to 2 kB of retain data. Ensure that no (or only very few) retain data are used in function blocks (see RETAIN data).


General operating conditions

The following conditions must be observed if the fieldbus components are to function without error.

Environmental conditions

Operation

The components may not be used without additional protection in the following locations:

  • in difficult environments, such as where there are corrosive vapors or gases, or high dust levels
  • in the presence of high levels of ionizing radiation
Condition | Permissible range
Permissible ambient temperature range during operation | 0°C ... +55°C
Permissible relative humidity during operation | 95 %, no condensation
Installation position | variable
Vibration resistance | conforms to EN 60068-2-6
Shock resistance | conforms to EN 60068-2-27, EN 60068-2-29
EMC resistance burst | conforms to EN 61000-6-2
ESD emission | conforms to EN 61000-6-4

Transport and storage

Condition | Permissible range
Permissible ambient temperature range during storage | -25 °C ... +85°C
Permissible relative humidity | 95 %, no condensation
Free fall | up to 1 m in the original packaging

Protection classes and types

Condition | Permissible range
Protection class in accordance with IEC 536 (VDE 0106, Part 1) | A protective conductor connection to the mounting rail is necessary!
Protection class according to IEC 529 | IP20 (protection against contact with a standard test finger)
Protection against foreign objects | Less than 12 mm in diameter
Protection against water | No protection

Component identification

Every supplied component includes an adhesive label providing information about the product's approvals. For example, on the BK2000:

The following information is printed on the label:

Printed item | In this particular example:
Precise product identification | Lightbus Coupler BK2000
Supply voltage | 24 VDC
Data transfer rate | 2.5 MBaud
manufacturer | Beckhoff Automation GmbH
CE mark | Conformity mark
UL mark

Mark for UL approval. UL stands for the Underwriters Laboratories Inc., the leading certification organization for North America, based in the USA.

C = Canada, US = USA, LISTED 22ZA (the test results can be inspected under this entry)
Production identification

From left to right, this sequence of characters indicates the production week (2 characters), the production year (2 characters), the software version (2 characters) and hardware version (2 characters), along with any special indications (4 characters).

This case therefore is a BK2000
- produced in the 9th calendar week
- of the year 2001
- containing the BF firmware version
- and using the 6th hardware version
- with no special indications


Standards for device testing

EMV

EMC resistance burst

EN 61000-6-2

ESD

EN 61000-6-4

Vibration / Shock resistance

Vibration resistance

EN 60068-2-6

Shock resistance

EN 60068-2-27, EN 60068-2-29


Bibliography

TCP/IP

TCP/IP (English)
Illustrated, Volume1 The Protocols
by W. Richard Stevens
Publisher: ADDISON-WESLEY Longmann Verlag

TCP/IP (German)
Aufbau und Betrieb eines TCP/IP Netzes (Structure and Operation of a TCP/IP Network)
by Kevin Washburn and Jim Evans
Publisher: ADDISON-WESLEY Longmann Verlag

Modbus/TCP

http://www.modicon.com/

http://www.modbus.org

TwinCAT

Beckhoff Information System
http://infosys.beckhoff.com


List of Abbreviations

ADS

Automation Device Specification.

IP (20)

Bus Terminal protection class

IPC

Industrial PC

I/O

Inputs and outputs

K-Bus

Terminal bus

KS2000

Configuration Software for Bus Terminals, Bus Coupler, Bus Terminal Controller, Fieldbus Box Modules and so on

PE

The PE power contact can be used as a protective earth.

TwinCAT

The Windows Control and Automation Technology


Support and Service

Beckhoff and their partners around the world offer comprehensive support and service, making available fast and competent assistance with all questions related to Beckhoff products and system solutions.

Beckhoff's branch offices and representatives

Please contact your Beckhoff branch office or representative for local support and service on Beckhoff products!

The addresses of Beckhoff's branch offices and representatives round the world can be found on her internet pages:
http://www.beckhoff.com

You will also find further documentation for Beckhoff components there.

Beckhoff Headquarters

Beckhoff Automation GmbH

Eiserstr. 5
33415 Verl
Germany

Phone: | +49(0)5246/963-0
Fax: | +49(0)5246/963-198
e-mail: | info@beckhoff.com
Beckhoff Support

Support offers you comprehensive technical assistance, helping you no only with the application of individual Beckhoff products, but also with other, wide-ranging services:

  • support
  • design, programming and commissioning of complex automation systems
  • and extensive training program for Beckhoff system components
Hotline: | +49(0)5246/963-157
Fax: | +49(0)5246/963-9157
e-mail: | support@beckhoff.com
Beckhoff Service

The Beckhoff Service Center supports you in all matters of after-sales service:

  • on-site service
  • repair service
  • spare parts service
  • hotline service
Hotline: | +49(0)5246/963-460
Fax: | +49(0)5246/963-479
e-mail: | service@beckhoff.com