Upload
rinku-chandolia
View
124
Download
7
Tags:
Embed Size (px)
Citation preview
1
Embedded programming in RTOS VxWorks for
PROFIBUS VME interface card
A PROJECT REPORT
Submitted by
SHELAT RUTUL B. (ER NO.090130117001)
CHANDOLIA RINKU K. (ER NO. 090130117023)
In fulfillment for the award of the degree
Of
BACHELOR OF ENGINEERING
in
INSTRUMENTATION & CONTROL
Government Engineering College, Sector 28,
Gandhinagar.
Gujarat Technological University, Ahmedabad
MAY 2013
Government Engineering College, Sector 28,
Gandhinagar.
2
INSTRUMENTATION & CONTROL 2013
CERTIFICATE
Date: This is to certify that the dissertation entitled “Embedded programming in
RTOS VxWorks for PROFIBUS VME interface card” has been carried out
by SHELAT RUTUL B. (ER NO.090130117001) and CHANDOLIA RINKU
K. (ER NO. 090130117023) under our guidance in fulfillment of the degree of
Bachelor of Engineering in INSTRUMENTATION & CONTROL (7th
& 8th
Semester) of Gujarat Technological University, Ahmedabad during the
academic year 2012 - 2013.
Guides: Mr. MAHESH KUMAR KUSHWAH
Electrical engineer. SE, ECRH
group ITER-INDIA(IPR)
&
Mr. DINESH KUMAR SHARMA
Engineer-SE, SST-1 power system
group(IPR)
PROF. RATHOD SWATI YASHVANTBHAI
(INTERNAL) Head of the Department
(HOD)
PROF. AMAR D. RATHOD
3
ACKNOWLEDGEMENT
We express our sincere gratitude and thanks to all those who helped us in the completion
of this project. Of all the persons who have helped us, we would first of all like to thank Mr.
Mahesh Kumar Kushwah, Electrical Engineer, SE, ECRH group, ITER-India (IPR) & Mr.
Dinesh Kumar Sharma, Engineer SE, IPR for their able guidance because of whom we are doing
our project and who helped us at each and every stage of our project.
We are also thankful to Prof. Swati Rathod who guided us as internal project guide in our
college.
They a re very co-operative and always eager to solve our problems. They
always encouraged us to work hard and have given useful suggestions on how to solve the
errors. We are grateful to them for their prolonged interest in our work and excellent
guidance. They have been a constant source of motivation for us. By their uncompromising
demand for quality and their insistence for meeting the deadlines, we could do such an excellent
work. They have shown us a way to pursue excellence. Their time particularity and tactics of
what to learn and how to learn have helped us stepping into professional world as well as to be
a better person.
4
PREFACE
This report is a result of a group exercise carried out as a part of Academic Project. Our
team underwent for project in the EMBEDDED PROGRAMMING IN RTOS VxWORKS FOR
PROFIBUS VME INTERFACE CARD and we are learning its various skills during the process.
We will carry out the complete work of preparing this project individually as well as collectively
and we will learn a lot in this process. Our guides in this endeavor, Mr. Mahesh Kumar Kushwah
& Mr. Dinesh Kumar Sharma are guiding us very well.
5
ABSTRACT
This project is based on real time operating system (RTOS) VxWorks
software in which we are transmitting reference signal from VME (Versa
Module Eurocard ) system to CBP2 (Carrier Board Profibus ) module.
Its main purpose is to transfer reference and ON/OFF data from VME
profibus card to CBP2 module on event.
In this project we have to complete embedded programming in RTOS VxWorks
for carrier board (V6PFB) module and test the same by transferring reference
data from VME based PSCS(Power Supply Control System) to gate pulse
controller mounted on control card of 6RA70 controller on an event.
That reference (current reference acquired from machine control
system) will act as reference data to close loop current control block in simoreg
master drive controller (6RA70 drive controller) controller.
6
List of TABLES
Table No. Name Page No.
3.1 General features of VMEbus 15
3.2 Base address setting of carrier board 20
3.3 Memory map for AVME 9668 21
3.4 DIP switch setting 26
3.5 Power supply selection 26
3.6 IP330 space identification (ID) PROM 27
3.7 I/O space address map for IP33o 28
3.8 Call routine description 40
5.1 Technical specification of V6PFB 86
5.2 V6PFB jumper setting of base address 88
6.1 Pin function of CUD1 91
7
List of FIGURES
Figure No. Name Page No.
1.1 Block diagram 12
3.1 VMEbus wiring connections 16
3.2 Carrier board block diagram 22
3.3 Actual carrier board image 23
3.4 Actual IP330 image 27
3.5 Tornado shell image 32
3.6 Target simulator 34
3.7 Implementation of IP330 in carrier board 35
3.8 Sample programme 36
3.9 Analog input 37
3.10 Output hyper terminal window for sample programme 38
3.11 Semaphore programme 41
3.12 Semaphore programme output 42
3.13 Programme of Interrupt Service routine 44
3.14 Output of Interrupt Service routine 46
3.15 Programme of multitasking 48
4.1 DP master-parameter set 50
4.2 DP slave-parameter set 50
4.3 Tool bus and menus 51
4.4 Database import dialoge 52
4.5 Selecting files for import 52
4.6 Cofiguration of local PROFIBUS innterface 54
4.7 Parameter for local master class2 55
4.8 Template parameters 55
4.9 Setting dialoge 56
4.10 Project pane 57
4.11 Project pane with a master and three slaves in a project 58
4.12 Result of Auto-configuration 58
4.13 Association of slave to group 59
4.14 Master parameters 60
4.15 Net parameters 61
4.16 Basic slave parameters 62
4.17 Selecting modules 63
4.18 Advanced set up of a slave 64
4.19 Extented user parameters 65
4.20 Edit menu with new import "import slaves" 66
4.21 Error message when importing slaves 66
4.22 Master configuration window 68
4.23 Slave configuration window 68
4.24 Compile binary file 73
5.1 Token procedure in PROFIBUS 76
5.2 OSI level of PROFIBUS 79
5.3 PROFIBUS DP 80
8
5.4 PROFIBUS cable image 82
5.5 Actual image of VME interface card 83
5.6 Function block diagram V6PFB 84
5.7 V6PFB board overview 87
6.1 Internal view of 6RA70 89
6.2 CUD1 90
6.3 LED status of CBP2 99
6.4 Drive monitor active window 103
6.5
Drive monitor response analysis window when NO CONNECTION
with 6RA70 108
6.6 net parameters 111
8.1 Connection between 6RA70 and VME system 129
8.2 Input reference signal 130
8.3 Communication status by viewing LEDs 130
8.4 Drive monitor status for reference signal 131
8.5 Screen shot related to fig.8.4 132
8.6 Data transfer through VME interface card 133
9
Table of Contents
---------------------------------------------------------------------------------------------------
TITLE PAGE NO.
COVER PAGE 1
CERTIFICATE 2
ACKNOWLEDGEMENT 3
PREFACE 4
ABSTRACT 5
LIST OF TABLES 6
LIST OF FIGURES 7
TABLE OF CONTENTS 9
CHAPTER 1 INTRODUCTION 12
1.1 INTRODUCTION 12
CHAPTER 2 PROBLEM SUMMARY & TOOLS 13
2.1 PROBLEM SUMMARY 13
2.2 TOOLS & COMPONENTS 13
CHAPTER 3 VME SYSTEM 14
3.1 VMEbus SYSTEM 14
3.1.1 INTRODUCTION OF VMEbus 14
3.1.2 GENERAL FEATURES OF VMEbus 14
3.1.3 THE VME64 EXTENSIONS 15
3.1.4 VMEbus APPLICATIONS 17
3.2 VME MODULES 17
3.2.1 CARRIER BOARD MODULE 18
3.2.2 IP INPUT ANALOG MODULE 23
3.3 PC WITH RTOS VxWorks 28
3.3.1 FACILITIES OF VxWorks REAL TIME OPERATING
SOFTWARE
29
3.4 RESULT ANALYSIS FOR SIMPLE ROUTINE &
SEMAPHORES PROGRAMME
34
10
3.4.1 SIMPLE ROUTINE PROGRAMME 34
3.4.2 WHAT IS SEMAPHORE? 38
CHAPTER 4 DP CONFIGURATION 49
CHAPTER 5 PROFIBUS & PROFIBUS VME INTERFACE CARD 74
5.1 PROFIBUS 74
5.2 PROFIBUS VME INTERFACE CARD 83
CHAPTER 6 6RA70 CHASIS & DRIVE MONITOR 89
6.1 6RA70 CHASIS 89
6.2 DRIVE MONITOR 99
6.2.1 DRIVE MONITOR OVERVIEW 99
6.2.2 DRIVE MONITOR CONFIGURATION 108
CHAPTER 7 PROGRAMME FILE OF SIMPLE DP 112
CHAPTER 8 EXECUTION OF DATA TRANSFER BETWEEN CBP2
MODULE & VME INTERFACE CARD THROUGH
PROFIBUS
129
APPLICATION 137
CONCLUSION 138
REFERENCE 139
12
Chapter 1
Introduction
1.1 Introduction The problem Embedded programming in RTOS Vxworks for PROFIBUS VME Interface
card is related to interfacing or communication of two different system. One system is VME
system which receives reference and status of DC power supply and second CBP2 module
mounted on 6RA70 simoreg master drive controller.
In this project we are transferring reference signal from VMEsystem to CBP2 module
through profibus, as shown in block diagram.
Fig.1.1 Block diagram
13
CHAP TER 2
PROBLEM SUMMARY & TOOLS
2.1 PROBLEM SUMMARY
DC power supply both TF (toroidal field) and PF (poloidal field) are very much integral
part of SST-1(steady state super conducting tokamak) machine. These TF and PF power supplies
are twelve pulse SCR based converter system. These DC coil power supply are connected to
VME bus based control system. And ultimately this power supply control system (PSCS) is
connected to central machine control system.
Here the communication link plays a pivotal role for transferring reference and status of
DC power supply to PSCS and Machine control system. The reference signal for current in the
individual power supply will be transmitted to VME on reflective memory FO link system. From
VME system to all PF power supply a dedicated with redundancy link profibus system will be
used for transferring reference data to all PF power supply.
PF power supply has 6RA70 DC simoreg master (drive controller) for gate firing control
of 12 pulse converter system. A CBP2 module is mounted on the 6RA70 control card for
external fast communication (12 Mbaud speed).
Now the problem arises in interlinking two different systems (one VME and another is
CBP2 module mounted on 6RA70 controller). To interlink effectively, we have a module
Profibus VME interface card.
In this project we have to complete embedded programming in RTOS VxWorks for
V6PFB module and test the same by transferring reference data from VME based PSCS to gate
pulse controller mounted on control card of 6RA70 controller on an event.
2.2 TOOLS & COMPONENTS
To solve the problem, we are using different types of tools & components. These are as
follows:
VME system
VME module
PC with RTOS VxWorks
DP Configuration Software (SOFTING)
Profibus – VME Interface card (V6PFB)
CBP2 installed in 6RA70 drive controller
Oscilloscope and multimeter
14
CHAPTER 3
VME SYSTEM
3.1 VMEbus SYSTEM
3.1.1 Introduction of VMEbus:-
VMEbus is a computer architecture. The term 'VME' stands for VERSAmodule
Eurocard. VMEbus was originally a combination of the VERSAbus electrical standard, and
the Eurocard mechanical form factor. The VMEbus architects were charged with defining a
new bus that would be microprocessor independent, easily upgraded from 16 to 32-bit data
paths, implement a reliable mechanical standard and allow independent vendors to build
compatible products.
No proprietary rights were assigned to the new bus, which helped stimulate third party
product development. Anyone can make VMEbus products without any royalty fees or
licenses. Eurocard is a term which loosely describes a family of products based around the
DIN 41612 and IEC 603-2 connector standards, the IEEE 1101 PC board standards and the
DIN 41494 and IEC 297-3 rack standards.
When VMEbus was first developed, the Eurocard format had been well established in
Europe for several years. A large body of mechanical hardware such as card cages, connectors
and sub-racks were readily available. The pin and socket connector scheme is more resilient
to mechanical wear than older printed circuit board edge connectors.
The ANSI, VITA, IEC and IEEE standards made VMEbus a publicly defined
specification. Since no proprietary rights are assigned to it, vendors and users need not worry
that their products will become obsolete at the whim of any single manufacturer.
Since its introduction, VMEbus has generated thousands of products and attracted hundreds of
manufacturers of boards, mechanical hardware, software and bus interface chips. It continues
to grow and support diverse applications such as industrial controls, military,
telecommunications, office automation and instrumentation systems.
3.1.2 General Features of VMEbus
Since 1970s, a continuous modification and improvement in the VME system takes
15
place, the main general features of VMEbus are as shown in table 3.1
Item Specification Notes
Architecture Master/Slave
Transfer Mechanism Asynchronous, with both
multiplexed & non-
multiplexed bus cycles
No central synchronization
clock
Addressing Range 16, 24, 32, 40 or 64-bit Address range selected
dynamically
Data Path Width 8, 16, 24, 32 or 64-bit Data path width selected
dynamically
Parity Protection No
Data Transfer Rate 0 – 500 Mbyte/sec Experimental VME320
backplane to 500 Mbyte/sec
Interrupts 7 levels Priority interrupt system
with STATUS/ID
Multiprocessing Capability 1 – 21 processor Flexible bus arbitration
Live Insertion Capability Yes High Availability VME64
Control & Status Registers
(Plug & Play Support)
Yes VME64
VME64x
Mechanical Standard 3U single-height Eurocard
6U double-height Eurocard
9U (optional standard)
160 x 100 mm Eurocard
160 x 233 mm Eurocard
367 x 400 Eurocard
User Defined I/O Yes Through the front panel
Maximum Number of Card
Slots in Backplane
21 The number of cards is
limited by how many
boards, located on 0.8”
centers, can be placed into
a 19” rack panel
Table 3.1:- General Features of VMEbus
3.1.3 The VME64 Extensions
In 1997 the VITA Standards Organization (VSO) adopted a superset to the VME64
standard. The latest standard is called the VME64 Extensions (VME64x). VME64x adds new
capabilities such as:
A new 160 pin connector
16
family.
A 95 pin P0/J0 connector.
3.3 V power supply pins.
More +5 VDC power supply
pins.
Geographical addressing.
Higher bandwidth bus cycles
(up to 160 Mbytes/sec).
141 more user-defined I/O pins.
Rear plug-in units
(transition modules).
Live insertion / hot-swap
capability.
Injector / ejector locking handles.
EMC (ElectroMagnetic Compatible)
front panels.
ESD (Electrostatic Discharge) features.
Fig.3.1 VMEbus wiring connection
The VME64x standard also lays the groundwork for the High Availability and Live
Insertion (Hot Swap) VME64x standards.
All legacy VME and VME64 modules are forward compatible to VME64x backplanes
and sub-racks. That means that older bus modules can be plugged into newer systems.
In general, the reverse is also true. Bus modules designed to the VME64x standard are
also backward compatible with older backplanes and subracks. For example, the new 160 pin
connectors can be plugged into an older backplane. However, there are a few exceptions to this.
For example, if a board requires the new +3.3 VDC power supplies, then it will not work in an
older backplane (which does not have these power pins).
The VME64x standard describes many optional features. However, the standard insists
that a minimum set of features be present on boards and backplanes before they are considered to
be VME64x compliant. All of the other features in the standard are considered optional. For
example, the minimum features that must be present on 6U modules include:
160 pin connectors.
17
All defined grounds must be connected (row 'd' is optional).
The minimum features that must be present on a 6U backplane include:
160 pin connectors.
All defined grounds must be connected.
Monolithic PCB (i.e. must include both J1 and J2 connectors).
Geographical address pins.
Must route and terminate all VME64 and VME64x bused signal lines.
Power connection and distribution for +5V, +3.3V, +/- 12V, +/- V1, +/- V2 and VPC.
If rear (user defined) I/O pins are supported, then the rear connections must comply
with the IEEE 101.11 rear I/O transition board standard.
3.1.4 VMEbus Applications
VMEbus is used in a wide variety of applications. In many cases, the VMEbus system
design has been tailored to support specialized applications as well. Some of the most popular
applications are:
Industrial controls: factory automation, robotics, injection molding machines,
automotive body assembly and painting, sawmill controls, metal working, steel
manufacturing, cardboard cutters and many others.
Military: battlefield command & control systems, ground and flight radar control
systems, tank and gun controls, communications, avionics and many others.
Aerospace: avionics, fly-by-wire control systems, in-flight video servers, spacecraft
experiment control, missile countdown sequencers, and many others. In 1998 the
Mars Pathfinder used a VMEbus computer to control spacecraft operation on the
planet Mars.
Transportation: railway controls, smart highway systems and light-rail transit
systems.
Telecom: advanced intelligent node (AIN) switch gear, cellular telephone base
stations, satellite uplink and downlinks and telephone switches. VMEbus live
insertion capabilities were also designed for this application.
Simulation: aircraft flight, earthquake, metal fatigue and various military simulation
systems.
Medical: CATSCAN imaging, MRI imaging and various acoustical systems.
High Energy Physics: particle accelerators, particle detectors.
General business: network routers, servers, copy machines and high-speed printers.
3.2 VME Modules:
In VME System, there are 21 slots these slots used for mounting the VME carrier boards
modules. These carrier boards having slots for IP industrials I/O pack. So in VME system there
is basically two modules are used.
18
These are:
1.Carrier board module (AVME 9668)
2.IP analog I/O module (IP330 analog input module)
3.2.1 Carrier board module
The Carrier board used to carries the IP analog input/output and digital input/output
modules on it, than it is mounted in VMEsystems any one slots for programme writing.
The AVME9668 Series of VMEbus cards are carriers for the Industrial I/O Pack (IP)
mezzanine board field I/O modules. The carrier boards facilitate a modular approach to system
assembly, since each carrier can be populated with any combination of analog input/output and
digital input/output IP modules.
Thus, the user can create a board which is customized to the application which saves
money and space - a single carrier board populated with IP modules may replace several
dedicated function VMEbus boards.
This standard VMEbus 6U size, with support for up to four IP modules.
KEY AVME9668 FEATURES
The main features of AVME carrier board are as follow:
Interface for Four IP Modules : Provides an electrical and mechanical interface for up to
four industry standard IP modules. IP Modules are available from Acromag and other
vendors in a wide variety of Input/Output configurations to meet the needs of varied
applications.
Supports accesses to IP input/output, memory, and ID PROM data spaces.
Full IP Register Access - Makes maximum use of logically organized programmable
registers on the carrier boards to provide for easy configuration and control of IP
modules. The only hardware jumper settings required on the carrier boards set the base
address of the card in the VMEbus short I/O space.
LED Displays Simplify Debugging - On board LED's are dedicated to each IP module to
give a visual indication of successful IP accesses.
Front Panel Connectors Access I/O - Front panel access to field I/O signals is provided
via industry standard 50-pin headers. A separate header is provided for each IP module.
All IP module I/O signals can be connected to SCSI-2cables from the front panel without
interference from boards in adjacent slots.
Optional Screw Termination Panel - Model supports field connection via screw terminals
using the optional DIN rail mount termination panels.
Memory Space Access Support - IP memory space accesses are supported and software
configurable from1Mbyte to 8Mbytes in the VMEbus standard address space.
19
Supports Two Interrupt Channels per IP - Up to two interrupt requests are supported for
each IP. The VMEbus interrupt level is software programmable. Additional registers are
associated with each interrupt request for control and status monitoring.
Supervisory Circuit for Reset Generation - A microprocessor supervisor circuit provides
power-on, power- off, and low power detection reset signals to the IP modules per the IP
specification.
Individually Fused and Filtered Power – Fused and filtered +5V, +12V, and -12V DC
power is provided to the IP modules via passive filters present on each supply line
serving each IP. This provides optimum filtering and isolation between the IP modules
and the carrier board and allows analog signals to be accurately measured or reproduced
on IP modules without signal degradation from the carrier board logic signals.
Interrupt Support - I (1-7) interrupter D16/D08 (O). Up to two interrupt requests are
supported for each IP module. The VMEbus interrupt level is software programmable.
Carrier board software programmable registers are utilized as interrupt request control
and status monitors.
VMEbus INTERFACE CONFIGURATION
The carrier board is shipped from the factory configured as follows: -Carrier board with
VMEbus Short I/O Base Address of 0000H. Board will respond to both Address Modifiers 29H
and 2DH.
Registers on the carrier board plus the I/O and ID spaces on any installed IP modules will
be accessible.
Programmable software registers default to IP memory space (VMEbus standard address
space) accesses disabled.
Programmable software registers default to IP interrupt requests disabled and VMEbus
interrupt level-none.
(A) Address Decode Jumper Configuration
The carrier board interfaces with the VMEbus as a 1K byte block of address locations in
the VMEbus short I/O address space (refer to Section 3 for memory map details). J1 decodes
the six most significant address lines A10 through A15 to provide segments of 1K address
space. The configuration of the jumpers for different base address locations is shown in Table
2.1. "IN" means that the pins are shorted together with a shorting clip. "OUT" indicates that the
clip has been removed. As in table 3.2.
20
Base
Addr*
(Hex)
A15
(11&12
)
A14 (9&10)
A13 (7&8)
A12 (5&6)
A11 (3&4)
A10 (1&2)
0000 OUT OUT OUT OUT OUT OUT 0400 OUT OUT OUT OUT OUT IN 0800 OUT OUT OUT OUT IN OUT 0C00 OUT OUT OUT OUT IN IN 1000 OUT OUT OUT IN OUT OUT . . .
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
.
. EC00 IN IN IN OUT IN IN F000 IN IN IN IN OUT OUT F400 IN IN IN IN OUT IN F800 IN IN IN IN IN OUT FC00 IN IN IN IN IN IN
Jumper Selections (J1 Pins)
TABLE 3.2:- Base address setting of carrier board
Thus jumper in /out used for base address setting.For e.g. if all address lines are in, then
the base address is 0xFCFEFCOO. Where the add. FCOO as shown in table.
(B) VMEbus Address Modifiers
No hardware jumper configuration is needed. The carrier board will respond to both
address modifiers 29H and 2DH in the VMEbus short I/O space. This means that both short
supervisory and short non-privileged accesses are supported.
PROGRAMMIG INFORMATION
The board is addressable on 1K byte boundaries in the Short I/O (A16) Address Space.
This Acromag VMEbus non-intelligent slave (carrier board) has a Board Status register, but no
ID PROM. ID PROM’s are provided per the Industrial I/O Pack logic interface specification on
the mezzanine (IP) boards which are installed on the carrier.
Base
Address +
(Hex)
EVEN Byte
D15 D08
ODD Byte
D07 D00
Base Address + (Hex)
0000
↓
007E
IP A
I/O Space
High Byte
IP A
I/O Space
Low Byte
0001
↓
007F
0080
↓
00BE
Not Used
IP A
ID Space
Low Byte
0081
↓
00BF
00C0
↓
00FE
Not Used
Carrier Board
Registers
(See Table 3.1B)
00C1
↓
00FF
0100
↓
017E
IP B
I/O Space
High Byte
IP B
I/O Space
Low Byte
0101
↓
017F
0180
↓
01BE
Not Used
IP B
ID Space
Low Byte
0181
↓
01BF
21
01C0
↓
01FE
Not Used
Not Used
01C1
↓
01FF
0200
↓
027E
IP C
I/O Space
High Byte
IP C
I/O Space
Low Byte
0201
↓
027F
0280
↓
02BE
Not Used
IP C
ID Space
Low Byte
0281
↓
02BF
02C0
↓
02FE
Not Used
Not Used
02C1
↓
02FF
0300
↓
037E
IP D
I/O Space
High Byte
IP D
I/O Space
Low Byte
0301
↓
037F
0380
↓
03BE
Not Used
IP D
ID Space
Low Byte
0381
↓
03BF
03C0
↓
03FE
Not Used
Not Used
03C1
↓
03FF
Table 3.3:- memory map for AVME9668
From this table, we get idea about the idea of ID space and I/O space for the particular IP
modules that are mounted on carrier board.
For e.g. if the IP module is mounted on slot A then the ID space and I/O space are
As ID space- 0xFCFEFC80 to 0xFCFEFCBE
I/O space-oxFCFEFC00 to 0xFCFEFC7E
22
Fig. 3.2 Carrier Board Block Diagram
In our project we have mounted the IP 330 analog input module on slot B of carrier board
as shown in the following image.
Then ID space- 0xFCFEFD80 to 0xFCFEFDBE
I/O space-oxFCFEFD00 to 0xFCFEFD7E
23
Fig. 3.3 Actual Carrier Board Image
3.2.2.IP input analog module:
IP modules provide a convenient method of implementing a wide range of I/O, control,
interface, slave processor ,analog and digital functions.
The Industrial I/O Pack (IP) Series IP330 module is a precision16-bit, high density, single
size IP, with the capability to monitor 16 differential or 32 single-ended analog input channels.
The IP330 utilizes state of the art Surface Mounted Technology (SMT) to achieve its high channel
density. Four units may be mounted on a carrier board to provide up to 64 differential or 128
single-ended analog input channels per 6U-VMEbus system slot or ISA bus (PC/AT) system slot.
The IP330 offers a variety of featuresas explain above.
KEY IP330 FEATURES:
A/D 16-Bit Resolution - 16-bit capacitor-based successive approximation Analog to Digital
24
Converter (ADC) with integral sample and hold and reference.
High density- Monitors up to 16 differential or 32 single-ended analog inputs (acquisition
mode and channels are selected via programmable control registers).
8usec Conversion Time - A maximum conversion rate of 125KHz is supported. Maximum
recommended conversion rate for specified accuracies is 67KHz.
Individual Channel Mail Box - Two storage buffer registers Are available for each of the 16
differential channels. If configured for 32 single-ended channels, one storage buffer register
is available for each of the 32 channels.
Interrupt Upon Conversion Complete Mode – May be programmed to interrupt upon
completion of conversion for each individual channel or upon completion of conversion of
the group of all scanned channels.
Programmable control of channel scanning- Scan all channels or a subset of the channels
to allow an overall higher sample rate. The channels digitized include all sequential
channels beginning with a specified start-channel value and ending with a specified end-
channel value.
User programmable interval timer- Controls the delay between each channel converted
when Uniform-Continuous or Single Scan modes are selected. If Burst-Continuous is
selected, the Interval Timer controls the delay after a group of channels are converted before
conversion is initiated on the group again. Supports a minimum interval of 8 sec and a
maximum interval of 2.09 seconds.
Uniform Continuous Scanning Mode - All channels selectedfor scanning are continually
digitized in a round robin fashion with the interval between conversions controlled by the
programmed interval timer. The results of each conversion are stored in the channel’s
corresponding mailbox buffer. Scanning is initiated by a software or external trigger.
Scanning is stopped by software control.
Burst Continuous Scanning Mode - All selected input scan channels are sequentially
digitized at a 67KHz conversion rate (15 second conversion time). At the end of a
programmed interval time a new conversion of all channels is re-initiated. The conversion
results are stored in each channel’s mail box buffer.
Uniform Single Cycle Scan Mode - All channels selected for scanning are digitized once
with the idle time between each channel conversion controlled by the programmed interval
timer. The scan is initiated by a software or external trigger.
Burst Single Cycle Scan Mode - All channels selected for scanning are digitized once at a
66.7KHz conversion rate (15 sec/Channel). The scan is initiated by a software or external
trigger.
External Trigger Scan Mode - A single channel is digitized with each external trigger.
25
Successive channels are digitized in sequential order with each new external trigger. This
mode allows synchronization of conversions with external events that are often
asynchronous.
External Trigger Output - The external trigger is assigned to a field I/O line. This external
trigger may be configured as an output signal to provide a means to synchronize other
IP330’s or devices to a single IP330’s on board timer reference.
User Programmable Gain Amplifier - Provides independently software controlled gains (1,
2, 4, and 8V/V) for each of the 16 differential or 32 single-ended channels.
Hardware DIP Switch For Selection of A/D Ranges - Both bipolar 5V, 10V) and
unipolar (0 to 5V and 0 to 10V) ranges are available. Selected range applies to all channels
and can- not be individually selected on a per channel basis.
New Data Register - This register can be polled, to indicatewhen new digitized data is
available in the mail box. A set bit indicates a new digitized data value is available in the
bit’s corresponding mail box register. Register bits are cleared upon read of their
corresponding mail box register or start of a new scan cycle.
User Programmable Data Output Format - Software control provides selection of straight
binary or binary two’s complement data output format.
Hardware Jumpers For Selection of Internal or External Supply - Hardware jumper provide
a means to select internal +/-12 volts or external +/-15 volt supplies. External supplies are
required when using inputs exceeding +/-8.5 volts.
IP module configuration:
For configure IP module, its hardware jumper configuration and analog input hardware
configuration are done and then mounted on carrier board module.
(a)Default Hardware Jumper Configuration:
1. When the board is shipped from the factory, it is configured as follows:
Analog input range is configured for a bipolar input with a 10 volt span (i.e. an ADC input range of
-5 to +5 Volts).
2. Internal +12 and -12 Volt power supplies are used (sourced from P1 connector).
3. The default programmable software control register bits at power-up are described in. The
control registers must be programmed to the desired gain, mode, and channel configuration before
starting ADC analog input acquisition.
Analog Input Range Hardware Jumper Configuration
The ADC input range is programmed via hardware DIP switch. The DIP switch controls the
input voltage span and the selection of unipolar or bipolar input ranges. The configuration of the
DIP switch for the different ranges is shown in the following table. A switch selected as "ON"
would be positioned to the side of the DIP labeled “ON”.
26
Desired ADC
Input Range*
(VDC)
Required
Input Span
(Volts)
Required
Input Type
Switch
Settings ON
Switch
Settings
OFF -5 to +5 10 Bipolar 1,3,4,9 2,5,6,7,8
-10 to +10** 20 Bipolar 2,5,6,9 1,3,4,7,8
0 to +5 5 Unipolar 1,3,5,8 2,4,6,7,9
0 to +10** 10 Unipolar 1,3,4,7 2,5,6,8,9
Analog Input Range Selections/DIP Switch Setting
Table 3.4:- DIP Switch Setting
Power Supply Hardware Jumper Configuration
The selection of internal or external analog power supplies is accomplished via hardware
jumpers J1 and J2. J1 (J2) controls the selection of either the internal +12 (-12) Volt supply
sourced from P1 connector, or the external +15 (-15) Volt supply sourced from the P2 connector.
The configuration of the jumpers for the different supplies is shown in Table3.5.
Power Supply Selections (Pins of J1 and J2)
Power supply
Selection
J1(1&2) J1(2&3) J2(1&2) J2(2&3)
+/-12volt(int.P1) OUT IN OUT IN
+/15volt(ext.P2) IN OUT IN OUT
Table 3.5:- Power supply selection
As shown in following fig.
27
Fig. 3.4 Actual ip330 module
Programming Information
IP IDENTIFICATION PROM
Each IP module contains an identification (ID) information that resides in the ID space per
the IP module specification. This area of memory contains 32 bytes of information at most. Both
fixed and variable information may be present within the ID space. Fixed information includes the
"IPAC" identifier, model number, and manufacturer's identification codes. Variable information
includes unique information required for the module. The IP330 ID information does not contain
any variable (e.g. unique calibration) information.
Hex Offset From ID
PROM Base Address
ASCII Character
Equivalent
Numeric
Value (Hex)
Field Description
01 I 49 All IP's have 'IPAC'
03 P 50
05 A 41
07 C 43
09 A3 Acromag ID Code
Table 3.6:- IP330 ID Space Identification (ID) PROM
I/O SPACE ADDRESS MAP
This board is addressable in the Industrial Pack I/O space to control the acquisition of analog
inputs from the field. As such, three types of information are stored in the I/O space: control,
status, and data.
The I/O space may be as large as 64, 16-bit words (128 bytes) using address lines A1 to A6,
28
but the IP330 uses only a portion of this space. The I/O space address map for the IP330 is shown
in Table 3.7.
Base
Addr+ MSB
D15 D08 LSB
D07 D00 Base
Addr+
00 Control Register 01
02 Timer Prescaler Interrupt Vector 03
04 Conversion Timer 05
06 End Channel Value
Start Channel Value
07
08 New Data Register Channels 0 to 15
09
0A New Data Register Channels 16 to 31
0B
0C Missed Data Register Channels 0 to 15
0D
0E Missed Data Register Channels 16 to 31
0F
10 Not Used Bits15 to Bit 01
Start Convert Bit-0
11
Table 3.7:- I/O space address map for the IP330
3.3 PC with RTOS VxWorks:
Real Time Operating System (RTOS) is a computer system that has timing constraints, that means
an RTOS is partly specified in terms of its ability to make certain calculations or decisions in a timely
manner; that means any system is RTOS if it is Deterministic.
Types of RTOS:-
1.Hard RTOS
2.Soft RTOS
HARD RTOS:-
A system is a hard real time system if failure to respond to an event within a specified
time is considered complete system failure. Complete system failure mean a failure that the
system designers consider unacceptable.
Example- shuttle-craft flight controls
29
SOFT RTOS:-
In soft real time system ,timeliness of response is important but not a matter of life and
death. Designers of a soft rts having witnessed a missed deadline,so syetem failed that one time
.Not a big deal.
Example- remote controlled TV system
VxWorks is RTOS software is using to write programming for communicate real time
applications. For VMEbus there is many RTO software that used for programming. VxWorks
real time operating syatem runs time critical or embedded application.
3.3.1 Facilities of VxWorks Real Time Operating software are:
High-Performance Real-time Kernel Facilities
The VxWorks kernel, wind, includes multitasking with preemptive priority scheduling,
intertask synchronization and communications facilities, interrupt handling support,
watchdog timers, and memory management.
I/O System
VxWorks provides a fast and flexible ANSI C-compatible I/O system
C++ Development Support
In addition to general C++ support including the iostream library and the
standard template library.
Utility Libraries
VxWorks provides an extensive set of utility routines, including interrupt handling,
watchdog timers, message logging, memory allocation, string formatting and scanning,
linear and ring buffer manipulations
Target Agent
The target agent allows a VxWorks application to be remotely debugged using the
Tornado development tools.
Board Support Packages
VxWorks also provides board support packages.
VxWorks Simulator
Multitasking and Intertask Communications are also done by VxWorks.
Brief of tornado VxWorks software:
Tornado Host IDE:
Tornado integrates the various aspects of VxWorks programming into a single
environment for developing and debugging VxWorks applications. The Tornado IDE
allows developers to organize, write, and compile applications on the host system; and
then download, run, and debug them on the target. This section provides more detail on
30
the major features of the IDE.
Tornado Editor
The Tornado source-code editor includes the following features:
Standard text manipulation capabilities.
C and C++ syntax-element color highlighting.
Debugger integration: the editor window tracks code execution.
Compiler integration: the project-management utility links compiler warnings and errors
directly to the affected source in an editor window.
Project Management:
The Tornado project facility simplifies organizing, configuring, and building VxWorks
applications. It includes graphical configuration of the build environment (including compiler
flags), as well as graphical configuration of VxWorks (with dependency and size analysis). The
project facility also provides for basic integration with common configuration management tools
such as ClearCase. The project facility provides mechanisms for:
Organizing the files that make up a project.
Grouping related projects into a workspace.
Customizing and scaling VxWorks.
Adding application initialization routines to VxWorks.
Defining varied sets of build options.
Building applications and VxWorks images.
Downloading application objects to the target.
Compiler:
Tornado includes the GNU compiler for C and C++ programs, as well as a collection of
supporting tools that provide a complete development tool chain:
cpp, the C preprocessor
gcc, the C and C++ compiler
make, the program-building automation tool
ld, the programmable static linker
as, the portable assembler
binary utilities
These tools are supported, commercial versions of the leading-edge GNU tools originally
developed by the Free Software Foundation (FSF). Users of the GNU tools benefit from the
innovative FSF development environment as well as from testing and support by Wind River
Systems.
Among other features, the Tornado project facility provides a GUI for the GNU tools that
is powerful and easy to use.
31
WindSh Command Shell:
WindSh is a host-resident command shell that provides interactive access from the host to
all run-time facilities. The shell provides a simple but powerful capability: it can interpret and
execute almost all C-language expressions. It also supports C++, including "demangling" to
allow developers to refer to symbols in the same form as used by the original C++ source code.
Thus the shell can be used to call run-time system functions, call any application function,
examine and set application variables, create new variables, examine and modify memory, and
even perform general calculations with all C operators.
For even more versatile shell scripting and target control, the Tornado shell includes a
complete Tcl interpreter as well as the C interpreter. The shell also provides the essential
symbolic debugging capabilities, including breakpoints, single-stepping, a symbolic
disassembler, and stack checking.
The shell interpreter maintains a command history and permits command-line editing.
The shell can redirect standard input and standard output, including input and output to the
virtual I/O channels supported by the target agent.
As a convenience, there is some overlap between WindSh and CrossWind, the Tornado
debugger. (Conversely, the CrossWind debugger provides access to all shell built-in commands.)
From the shell, you can perform the following debugging activities:
Display system and task status.
Generate a symbolic disassembly of any loaded module.
Set breakpoints and single-step specific tasks, even in shared code.
Set breakpoints and single-step the system as a whole, even in interrupt service
routines.
As with all Tornado tools, these facilities provide symbolic references wherever possible,
using the symbol table managed by the target server.
32
Fig 3.5:- TORNADO Shell Image
CrossWind Debugger:
The remote source-level debugger, CrossWind, is an extended version of the GNU
source-level debugger (GDB). The most visible extension to GDB is a straightforward
graphical interface. CrossWind also includes a comprehensive Tcl scripting interface that
allows you to create sophisticated macros or extensions for your own debugging
requirements. For maximum flexibility, the debugger console window synthesizes both
the GDB command-line interface and the facilities of WindSh, the Tornado shell.
From your development host, you can use CrossWind to do the following:
Spawn and debug tasks on the target system.
Attach to already-running tasks, whether spawned from your application, from a
shell, or from the debugger itself.
33
Use breakpoints and other debugging features at either the application level or the
system level.
View your application code as C or C++ source, as assembly-level code, or in a
mixed mode that shows both.
Browser:
The Tornado browser is a system-object viewer, a graphical companion to the Tornado
shell. The browser provides display facilities to monitor the state of the target system,
including the following:
Summaries of active tasks (classified as system tasks or application tasks).
The state of particular tasks, including register usage, priority, and other attributes.
Comparative CPU usage by the entire collection of tasks.
Stack consumption by all tasks.
Memory allocation.
Summary of modules linked dynamically into the run-time system.
Structure of any loaded object module.
Operating-system objects such as semaphores, message queues, memory
partitions, and watchdog timers.
Using the browser following thing also examine:
detailed task information
semaphores
message queues
memory partitions
watchdog timers
stack usage by all tasks on the target
WindView Software Logic Analyzer:
WindView is the Tornado logic analyzer for real-time software. It is a dynamic
visualization tool that provides information about context switches, and the events that lead to
them, as well as information about instrumented objects.
Tornado includes an integrated version of WindView designed solely for use with the
VxWorks target simulator. WindView is available as an optional product for all supported target
architectures.
WindView is described in the WindView User's Guide.
VxWorks Target Simulator:
The VxWorks target simulator is a port of VxWorks to the host system that simulates a
target operating system. No target hardware is required. The target simulator facilitates learning
Tornado usage and embedded systems development. More significantly, it provides an
independent environment for developers to work on parts of applications that do not depend on
hardware-specific code (BSPs) and target hardware.
34
Tornado includes a limited version of the target simulator that runs as a single instance
per user, without networking support. Optional products such as STREAMS, SNMP, and Wind
Foundation Classes are not available for this version.
The full-scale version of the simulator, VxSim, is available as an optional product. It
supports multiple-instance use, networking, and all other optional products.
Fig 3.6:- Target Simulator
3.4 RESUIT ANALYSIS FOR SIMPLE ROUTINE AND SEMAPHORES PROGRAMME
3.4.1 SIMPLE ROUTINE PROGRAMME:
To write simple routine program following task are required done:
1.for carrier board AVME9668 setting the jumper for base address.
For e.g.:- if all lines A10 to A15 are ‘IN’ then the 32-bit base address is 0xfcfefcoo.
2.mounted IP330 16-bit high density analog input module on any one slots of carrier
board(slots-A,B,C,D).after that carrier board mounted in VMEsystem.
e.g.IP330 mounted on slots B as shown in fig. ID space identification base address is
(0xfcfefc00+0x100) 0xfcfefd00.
35
Fig. 3.7:- Implementation of ip330 on carrier board
3. Then write sample programme as shown in fig. 3.8.
38
5.check digital output codes on simulator by running the programme. The output is shown.
Fig. 3.10 Output of sample programme on simulator
Procedure:
1.Copy the source code in the example and compile it.
2.Load the object file onto the target machine.
3.Run the example by executing the main routine (binary,etc.)of the example on WindSh
terminal.
Note: Make sure about redirected I/O,otherwise we won’t see the results of the printf commands. 3.4.2 What is semaphore?
VxWorks semaphores are highly optimized and provide the fastest intertask communication
mechanism in VxWorks. Semaphore is a tool that allows multitasking applications in
VxWorks. All tasks in VxWorks exist in a single linear address space. Using semaphores, the
exchange of data is simplified by shared address space.
39
Types of semaphores:
There are three types of semaphores.
1. Binary
2. Mutual exclusion
3. Counting
Binary semaphores: VxWorks binary semaphores are the most versatile & fastest, efficient and conceptually
simple type of semaphore. They can be used to: (1) control mutually exclusive access to shared
devices or data structures, or (2) synchronize multiple tasks and interrupt-level processes. Binary
semaphores form the foundation of numerous VxWorks facilities. A binary semaphore can be
viewed as a cell in memory whose contents are in one of two states, full or empty.
Mutual exclusion semaphores:
The mutual-exclusion semaphore is a specialized binary semaphore designed to
address issues inherent in mutual exclusion, including priority inversion, deletion
safety, and recursive access to resources. The fundamental behavior of the mutual-exclusion
semaphore is identical to the binary semaphore, with the following exceptions:
■ It can be used only for mutual exclusion.
■ It can be given only by the task that took it.
Counting semaphores:
Counting semaphores are another means to implement task synchronization and mutual
exclusion. The counting semaphore works like the binary semaphore except that it keeps track of
the number of times a semaphore is given. Every time a semaphore is given, the count is
incremented; every time a semaphore is taken, the count is decremented. When the count reaches
zero, a task that tries to take the semaphore is blocked. As with the binary semaphore, if a
semaphore is given and a task is blocked, it becomes unblocked. However, unlike the binary
semaphore, if a semaphore is given and no tasks are blocked, then the count is incremented. This
means that a semaphore that is given twice can be taken twice without blocking
CALL ROUTINE DESCRIPTION
semBCreate(SEM_Q_PRIORITY,
SEM_FULL)
Allocates and initializes a binary semaphore.
SemMCreate(SEM_Q_PRIORITY
| SEM_INVERSION_SAFE)
Allocates and initializes a mutual-exclusion semaphore.
semCCreate(SEM_Q_PRIORITY,
__________)
Allocates and initializes a counting semaphore.
semDelete(semId) Terminates and frees a semaphore.
40
semTake(semId,
WAIT_FOREVER)
Takes a binary, mutual-exclusion, or counting semaphore or
a read/write semaphore in write mode. A semTake() with
WAIT_FOREVER means wait indefinitely & if it’s with
NO_WAIT, it means no wait at all.
semGive(semId) Gives a binary, mutual -exclusion, or counting semaphore.
semFlush(semId) Unblocks all tasks that are waiting for a semaphore.
Table 3.8:- Call Routine Description
We are using semBCreate(SEM_Q_PRIORITY, SEM_FULL) as binary semaphores are the
most versatile & fastest, efficient and conceptually simple type of semaphore.
The programme with binary semaphores as follows:
#include <vxWorks.h>
#include <stdio.h>
#include <taskLib.h>
#include <logLib.h>
#include <semLib.h>
//#include <gecg28ip330.h>
#define ip330_base 0xfcfefd00
void appy_test(void);
void gecg28(int);
SEM_ID semId;
volatile unsigned short* ip330_ct=(unsigned short*)0xfcfefd00;
volatile char* ip330_en=(char*)0xfcfefd06;
volatile char* ip330_st=(char*)0xfcfefd07;
volatile char* ip330_tp=(char*)0xfcfefd02;
volatile unsigned short* ip330_ctb=(unsigned short*)0xfcfefd04;
volatile char* ip330_scb=(char*)0xfcfefd11;
volatile unsigned short* ch1=(unsigned short*)0xfcfefd40;
void appy_test(void)
{
int tid, i=5;
semId=semBCreate(SEM_Q_FIFO, SEM_EMPTY);
tid=taskSpawn("gecg",123,0,5000,(FUNCPTR)gecg28,i,0,0,0,0,0,0,0,0,0);
}
void gecg28(int d)
{
semTake(semId, WAIT_FOREVER);
*ip330_ct=0x0906;
*ip330_en=0x01;
*ip330_st=0x00;
*ip330_tp=0x50;
*ip330_ctb=0x18;
taskDelay(5);
*ip330_scb=0x01;
taskDelay(5);
printf("ip330 channel 1 value =%x %d \n",*ch1, d);
42
Fig. 3.12 Semaphore program output
Procedure:
1.Copy the source code in the example and compile it.
2.Load the object file onto the target machine.
3.Run the example by executing the main routine (binary,etc.)of the example on WindSh
terminal.
Note: Make sure about redirected I/O,otherwise we won’t see the results of the printf commands.
ISR (Interrupt Service Routine)
What is ISR?
ISR (Interrupt Service Routine) is a tool used for interrupting the sequence of the program.
Interrupts allow devices to notify the CPU that some event has occurred.
In VxWorks, C functions can be connected to any interrupt by intConnect( ).
ISRs are restricted to be used in Some VxWorks functions such as semTake( ), malloc( ), printf(
) etc. because these call functions may cause blocking and thus creation & deletion functions are
restricted.
To print out messages from an ISR, function logMsg or other functions provided by the library
logLib are used.
43
To improve cooperation between VxWorks' ISRs and tasks, the best
mechanism is semaphore semGive( ).
CALL ROUTINE for ISR
intConnect(INUM_TO_IVEC(INTERRUPT_LEVEL),(VOIDFUNCPTR)interruptHandler,i)
to write interrupt programme following registers are required to configure:-
(1) Carrier Board Status Register (CBSR)
(2) Interrupt Vector Register (IVR)
(3) Interrupt Level Register (ILR)
(4) Interrupt Clear Register (ICR)
(5) Interrupt Enable Register (IER)
(1) Carrier Board Status Register (CBSR) - (Read/Write, Base + C1H)
The Carrier Board Status Register reflects and controls functions globally on the carrier board.
MSB D7 D6 D5 D4 D3 D2 D1 LSB D0
ACE
(Auto
Clear
Interrupt
Enable)
Not Used Not Used Soft
Reset
GIE
(Global
Interrupt
Enable)
GIP
(Global
Interrupt
Pending)
Not Used Not Used
Where;
Bit 7 Writing a ‘1’ to this bit will enable automatic clear of pending interrupts on the
carrier. An interrupt will only remain set as pending on the carrier if its
corresponding IP module has an active interrupt request.
Bits 6,5 Not used – equal ‘0’ if read
Bit 4 Writing a ‘1’ to this bit causes a software reset. Writing a ‘0’ to this bit for
hardware interrupt.
Bit 3 writing a ‘1’ to this bit enables interrupts to be serviced, provided the interrupts
are supported and configured. Set this bit to ‘0’ disables the interrupts.
Bit 2 this bit will be ‘1’ when there is an interrupt pending. This bit will be ‘0’ when no
interrupt is pending.
Bits 1,0 Not used – equal ‘0’ if read
(2) Interrupt Vector Register (IVR) – (Read/Write, Base + 03H)
The Vector Register can be written with an 8-bit interrupt vector. This vector is provided to the
carrier and system bus upon an active INTSEL* cycle. Read or writing to this register is possible
via 16-bit or 8-bit data transfers. 16-bit data transfers will implement simultaneous access the
Interrupt Vector and Timer Prescaler registers. The register contents are cleared upon reset.
46
Fig. 3.14 output of ISR program
Procedure:
1.Copy the source code in the example and compile it.
2.Load the object file onto the target machine.
3.Run the example by executing the main routine (binary,etc.)of the example on WindSh
terminal.
Note: Make sure about redirected I/O,otherwise we won’t see the results of the printf commands.
Multi-Tasking
Multi tasking in VxWORKS:
Multi tasking is a process in which a set of independent tasks are performed.
In the VxWorks multitasking is performed by using
either interrupt or priority- based task scheduling.
A muilitask's context includes:
a thread of execution, that is, the task's program counter
the CPU registers and floating-point registers if necessary
a stack of dynamic variables and return addresses of function calls
I/O assignments for standard input, output, error
a delay timer
a timeslice timer
47
kernel control structures
signal handlers
debugging and performance monitoring values
The routine taskSpawn creates the new task context, which includes allocating and setting up
the task environment.
The new task begins at the entry to the specified routine.
Syntax
id = taskSpawn(name,priority,options,stacksize,function, arg1,..,arg10);
programme of multi-tasking:
#include <vxWorks.h>
#include <stdio.h>
#include <taskLib.h>
#include <logLib.h>
#include <semLib.h>
//#include <gecg28ip330.h>
#define ip330_base 0xfcfefd00
#define ITERATIONS 10
void gecg28(void);
volatile unsigned short* ip330_ct=(unsigned short*)0xfcfefd00;
volatile char* ip330_en=(char*)0xfcfefd06;
volatile char* ip330_st=(char*)0xfcfefd07;
volatile char* ip330_tp=(char*)0xfcfefd02;
volatile unsigned short* ip330_ctb=(unsigned short*)0xfcfefd04;
volatile char* ip330_scb=(char*)0xfcfefd11;
volatile unsigned short* ch1=(unsigned short*)0xfcfefd40;
spawn_ten() /* Subroutine to perform the spawning */
{
int i, taskId;
for(i=0; i < ITERATIONS; i++) /* Creates ten tasks */
taskId = taskSpawn("gecgprint",90,0x100,2000,print,0,0,0,0,0,0,0,0,0,0);
}
void gecg28(void) /* Subroutine to be spawned */
{
printf("Hello, I am task %d\n",taskIdSelf()); /* Print task Id */
}
48
Fig. 3.15 Program of multi-tasking
Procedure:
1.Copy the source code in the example and compile it.
2.Load the object file onto the target machine.
3.Run the example by executing the main routine (binary,etc.)of the example on WindSh
terminal.
Note: Make sure about redirected I/O,otherwise we won’t see the results of the printf commands.
49
CHAPTER 4
DP CONFIGURATION
DP CONFIGURATION:-
Steps of Installation:
1. Connect the hardlock to the parallel port. The hardlock tested periodically whole using the DP
Configurator.
2. Start the “setup.exe” program on the delivery disk with Program Manager by selecting the
menus “File” , “Execute” or with File Manager by simply double –clicking the file “setup.exe”.
3. Enter the destination drive and directory in the dialog presented to you. The directory will be
created if necessary.
4. The set-up program adds a program group “DP Configurator ” to the Program Manager or puts
entries into the group PROFIBUS of the start menu. Start the Configurator by (double)clicking
its icon in this group.
5. The delivery supplies the DDB files of the Softing master PROFIBUS controller cards and a
slave. To add your own DDB files(master or slaves), import them first with the menu “DDB”,
“Import” before opening a new or existing project.
6. For online configuration of remote master, the DP Configurator will look for the papi_l.dll.
This DLL is part of the PROFIBUS/DP DMK package and may not be part of the DP
Configurator. Enter the directory hosting this DLL either in your PATH environment variable or
copy the papi_l DLL to the application directory of the DP Configurator.
Configuration of DP Applications
In a PROFIBUS DP network, a DP Master (class1) controls and communicates with several
assigned slaves. The master needs a Master Parameter Set to start communications with the
slaves, to send parameterization data to slaves on request, to poll the assigned slave devices and
to prevent the I/O data in the communication area between a master application and the protocol
stack.
DP Master Parameter Set
A Master Parameter Set describes the network as seen by a single master. The parameter set
decides the bus peremeters and the configuration of all slaves assigned to this master. In multi-
master environment, every master has its own Master Parameter Set.
The Master Parameter Set consists of:
- one Bus Parameter Set
- max. 125 DP Slave Parameter Sets
50
Fig. 4.1:- DP Master Parameter Set
The DP Bus Parameter Set consists of the standard FDL operational parameters and some new
DP specific extentions.
DP Slave Parameter Sets
The DP Slave Parameter Sets are used to declare the features of each DP Slave and to define the
whole DP application. It is the most important data base for the user.
Fig. 4.2:- DP Slave Parameter Set
The Configurator has specific support for AAT-MODE “Compact”.
Features:
A single Master Parameter Set configuration is called a configuration project. Its data is
transferred to the DP master when starting up the master application.
The DP Configurator software offers the following features:
- Import third party provided device descriptions as DDB files (referred as GSD),
51
- Create and edit configuration projects by adding ,changing and deleting device for master
and slaves,
- Configure bus parameters,
- Configure compact and modular slaves including extended user parameters,
- Assign addresses to devices and slaves groups, change operation modes , edit watchdog
timeouts for slaves,
- Save a Parameter Set as binary file for later use by a master application(i.e. Softing DDE-
Server),
- Directly download the Master Parameter Set to a remote DP master (via PROFIBUS).
General Behavior:
The User Interface of the DP Configure behaves like a standard Windows MDI-
Application(Multiple Document Interface). The user has access to a menu, a toolbar and an area
where all child documents will be displayed.
Fig. 4.3:- Tool-Bar and Menus
Whenever a function is not applicationin the current context (e.g. Delete Slave when no slaves is
selected), the corresponding button is disabled.
Project
The Project menu presents all functions to create new projects and load previous projects and to
exit the DP Configurator. A project in this context is a configuration of a Master Parameter Set
for one master and all of its assigned slaves.
More on 12th
DDB
The Device DataBase (DDB) contains descriptions for master and slave devices available for
configuration projects. Add new device descriptions by importing standardized DDB files with
the menu “DDB”, “Import”.
Import
To change the device database , save close all projects first. Select the menu “DDB”, “Import”.
52
Fig. 4.4:- Database Import Dialogue
In order to remove a device from the database, select the device to be deleted and either double –
click the mouse or click the button Remove.
In order to import a device (its DDB file),click on the Add button. The following dialog appears:
Fig. 4.5:- Selecting Files for Import
Select drive and directory with the DDB files to import into the DP Configurator’s database.
Several DDB-files may be imported at once by marking them all and pressing ok.
The results of an import operation are logged into a file named gsd_pars.log in the database
directory. If a warning or an error appeared during the parsing of the files , a message box
informs about results being written into the logfile.
Change Database
A device is identified by its description file, which always has the name dp_konf.gls. By
choosing a different dp_konf.gls, the database is changed. The ini-file is not changed by this
function, so the list of projects in the Project-menu refer to a different database- this can cause
errors.
53
Download
This version supports two download methods: generation of a local configuration file and online
access with a remote download.
Remote Download transfers the current configuration data to a remote master(class1) with a
local master. This enables the remote master to access the configured slaves. Never download a
new configuration while the remote master is actively controlling any process.
Download to binary file transfers the current configuration in binary form to a MSDOS file.
This file may be downloaded by another DP master application, Softing’s DPDDE Seaver. The
configurator presents a dialog to select the desired path and name for the binary file. By default,
the dialog proposes the project path and filename,replacing the extension by “bin”.
Options
Basic Mode /Advanced Mode
PC Interface
Busparameter Master Class 2
Busparameter Template
Setting
Basic Mode /Advanced Mode:
In Advanced Mode , all bus parameters in master and slave are accessible. For a better protection
against unintentional change of critical parameters,the mode can be set to Basic Mode. In Basic
Mode , some parameters in the respective dialogs are disabled.
The current mode can be seen on the status-bar : BAS or ADV indicate
the current mode.
The operation mode can only be changed, when no project is open. To change the mode, close all
projects first.
PC Interface:
Select this menu to change the setting for the installed PROFIBUS DP controller hardware and
to set the bus parameters when the DP Configurator operates as master class 2.
54
Fig. 4.6:- Configuration of local PROFIBUS Interface
This dialog lets the user select one of the supported PROFIBUS controllers. Currently the
following controllers are supported:
- PROFIboard
- PROFIcard
Hardware Addresses (PROFIboard only, on 16 –Bit PAPI):
I/O Base Address Port I/O Address
The value given here must match the
setting of the I/O Base Address on the
PROFIBUS controller card
Than ensure that this address is not in
use by any other hardware device in
our system
Dual Ported RAM Address Hardware base address of 16 KB dual
ported RAM
The specified segment must be excluded from system usage (DOS and Windows)
Hardware Set-up Files (PROFIcard only , on 16 Bit-PAPI):
Loadcard INI Path and name of INI file with settings
of the installed PROFIcard.
This file is located in our CARDINST
directory.
Windows 95,98 may require, Window NT and 2K always require, that PROFIboard has to be
selected even if a PROFIcard is installed, depending on the installed drivers.
55
BUSparameter Master Class 2
Fig. 4.7:- Parameters for local master class 2
The Busparameter Master Class 2 dialog lets we edit the settings to use as master class2. the DP
Configurator uses the setting as configuration master to download to a remote master(master
class 1).
Than select an appropriate station address for master class 2 and the desired buadrate.
The pushbutton Edit.. brings up a dialog to edit bus communication parameters in detail. The
dialog resembles the one from “BUS PARAMETERS”, except that the entries Delta Ttr and
Watchdog/Ttr are constantly disabled.
Busparameter Template:
The template master defines station- and bus parameters to use when a master is added to a
project. The settings are saved in the application’s INI file.
Fig. 4.8:- Template Parameters
56
The first dialog defines the template station parameters. Enter the timings as ms ,or us
respectively.
Select a template buadrate and busparameters by activating the pushbutton “Edit
Busparameters..”. The dialog resembles the one from “Bus Parameters”, except that all entries
are enabled irrespective of the modes Basic/Advanced.
Settings:
Fig. 4.9:- Settings Dialog
The settings are saved into the ini-File and thus do not refer to a certain project, they are active
for all projects.
Strict HSA-Checking influences the functionality of Check Config and Auto Config with respect
to the HSA(Highest Station Address). If enabled, HSA is tested against / set to the highest
address of all stations, if disabled, it is tested / set to the highest master address.
Compatible CNF-Output assures that the file-output is compatible to earlier versions of the DP-
Configurator. Do not use this option unless necessary, as some data from several dialogs get lost
after closing the project.
Offset Inputs and Offset Outputs affect the address assignment table: DP-Configurator generates
address information for all inputs from Offset Inputs on, Offset Output is the start address of the
output page. The generated binary files can be used in AAT-Modes Array, Compact and IO-
Blocks. In AAT-Modes Array and IO-Blocks, the offset will be ignored by the master card! Do
not use the calculated offsets in an application except from AAT-Mode Compact.
View:
The menu “View” lets you show or hide the toolbar and the status bar.
Window:
The menu “Window” lets you arrange the project windows.
Project Window:
A project window hosts a single configuration project. The titlebar shows the file name of the
configuration file. The project window is split into two lists:
The lists to the left are the actual configuration project with the master and its associated
ant configured slaves.
The lists to the right presents us the imported master and slave device descriptions in the
device database as selection list.
57
Fig. 4.10:- Project Pane
First, pick a master for our project by selecting a master device description in the master
selection list with the mouse or with the tab and cursor keys. Either double click the line in the
list box or use the corresponding button from the toolbar or press <Enter>. The DP Configurator
presents a “DP Master Configuration” dialog.
Later on, the master’s parameters can be changed by selecting the actual master in configuration
list on the left of the project window. Either double click the line in the list box or box or use the
corresponding button from the toolbar.
Add a slave to our project by selecting and activating a slave device description in the
slave selection list. The DP Configurator presents a “DP Slave Configuration” dialog. Repeat
this step for every slave station in the project.
Change the parameters of a slave by activating the actual slave in the configuration list.
Delete a slave from the project by selecting the slave and then use the Cut-Button from
the toolbar.
Duplicate a slave in the project by selecting the slave and then use the Copy-Button from
the toolbar. Change the slave’s address immediately, as the copy is exact and duplicate addresses
are not allowed.
58
After these steps, a sample configuration could look as below:
Fig. 4.11:- Project pane with a master and three slaves in a project
Auto Config:
Consistent busparameters can be calculated with Auto Config. This button will change the major
master parameters and the watchdog interval of all the slaves. In basic mode, the watchdog
intervals will not be touched, thus, the calculated master parameter set might be inconsistent to
the slaves’ watchdog intervals. A warming will tell about the risk of using Auto Config in basic
mode.
Fig. 4.12:- Result of Auto-Configuration
The Cycle Time displayedgives a rough average for the data cycles to be expected. The upper
value includes a Gap-Update to a non-existent slave, the lower value gives an estimation of a
pure average data cycle.
Check Config:
Before finishing a project, the data should be checked for inconsistencies or possibly dangerous
configurations. A messagebox informs about the results. Use Check Config even after Auto
Config, as the tests are more comprehensive here.
59
Groups:
Fig. 4.13:- Association of slave to group
Groups gives an overview of the assignment of slaves to goups. This assignment can be changed
by editing the slave in the “Slave Configuration Dilog”; “Tab Setting”. Each slave in the project
has two markers, indicating whether Sync(‘S’) or Freeze(‘F’) are activated. If the corresponding
feature is not activated, this is noted by an ‘n’.
Usually , one Group should be consistent(i.e. all slaves support the same features within one
group.)
60
DP Master Configuration Dialog:
Fig. 4.14:- Master Parameters
This dialog is divided into three frames:
The info frame displays the vendor information of the DP Master device: vendor name, device
name, device revision and ident number.
The parameters frame:
Station Address Enter the master’s station address in a range of 0 to 126. The
dialog proposes a default address 1.
Min. Slave Interval This time gives a lower bound for the DP-cycles and should be as
small as possible, but no smaller than the slowest slave allows.
Poll Timeout Timeout for Master-Master operations. The dialog suggests the
Min_Poll_Timeout value declared in the master DDB.
Data Control Time Timeout for data update for all slaves.
Autoclear Enables fallback from operation mode ‘operate’ to ‘clear’, if
timeout ‘Data Control Time’ is violated by atleast one slave.
61
Bus Parameters:
Fig. 4.15:- Net Parameters
When selecting a baudrate, the values in the edit fields for the bus parameters are updated to
present a reasonable default set. All timing values are in multiples of the bit time tbit, except
Watchdog/Ttr, which is in Percent.
In basic configuration mode, some fields are disabled and cannot be edited.
Delta Ttr represents the time needed for further PROFIBUS-Masters, e.g. if online configuration
with a DP-Master Class 2 is used, Delta Ttr has to be non-zero.
Slave Configuration Dialog:
This dialog consists of four property sheets which are accessible vai the tabs below the dialog’s
toolbar.
For modular slaves, the user must configure atleast one slot to successfully complete this dialog.
62
Tab: Basic
Fig. 4.16:- Basic Slave Parameters
The first field in the subdialog Basic displays the general slave descriptions as supplied by the
slave vendor: vendor name, device name, ident number, revision.
The second field sums up the slave’s I/O-length over all modules and either displays the name of
the first virtual module in a compact slave or identifies a slave as Modular Slave.
In the third field, the user provides:
Station Address Either the slave’s station address in a range of 0 to 126
The dialog proposes the next free station address.
Active If this checkbox is not marked, the slave is inactive, i.e. the station is not
included in the update cycle when the master starts running in mode
Clear/Operate
63
Tab: Modules
Fig. 4.17:- Selecting Modules
In a compact slave, the buttons Add & Remove are deactivated, the configuration cannot be
changed. The (virtual) modules in the DDB-File are automatically configured in the list of slots.
In a modular slave, the user has to define the configuration for every slot of the slave. Atleast one
slot has to be added to the list of slots. The already defined slots are displayed in the current slots
list, the available modules are displayed in the list on the left side.
Configure a slot by activating a module in the list of available modules. To put an instance of the
module to the list of active slots, either click on the Add button, or double click the module. The
module’s instance will be added at the end of the list of active slots. If a slot is activated before
configuring a new slot, any new slot will be inserted into the list right before the activated slot.
Delete a slot either by selecting the slot in the slot list and then click Remove or double click the
slot in the slot list.
The DP Configurator displays the maximal number of available slots and the number of already
defined slots.
The texts in the lists will appear exactly as defined in the DDB file! No assumptions are made
about the format and language of these texts, since the texts are vendor provided.
64
Tab: Settings
Fig. 4.18:- Advanced set-up of a slave
The subdialog Settings lets the user supply more detailed slave configuration data.
In the first frame Operation Mode, the user provides:
Min. Station Delay Responder The value states the station delay time (slave internal
processing time) of this station. This time is declared in the
slave DDB as min TSDR
Sync Req. Freeze Req If the slave supports synchronize and freeze requests, these
checkboxes are enabled. Check the boxes to activate the
requests.
Fail Save If the slave supports Sail-Save (data transfer of telegrams
with no data instead of telegrams with zeros in operation
mode clear), this checkbox is enabled. Check the box to
activate Fail-Save-Support in Master and Slave.
If the slave requires Fail-Save operation, the box is marked
and disabled, so operation without Fail-Save is not
possible.
Watchdog Time If the slave supports its own watchdog timer, this check
box timer is enabled. Check the box and edit a timeout to
activate the watchdog.
This watchdog fires if the slave will not be polled by the
master before the timeout expires. The slave will clear all
outputs when the watchdog fires.
65
In the second frame Groups, the user defines the slave’s association to any of up to eight groups.
An overview of all slaves in all eight groups can be accessed from the project window by
activating the “Groups” pushbutton.
In the third frame User Prm Data, the User Parameter Data can be entered. By default the DDB
data are shown and can be modified.
Tab:Extended:
Fig. 4.19:- Extended User Parameters
Extended user parameters allow a symbolic manipulation of user parameters. The tab Extended
is enabled if the DDB-File contains the necessary information.
Extended user parameters are set for each module. By activating one module in the list of
available slots, the list of available parameters is initialized. By activating one entry in the list of
user parameters, the current value of this parameter is displayed. Select a symbolic value or enter
a number within the numeric range. The list of available slots also contains additionally a virtual
slot Device Data. Usually, its parameters refer to the whole slave.
Changes done in this dialog can be monitored in the dialog Setting, too. This redundant way of
changing user parameters is necessary as not all slaves have DDB-Files with symbolic
representation of user parameters.
Automatic Import of Slaves:
Users who have a tool which generates XPT-Output, can automatically integrate complete
projects.
Invoking the automatic import of Slaves:
The Edit Menu has an additional entry “Import Slaves”.
66
Fig. 4.20:- Edit menu with new import “import slaves”
The DP-Configurator asks for an XPT-File, which has tocontain a master description and one or
more slave descriptions. The master’s address has to match the address of the master in the
current project. The slaves found in the file replace the slaves of the current project.
Errors during import:
Whenever an error is detected, a message box tells about the fact, that the import was
incomplete.
Fig. 4.21:- Error message when importing slave
The database directory contains a file named xpt_parts.log, which is non empty in case an error
is detected. The following major error conditions are tested sequentially.
Error Behaviour
Illegal Syntax of the XPT-File, e.g. missing
keyword or missing separator
The import is cancelled, the current project
is not touched.
Master Address in the XPT-File does not
match the address configured
The import is cancelled, the current project
is not touched.
The requested GSD-File was not found in
the database
The slave is not configured into the project.
The requested slave contains modules,
which are not in the GSD-File
The slave is not configured into the project.
Whenever a syntax error is detected, the logging file contains the keyword, which came
unexpected, and the line, where the error was found. A missing keyword is therefore indicated as
67
an unexpected keyword, e.g., if the keyword ENDSLAVE is missing, the following
BEGINSLAVE is marked as unexpected.
Project description of DP configuration:-
DP configuration of VME interface card as master and 1 slave CBP2 Module
DP Master Configuration:
This is done by using SOFTING software. The steps are as follow:
DPConfigurator → Project → New Project
clicking on New Project, the above window will be shown. From Master Selection List, select
PROFIboard/PROFI104(Softing GmbH). So, another window will be shown as follows.
By default, the Station Address is “1”. Here, we will change it to “2” because VME system is
already having a master SBSVG4.
We can change only the Station Address. The other parameters (Min. Slave Interval, Poll
Timeout & Data Control Time) can’t be changed from their default values.
In Busparameters, we select the Baudrate 1.5 MBaud, which will be expanded up to 12MBaud.
68
Fig. 4.22:- Master configuration window
DP Slave Configuration:
From Slave selection list, click on MASTERDRIVES CBPx (Siemens AG A&D).
Fig. 4.23:- Slave configuration window
Select the Station Address as “3’”. Then click on Modules. Following window will be generated.
Here, we’ll select 4 parameters & 2 processes.
(PPO 1: 4 PKW | 2 PZD)
69
Then click on Settings. The following window will be displayed.
GSD File:
This document describes the definition of the GSD file format for DP. In order to achieve a
simple plug & play configuration for PROFIBUS , electronic device datasheets (GSD files) are
defined for communication features of the devices. These GSD files are a Human readable
ASCII text files. Keywords are specified as mandatory or optional with the corresponding data-
type and their border values to support the configuration of PROFIBUS devices.
Based on the defined file format it is possible to realize vender independent configuration tool
for PROFIBUS systems. The configuration uses GSD files for testing the data. These were
entered regarding limits and validity related to the performance of the individual device.
The manufacturer of a device is responsible for the functionality and the quality of its GSD file.
The device certification procedure is requesting either a standard GSD file based on a
PROFIBUS profile or a device specific GSD file.
For different slaves, there are different GSD files. If the GSD file is not provided for a slave, we
can also create its GSD file by providing details in Slave Configuration → User Prm Data.
70
GSD file of CBP2 Module:
; (c) 1997 Siemens AG ASI 1
;
; Profibus-DP Geraetestammdatei für MASTERDRIVES Baugruppen CBP und CBP2
; MLFB: CBP = 6SE7090-0xx84-0FF0 ; CBP2 = 6SE7090-0xx84-0FF5
;
; Autor: Heinz Kerpen ( H.K. )
; Erstellungsdatum: 13.03.97
; Aenderungen: H.K. 22.05.97 S7-Typkennung fuer Slot 5 von 0x23 auf 0xA3
; H.K. 06.06.97 Min-Slave-Intervall=1,3 ms
; S7-Typkennungen -> Kennungsbytes , Bitmap-Device
; H.K. 01.07.97 Abgleich GSD-Datei mit Typdateien ( V 1.0 )
; H.K. 29.10.97 Min_Slave_Int. von 13-->5 / User_Prm_Data_Len = 0 /
; d.h. Abgleich mit SSC-Vorschlägen
; H.K. 30.10.97 Slave_Family=1@TdF@SIMOVERT
; Revision 1.1: H.K. 14.08.98 24V_Pins=0 ( vorher=2 ) ; Software V1.2
; Revision 1.2: H.K. 29.01.99 Bitmap_Device von = "asi8022" erweitert zu = "asi8022n"
; Max_Module = 1 ; Baudrate 45.45 kBaud
; Revision 2.0: H.K. 13.08.99 Vendor_Name ; HW-Release = V2.0 ; SW-Release = V2.0
; Implementation_Type = "SPC 3" --> "DPC31(SPC3)"
; OrderNumber="6SE7090-0xx84-0FF5(0FF0)"
; Abgleich mit SSC-Vorschlägen bzgl. CBP2
; H.K. 30.10.00 Namensänderung von "MASTERDRIVES CBP" zu
"MASTERDRIVES CBPx"
;
;====================================================================
====================
;
;--- Allgemeine Angaben: ---
;
#Profibus_DP
;
Vendor_Name = "Siemens AG A&D "
Model_Name = "MASTERDRIVES CBPx"
Revision = "V2.0"
Ident_Number = 0x8045
Protocol_Ident = 0
Station_Type = 0
FMS_supp = 0
Hardware_Release = "V2.0"
Software_Release = "V2.0"
;
9.6_supp = 1
19.2_supp = 1
45.45_supp = 1
93.75_supp = 1
187.5_supp = 1
500_supp = 1
71
1.5M_supp = 1
3M_supp = 1
6M_supp = 1
12M_supp = 1
;
MaxTsdr_9.6 = 60
MaxTsdr_19.2 = 60
MaxTsdr_45.45 = 250
MaxTsdr_93.75 = 60
MaxTsdr_187.5 = 60
MaxTsdr_500 = 100
MaxTsdr_1.5M = 150
MaxTsdr_3M = 250
MaxTsdr_6M = 450
MaxTsdr_12M = 800
;
Redundancy = 0
Repeater_Ctrl_Sig = 2
24V_Pins = 0
Implementation_Type = "DPC31(SPC3)"
Bitmap_Device = "asi8022n"
;
;--- Slave spezifische Werte ---
;
OrderNumber="6SE7090-0xx84-0FF0/0FF5"
;
Freeze_Mode_supp = 1
Sync_Mode_supp = 1
Auto_Baud_supp = 1
Set_Slave_Add_supp = 0
Min_Slave_Intervall = 5
;
Modular_Station = 1
Max_Module = 1
Max_Input_Len = 28
Max_Output_Len = 28
Max_Data_Len = 56
Modul_Offset = 0
Max_User_Prm_Data_Len = 0
User_Prm_Data_Len = 0
;
Fail_Safe = 1
Slave_Family = 1@TdF@SIMOVERT
Max_Diag_Data_Len = 17
;
;
Module = "PPO 1: 4 PKW | 2 PZD " 0xF3, 0xF1
EndModule
72
Module = "PPO 2: 4 PKW | 4 + 2 PZD " 0xF3, 0xF3, 0xF1
EndModule
Module = "PPO 3: 0 PKW | 2 PZD " 0x00, 0xF1
EndModule
Module = "PPO 4: 0 PKW | 6 PZD " 0x00, 0xF5
EndModule
Module = "PPO 5: 4 PKW | 4 + 4 + 2 PZD" 0xF3, 0xF3, 0xF3, 0xF1
EndModule
Module = "___________options____________" 0x00
EndModule
Module = "PPO 2: 4 PKW | 6 PZD " 0xF3, 0xF5
EndModule
Module = "PPO 5: 4 PKW | 10 PZD " 0xF3, 0xF9
EndModule
;
After completing the Master & Slave Configuration Process, we will be shown this window.
After completion of Master Slave Configuration, we write Controls,ON/OFF & Iref from Master
to Slave and read the Status (healthy or not) & Iactual-value from Slave.
73
Compile Binary File into VME default directory:
First of all, create a binary file named GECG28.BIN using following steps.
DPConfigurator → Download → Binary File → C:\ → PROGRA~1 → profibus → DP_KONF
→ GECG28.BIN
Fig. 4.24:- Compile binary file
74
CHAPTER 5
PROFIBUS & PROFIBUS VME INTERFACE CARD
5.1 PROFIBUS
PROCESS FIELD BUS (PROFIBUS) is an open, digital communication system. PROFIBUS is
the uniform, open automation technology for all fields of application, both in manufacturing
automation & in process automation. It provides a standardized automation technology for the
whole system.
PROFIBUS works as a communication link between master & slave devices in Master/Slave
architecture systems for very fast communication. The data transfer rate vary from 9.6 kbits/s to
12 Mbits/s depending upon the distance between two devices.
Over PROFIBUS, devices and systems communicate horizontally via standardized information
channels throughout the entire field level from the upstream area through the mainstream area to
the downstream area. PROFIBUS thus provides a standardized automation technology for the
entire system.
Apart from the system-wide transparency, there is a desire for standardization for different
applications and requirements. PROFIBUS is the uniform, open automation technology for all
fields of application, both in manufacturing automation & in process automation.
The modular PROFIBUS system reflects the entire range of PROFIBUS technology. It contains
specifications of technologies that are required for a complete description of communication
between network devices.
The specifications are arranged by function, thus allowing a modular structure of the PROFIBUS
system according to different technology areas. Combination of modules from different
technology areas permits the definition of an optimal communication solution for any
application.
The communication technology contains specifications that describe the physical/electrical and
optical properties of the device interfaces and the network. They include features like
communication medium, network topology, connection technology, signal characteristics, and
transfer rate.
Depending on the application, the possible device interfaces are RS 485, MBP, and fiber-optic
cables, as well as the intrinsically safe variants, RS 485-IS and MBP-IS. A combination of these
device interfaces is also feasible.
75
The communication technology contains specifications that describe the data structure and the
data exchange between the network devices, i.e. the communication mechanisms. There is the
only one PROFIBUS protocol, that is, Protocol DP (Decentralized Periphery) in stages DP-V0 to
DP-V2.
For closed-loop control tasks PROFIBUS uses purely cyclic data communication. This protocol
stage is referred to as DP-V0. If commissioning and monitoring functions have to be executed as
well, device data must be transferred acyclically. This functional extension is called DP-V1.
Other services provided by DP-V2 include time synchronization and time stamping.
If there is only one master, a PLC for closed-loop control tasks for example, the bus is accessed
cyclically using the master/slave procedure. In this case, the master is termed a Class 1 master.
Communication is controlled exclusively by the master. The network devices are passive and
may only become active, i.e. send data, if they have first been requested to do so by the master.
If there are several masters in a network, e.g. a PLC and a computer for device configuration, bus
access takes place by means of the token passing procedure. Within a defined time frame, each
master receives the bus access authorization, or token, which entitles it to control communication
during that time.
76
Fig. 5.1:- Token procedure in PROFIBUS
Application profiles are general specification that describe the properties, performance
capability, and behavior, no matter what make of device. A profile allows application-oriented
interaction of different makes of devices in a PROFIBUS network.
General application profiles describe functions and properties with cross-applicational
significance. They can be used in conjunction with the specific application profiles. General
application profiles are available for PROFIsafe, Time Stamp, Redundancy, and HART on
PROFIBUS.
77
The modular PROFIBUS system technology permits the definition of customized solutions
tailored to the application. For this purpose, modules are selected from various technology areas
and combined with one another.
Transmission Technology used for PROFIBUS
PROFIBUS can communicate via scheduled two-wire cables or fiber-optic cables. RS 485
transmits via a two-wire cable and is mainly used in factory settings. In the case of Manchester
coded Bus Powered (MBP) systems, power is also supplied to the field devices via a two-wire
line. Therefore, MBP is suitable for the explosion-protected zones in process automation.
Transmission via fiber-optic cables ensures electrical isolation, bridges long distances, and is
immune to EMC interference. Subnets comprised of RS 485 and MBP are connected with one
78
another in order to transmit data from the potentially explosive zone to the master device (CPU)
in the safe zone.
Closed circuit communication in accordance with the EIA RS 485 standard is defined as the
communication technology for PROFIBUS DP. It uses a shielded two-wire copper cable. In
environments subject to heavy interference and to increase the range, glass or plastic fiber-optic
cables are used.
Data transmission takes place byte by byte. The RS 485 interface adds one start bit, one stop bit,
and one parity bit to each information byte. This means that for each information byte comprised
of 8 bits, 11 bits are transferred over the cable. The frames thus have a high level of protection
against transmission errors.
In the case of RS 485-IS, power is supplied to the PROFIBUS devices via separate cable due to
the typically higher power demand.
For PROFIBUS PA, available communication technologies are MBP and the IS variants MBP-IS
and RS 485-IS in potentially explosive atmosphere. PROFIBUS PA networks are always linked
via DP-PA couplers to a PROFIBUS DP network.
Fiber Optic Transmission
An optical PROFIBUS network can be comprised of devices with an integrated optical interface
that are connected to one another in a line topology. Devices without an integrated optical
interface can be connected with their RS 485 interface via an Optical Bus Terminal (OBT).
Optical Link Modules (OLMs) have an isolated electrical channel and, depending on the type,
one or two optical channels. A single device or a complete PROFIBUS segment can be
connected to the RS 485 interface. Terminals with an integrated interface can be connected
directly to the optical interfaces. Terminals with an RS 485 interface are connected via an OBT
or OLM.
Transmission Rate
With RS 485, the transfer rate, which can be adjusted in increments of 9.6 kbits/s up to a
maximum of 12 Mbits/s, is dependent on the maximum length of the largest segment and the
physical properties of the weakest device in the PROFIBUS configuration.
79
MBP uses a fixed transmission rate of 31.25 kbits/s. Unlike RS 485, different transmission rates
are not possible with MBP.
Fiber-optic cables always cover the entire range of transmission rates that can be set for RS 485.
However, the physical properties of each of the active optical components have to be taken into
consideration.
The maximum network length is achieved by the concentration of segments of maximum length.
The number of segments depends on the type of repeater. With standard repeater (RS 485), up to
3 can be connected in series, while in the case of repeaters with signal refresh, up to 9 can be
connected in series.
Field Devices
In addition to the field devices themselves, the field components of a PROFIBUS system include
components like distribution boxes, cables, connectors, and terminators. Furthermore, other
components are used for the configuration of a field bus system, e.g. segment coupler, remote
I/O systems, overvoltage protection, barriers, and repeaters.
Protocol Architecture
PROFIBUS protocol architecture is based on the ISO/OSI reference model, standardized
internationally for communication tasks. The 7 layers define appropriate services and execution
rules for communication between two applications. There are user-oriented layers and network-
oriented layers.
Fig. 5.2:- OSI level of PROFIBUS
With PROFIBUS DP, Layer 7 is not characterized either. With this lean architecture, data
communication is extremely efficient and fast. For the user interface of PROFIBUS DP, the
direct access to the functions of layer 2 is implemented by the Direct Data Link Mapper
(DDLM).
80
Fig. 5.3:- PROFIBUS DP
PROFIBUS DP
PROFIBUS DP is an optimized-speed protocol, specially designed for low-cost communication
between a DP master and DP devices, i.e., the DP slaves. These include field equipment such as
sensors, actuators, measuring transducers, drives, and field multiplexers.
The performance capability of PROFIBUS DP comes into its own especially in mono-master
systems with unlimited bus access. The centralized control device requires a bus cycle time (that
is, the period of time in which all the slaves are polled once), which is shorter than the internal
processing time of the controller.
In the case of multi-master systems, the centralized control devices have to share bus access.
This often results in higher demands in terms of transfer rate (cost) or smaller data quantities
(performance) in order to guarantee the required bus cyclic time.
Prior to commencement of cyclic data transfer, initialization takes place between the DP master
and a DP slave. A check is performed in order to establish whether the set configuration agrees
with the actual device configuration, e.g. device type, format and length information, number of
inputs and outputs, etc.
In the first step, the DP master sends a diagnosis request to the DP slave. The diagnostic
response contains the station status, the PROFIBUS address of the DP master by which the slave
was parameterized, the manufacturer’s identifier, and device-specific diagnosis data.
81
If the result of slave diagnosis indicates that the DP slave has to be parameterized and
configured, the procedure continues with the parameter frame, which is acknowledged by the DP
slave.
After parameterization, the DP master has to send the set configuration to the DP slave. If the DP
slave discovers a deviation from its actual configuration, it generates appropriate diagnosis data
and is then not available for user data communication.
The result of the configuration test is polled by the DP master via a repeat diagnosis request
before it commences cyclic data communication with the DP slave.
In regular operation, cyclic data exchange takes place between the DP master and the DP slave.
With the SRD service (Send and Request Data), up to 244 bytes of output data and up to 244
bytes of input data can be exchanged in one frame.
Application Profile
Application Profile describes functions and properties with cross-applicational significance. The
“PROFIsafe” profile defines how safety-oriented devices, e.g. emergency OFF switches,
communicate with safety controls via PROFIBUS such that they can be used in safety-oriented
automation tasks up to CAT 4.
82
the “HART on PROFIBUS DP” profile makes it possible to integrate HART devices into
PROFIBUS systems by mapping the client-master server model of HART on PROFIBUS.
When recording timed sequences in networks and especially with functions like diagnosis and
troubleshooting, it is useful to provide certain events and actions with a time stamp. That makes
it possible to attribute activities to exact times. It is controlled in the “time stamping” profile.
PROFIBUS
Fig. 5.4:- PROFIBUS cable image
83
5.2 PROFIBUS VME INTERFACE CARD
VME interface card (V6PFB)
PEP’s V6PFB provides dual independent PROFIBUS FMS and DP communication up to
12 Mbaud.
The PROFIBUS protocol FMS is well suited for general purpose communication tasks at cell or
field level while DP is designed for time-critical communication between
systems and distributed peripherals.
The heart of the V6PFB comprises a powerful microcontroller, the MC68360 and two ASPC-2
PROFIBUS controllers, which provides high speed (up to 12 MBaud) PROFIBUS interfaces for
FMS master and slave and DP master (class 1 and class 2) protocols.
The ASPC-2s are responsible for the DP communication and the microcontroller handles the
remaining protocol stack functions - especially in FMS mode. The intelligent integration of
PROFIBUS within OS-9, VxWorks or other operating systems allows easy ‘C’ language
programming of PROFIBUS applications.
The standard RS485 interfaces offer direct connection to PROFIBUS FMS and DP networks, or
via segment couplers to the intrinsically safe PROFIBUS PA net.
Fig. 5.5:- Actual image of VME interface card
84
Functional Block Diagram of V6PFB
Fig. 5.6:- Functional block diagram of V6PFB
Technical Specifications
V6PFB Technical Specifications
Form Factor 6 U
Special functions Programmable FAIL/RUN LEDs;
Serial EEPROM (2kbit) for board/application-
specific data;
Programmable local reset (3)
Connectors Two 9-pin DSUB fieldbus connector (female)
LEDs Two PROFIBUS activity LEDs (yellow);
Two board failure LEDs (red)
CPU MC68360 25MHz
85
Memory
DRAM
FLASH
DPRAM (VME)
EEPROM
1 Mbyte, 32 bit access
2 Mbyte, 32 bit access
256 kByte, dual-ported, 16 bit
2 kbit (serial)
Power Consumption Typically 5.5 W (5V/1.1A)
Temperature Range
Standard
Extended
Storage
0ºC - 70ºC
-40ºC - 85ºC
-55ºC - 85ºC
Weight 300g
PROFIBUS Interface System Clock 48 MHz
Controller:
- Baud rate
- Interface
- Number of
Participants
- Address Range
Two controllers of
“ASPC2” type:
9.6 kBaud – 12 Mbaud,
software-programmable
8/16 bit
127, mixed
active/passive
1 Mbyte each
64 byte internal FIFO for
send and receive each
PROFIBUS
Interface
Two optoisolated 12-
Mbaud RS-485
interfaces
DPRAM Two 256 kByte local
dual-ported DPRAM
devices, 32-bit
Backplane
Connector
One 96-pin connector
according to DIN 41612
having VMEbus slave
functionality
Type of
Configuration
space
Jumper selectable base
address, 4 Kbyte size,
AM-Codes 2D/29
Type of Memory
space
A24/D16, programmable
base address
Size 1 MByte
Address Modifier - A24/D16 supervisory
program/data (3E/3D)
- A24/D16
supervisory/non-
priviledged program/data
(3E/3D/3A/39)
- A24/D16 user-defined
(1F - 18)
- A24/D16 user-defined
86
(17 - 10)
VME Interrupt 2* Mailbox Out,
programmable vector
base, level2. Pending
IRQ readable from local
side
Local Interrupt 2* Mailbox In, local
autovectored requests,
level 5 and 4. Pending
IRQ readable from VME
side
Table 5.1:- Technical specifications of V6PFB
V6PFB Front Panel
Two LEDs are positioned on the VFPB front panel having the following signalling function:
• Yellow ON: PROFIBUS interface transmit data;
• Red ON: board failure.
The board failure LED is controlled by the VMEbus interface.
Board Interface
VMEbus Connector
A 3-row by 32-pin connector according to VME standard enables data exchange between the
V6PFB slave interface and the system’s main control unit.
PROFIBUS Connector
Two 9-pin DSUB connectors enable data exchange of the V6PFB via two PROFIBUS RS485
fieldbus communication lines/network accesses providing RxD and TxD lines. The RTS signals
are used to enable transmitter operation.
87
V6PFB Board Overview
Fig. 5.7:- V6PFB board overview
V6PFB jumper setting of base address
J24 J25 J26 J23 Description
Close Close Close Close HEX 0000
Close Close Close Open HEX 1000
Close Close Open Close HEX 2000
Close Close Open Open HEX 3000
Close Open Close Close HEX 4000
Close Open Close Open HEX 5000
Close Open Open Close HEX 6000
Close Open Open Open HEX 7000
88
Open Close Close Close HEX 8000
Open Close Close Open HEX 9000
Open Close Open Close HEX A000
Open Close Open Open HEX B000
Open Open Close Close HEX C000
Open Open Close Open HEX D000
Open Open Open Close HEX E000
Open Open Open Open HEX F000
Table 5.2:- V6PFB jumper setting of base address
Project description
By setting jumper 23 Close,24 Open,25 Close and 26 Open we get the base address for V6PFB is
0xFCFEA000.
Then inserted V6PFB in VME rack and check the fail LED status by sending command signal.
VME Board Control Register
Address: 0xFCFEA000 + HEX 85 = 0xFCFEA085
Access: Read and write
Value after reset: HEX 00
On memory address 0xFCFEA085, writing 0xff09, the FAIL LED-1 glows. By this, we
understood that we’re communicating with inserted V6PFB board.
91
FUNCTION TERMINAL
X174
CONNECTION VALUES /
REMARKS
Reference M
P10
N10
1
2
3
±1% at 25 ºC; 10 mA short-circuit
proof
Select Input Main Setpoint+
Main Setpoint-
4
5
Input type parameterizable:
- Differential input ±10V; 150kΩ
Select Input Analog 1+
Analog 1-
6
7
- Current input 0-20 mA; 300Ω or
4-20 mA; 300Ω
Table 6.1:- Pin functions of CUD1
Binary Control Inputs
93
Control Unit / Direct Current (CUD1)
Electronics board C98043-A7001 of SIMOREG DC-MASTER (Analog Outputs)
LBA(Local Bus Adapter):
Local Bus Adapter for the electronics box LBA is always needed to install supplementary
boards.
LBA for mounting supplementary boards
Optional supplementary boards can be installed only in conjunction with the LBA option. If an
LBA is not already fitted in the SIMOREG converter, one must be installed in the electronics
box to accommodate the optional board.
How to intall an LBA local bus adaptor in the electronics box
→ undo the two fixing screw on the CUD1 board and pull board out by special handles.
→ push LBA bue extension into electronics box until it engages.
→ insert CUD1 board in left-hand board location again and tight fixing screw in handles.
94
Mounting of optional supplementary board
Supplementary boards are inserted in the slots of the electronics box. Optional LBA is required
to fit supplementary boards. The designations of the board locations or slots are shown in the
adjacent diagram.
CUD1
local bus adapter (LBA)
T400 Adapter board(ADB)
Modular and expandable
95
Adapter Board (ABD)
ADB is always needed to install CBC, CBP, EB1, EB2, SBP and SLB boards.
SIMOLINK board (SLB)
Sequence of operation for starting up PROFIBUS boards (CBP2):
1. Switch off the power supply and insert the board or adapter with board.
2. The following are important communication parameters. Index 1 of each parameter is set
for the 1st communication board (1
st CB) and index 2 for the 2
nd CB:
- U712 PPO type, definition of the number of words in the parameter and process data
selection of the telegram (required only if the PPO type cannot be set via
PROFIBUS-DP master)
- U722 Telegram failure time for process data (0 = deactivated)
The DP master configuring data determine whether the slave (CBP2) must
monitor telegram traffic with the master. If this monitoring function is activated,
the DP master passes a time value (watchdog time) to the slave when the link is
set up. If no data are exchanged within this period, the slave terminates the
process data exchange with the SIMOREG converter. The latter can monitor the
process data as a function of U722 and activate fault message F082.
- P918 Bus address
- P927 Parameterization enabe (need only be set if parameters are to be assigned via
PROFIBUS)
- The process data of the 1st or 2
nd CB are connected by means of the appropriate
connectors and binectors. 3. Turn the electronics supply voltage off and on again or set U710.001 or U710.002 to “0”
to transfer the values of parameters U712, U722 and P918 to the supplementary board.
The CBP2 serves to link drives and higher-level automation systems via the PROFIBUS-DP. For
the purpose of PROFIBUS, it is necessary to distinguish between master and slave converters.
Masters control the data traffic via the bus and are also referred to as active nodes. There
are two classes of master:
DP master of class 1(DPM1) are central stations which exchange data with slaves in
predefined message cycles.
DPM1 support both a cyclic channel and an acyclic channel.
96
DP masters of class 2(DPM2) are programming, configuring or operator
control/visualization devices (e.g. Drive monitor) which are used in operation to
configure, start up or monitor the installation.
DPM2s support only an acyclic channel for transferring parameter data.
The contents of the data frames transferred via these channels are identical to the
structure of the parameter section (PKW) as defined by the USS specification.
The following diagram shows the services and channels supported by a CBP2:
slaves (e.g. CBP2) may only respond to received messages and are referred to as passive
nodes.
PROFIBUS combines high baud rates (to RS485 standard) with simple, low-cost installation.
The PROFIBUS baud rate can be selected within a range of 9.6 kbaud to 12 Mbaud and is set for
all devices connected to the bus when the bus system is started up.
The bus is accessed according to the token-passing method, i.e. permission to transmit for
defined time window is granted to the active stations (masters) in a “logical ring”. The master
can communicate with other masters, or with slaves in a subordinate master-slave process, within
this time window.
PROFIBUS-DP predominantly utilizes the master-slave method and data is exchanged cyclically
with the drives in most cases.
The user data structure for the cyclic channel MSCY_C1 is referred to as a Parameter
Process(data) Object (PPO) in the PROFIBUS profile for variable-speed drives. This channel is
also frequently referred to as the STANDARD channel.
The user data structure is divided into two different sections which can be transferred in each
telegram:
PZD section
The process data (PZD) section contains control words, setpoints, status words and actual
values.
PKW section
97
The parameter section (PKW – Parameter ID Value) is used to read and write parameter
values.
When the bus system is started up, the type of PPO used by the PROFIBUS master to address the
drive is selected. The type of PPO selected depends on what functions the drive has to perform in
the automation network.
Process data are always transferred and processed as priority data in the drive.
Process data are “wired up” by means of connectors of the basic unit (drive) or via technology
board parameters, if these are configured.
Parameter data allow all parameters of the drive to be accessed, allowing parameter values,
diagnostic quantities, fault messages, etc. to be called by a higher-level system without impairing
the performance of the PZD transmission.
A total of five PPO types are defined:
the acyclic channel MSCY_C2 is used exclusively for the start-up and servicing of
DriveMonitor.
Mechanisms for processing parameters via the PROFIBUS:
The PKW mechanism (with PPO 1,2 and 5 and for the two acyclic channels MSAC_C1 and
MSAC_C2) can be used to read and write parameters. A parameter request job is sent to the
drive for this purpose. When the job has been executed, the drive sends back a response. Until it
receives the response, the master must not issue any new requests, i.e. any job with different
contents, but must repeat the old job.
The parameter section in the telegram always contains at least 4 words:
98
The parameter identifier PKE contains the number of the relevant parameter and an identifier
which determines the action to be taken (e.g. “read value”).
The index IND contains the number of the relevant index value (equals 0 in the case of
nonindexed parameters). The IND structure differs depending on the communication mode:
- Definition in the PPOs (structure of IND with cyclical communication via PPOs)
- Definition for acyclical channels MSAC_C1 and MSAC_C2 (structure of IND with
acyclical communication)
The array subindex (referred to simply as “subindex” in the PROFIBUS profile) is an 8-bit value
which is transferred in the high-order bytes (bits 8 to 15) of the IND when data are transferred
cyclically via PPOs. The low-order byte (bits 0 to 7) is not defined in the DVA profile.the low-
order byte of the index word is used in the PPO of CBP2 to select the correct number range (bit7
= Page Select bit) in the case of parameter numbers of > 1999.
In the case of acyclical data traffic (MSAC_C1 , MSAC_C2) the number of the index is
transferred in the low-order byte (bits 0 to 7). Bit 15 in the high-order byte is used as the Page
Select bit. This assignment complis with the USS specification.
Index value 255 (request applies to all index values) is meaningful only for acyclical
transmission via MSAC_C1. the maximum data block length is 206 bytes with this transmission
mode.
The parameter value PWE is always transferred as double word (32-bit value) PWE1 and PWE2.
The high-order word is entered as PWE1 and low-order word as PWE2. in the case of 16-bit
values, PWE1 must be set to 0 by the master.
Rules for job/response processing:
A job or response can only ever refer to one parameter.
The master must send the job repeatedly until it receives an appropriate response from the
slave. The master recognizes the response to the job it has sent by analyzing the response
identifier, the parameter number, the parameter index and the parameter value.
The complete job must be sent in one telegram. The same applies to the response.
The actual values in repeats of response telegrams are always up-to-date values.
If no information needs to be fetched via the PKW interface (but only PZD) in cyclic
operation, then a “No job” job must be issued.
PROFIBUS devices have a variety of difference performance features. In order to ensure that all
master systems can correctly address each supplementary board, the characteristic features of
each board are stored in a separate device master files (GSD).
We need file <siem8045.gsd> for CBP2.
The appropriate file can be chosen in the selection menu for the SIMOVERT MASTER DRIVES
files in later versions of the configuring tool.
The communication boards can only be operated on a non-Siemens master as a DP standard
slave, the corresponding GSD file containing all necessary information for this mode.
99
Diagnostic tools:
LED displays of CBP2 (flashing LEDs means normal operation):
Red LED Status of CBP2
Yellow LED Communication between SIMOREG and CBP2
Green LED Communication between CBP2 and PROFIBUS
Fig. 6.3:- LED status of CBP2
6.2 DRIVE MONITOR
6.2.1 DRIVE MONITOR OVERVIEW
DriveMonitor is the start-up tool of Drive ES for drives belonging to the following families.
MICROMASTER
MASTERDRIVES
SIMOVERT
SIMOREG
Brief overview of the functions of DriveMon:
Parameterizing drives
Drive diagnostics
Entering setpoints
100
Operating modes
Drive converters can be parameterized both online and offline using DriveMon. DriveMon as
well as the SIMATIC Manager can be used to toggle between online and offline operation
Parameterizing types
Parameterization via lists
Graphic parameterization - basic functions
Graphic parameterization - technology functions
Parameter Set
Inserting or generating a parameter set via DriveMon
When DriveMon is open, parameter lists can be inserted or attached to all of the existing
projects. A new parameter set can be generated and linked to a project using the menu option
"File -> New -> Based on factory setting / Empty parameter set". An empty parameter list or
the factory setting can be selected.
The parameter set being currently processed can be inserted under another project for the same
drive converter and same software release via "File -> Save as ...".
Every parameter set in DriveMon has its own window.
Inserting or generating parameter sets via the SIMATIC Manager
In the SIMATIC Manager, parameters can only be inserted in parameter folders.
Proceed as follows:
1. In the SIMATIC Manager, select the parameter folder of the required drive (click once (1x)
with the left-hand mouse key on the parameter folder).
2. A new parameter set can be inserted as follows:
Using the SIMATIC Manager menu bar "Insert -> Parameter -> Parameter set" or
Using the context menu (click on the parameter folder using the right-hand mouse key)
"Insert new object -> Parameter set".
In the SIMATIC Manager, a new parameter set is always created as empty parameter set (i.e. it
does not contain any parameter values). In the SIMATIC Manager, parameter lists can be shifted
per drag and drop or copied. It is not permissible to copy into illegal object types (e.g. chart
folders).
Importing a parameter set via the SIMATIC Manager
An external parameter set (*.DNL file, generated, e.g. using DriveMonitor) can also be
integrated into the Drive ES project. Proceed as follows:
1. In the SIMATIC Manager, select the parameter folder of the required drive (with the left-hand
mouse key, on the parameter folder).
2. A new parameter set can be imported in the following ways:
Using the SIMATIC Manager menu bar "Insert -> external parameter..." or
Using the context menu (click on the parameter folder using the right-hand mouse key)
"Insert new object -> external parameter..."
101
Starting DriveMon
DriveMon is started from the SIMATIC Manager.
Start the offline mode (i.e. open and edit an existing parameter set).
1. In the SIMATIC Manager, open the parameter folder of the required drive/bus node and
select the parameter set to the opened.
2. DriveMon can be started as follows:
Double click on the selected parameter set (left-hand mouse key) or
Click on the parameter set with the right-hand mouse key and select "Open object" or
In the SIMATIC Manager via "Edit –> Open object".
Start the online mode (i.e. establish a communications link to the drive and read/change the
parameter values in the drive)
1. In the SIMATIC Manager, select the required drive (Caution: Not the bus interface, e.g.
mark CBP, but directly the drive, e.g. MASTERDRIVES MC).
2. DriveMon can be started as follows:
Click-on the drive with the right-hand mouse key and, in the context menu select the
following "Target system –> Drive -> Parameterization".
In the SIMATIC Manager via "Target system -> Drive -> Parameterization"
Please note:
When editing and working with parameter sets offline, the associated parameter set must
be marked, when parameterizing the unit online, the associated drive must be marked.
For every drive, DriveMon can be used to toggle between online and offline.
Further, parameter lists for other drives and projects can also be opened in DriveMon.
Several drives can be simultaneously opened in DriveMon. Each drive has its own window. In
the offline mode, drives from different projects can be opened.
DriveMon main window
The DriveMon window consists of:
Title line
with information on the project, drive and status
Menu line
with which you can activate all DriveMon functions
Function bar, with which you can activate important functions via Icons
Drive window
with different display options and operator action bar
General status line,
which contains the short help texts for the individual menu items.
102
The main window permits you to change, arrange, increase, decrease, minimize and maximize
the drive window which has been opened, as is usual for Windows 95 windows. However, for
reasons of transparency, it is recommended that the drive window with which you are presently
working, is maximized. It then fills the complete working area of the main window while the
inactive drive windows are invisible.
Note: If several drive windows are simultaneously open, then, for the inactive parameter
windows, only the unit status bar is updated, however, not the parameter values.
Toggling between several opened parameter windows
You can toggle between various open parameter windows using the menu option "Window
> Arrange"
Select one of the possibilities (Cascaded, Horizontally or Vertically) using the "Window >
Arrange" menu option
Result:
All the opened parameter windows are arranged corresponding to the selection made, and any
one of them can be brought to the foreground by simply clicking on it with the left-hand
mouse key (i.e. defined as active window).
103
Fig. 6.4:- Drive Monitor Active Window
Proceed as follows to close a parameter window:
Select the menu command File > Close device.
To exit DriveMon (close the main window), proceed as follows:
Select the menu command File > Exit.
Result:
The drive DriveMon application is closed and the system changes over into the SIMATIC
Manager.
Title line - DriveMon
In the title line, you can identify which drive you are presently working on and its operating
mode.
The title line of DriveMon includes
for maximized drive window
the names DriveMon, the project names, the drive names and the status of the active drive
online (RAM)
online (EEPROM)
offline (file name)
104
for a drive window which has not been maximized
the name DriveMon
the project name
of the drive name and the status are located in the title line of the drive window.
if a drive window has not been opened, then the title line only has the name DriveMon.
Drive window
Drive windows are opened to the maximum size, other settings (split window or minimized) are
established using "Window > Arrange" or using the buttons to the right in the title bar.
Title bar
If a drive window has not been maximized, the title bar shows the drive names and the status of
the active drive
online(RAM)
online(EEPROM)
offline(parameter set name)
If the drive window is maximized, the specified data/information is displayed in the title bar of
DriveMon.
Every drive window consists of
Parameter area or Drive Navigator
You can toggle between the parameter area and Drive Navigator as required.
Control bar
Parameter range
The parameter display range can be sub-divided into two independent sections. The active
section is identified by a thin blue frame (border). The inactive section is activated by clicking on
it using the left-hand mouse key:
In the active section, different views can be selected using the parameter, control and diagnostic
menus.
You can split parameter windows using the "Window > Split horizontally" menu option. In this
case, in each pane, different displays can be selected from the menu options, parameter, control
or diagnostics. The active pane has a blue frame. It is activated by clicking on it using the left-
hand mouse key. You can change the size of the pane by positioning the mouse pointer to the
line between the windows and then dragging it with the left-hand mouse key.
Contents of the parameter window when opening.
In the default setting, the "free parameterization" window is opened.
This means, you can enter those parameters, which you wish to view, in a dedicated list, and then
save this under "Parameter view".
Proceed as follows if you wish to display the complete parameter list when you start DriveMon:
Select the menu command Tools> Options.
The option dialog box opens.
105
Select the required setting in the "Pre-selection parameter window" field (empty parameter
window, complete parameter list or free parameterization).
Standard parameter table
With just a few exception (prompted start-up, trace), the Parameter and Diagnostic menus
open, under all of the menu options, the standardized table for displaying the parameters.
The parameter No., the plain text name, actual parameter value and the dimensions of the listed
parameters are entered in this table in columns P. No., Name, Parameter value and Dim. If the
current drive has indexed parameters, the Index and Index text columns are additionally
available in which, for indexed parameter, the index, and if available, the index text can be
displayed.
To change parameters, proceed as follows ("yellow" parameters (read-only parameters) cannot
be changed):
Using the left-hand mouse key, double click at any position in the appropriate line of the
table.
A window then opens to change the parameter value.
If the parameter to be changed is a "select parameter", select the new value from the text list
of possible parameter values and press OK.
If the parameter to be changed, is a "setting parameter", enter the new parameter value in the
"new value" input field and press OK. In order to monitor the limit values to be maintained,
also refer to offline mode (output-dependent parameters).
Parameter table
Column "P. No."
The parameter number is located in this column. It consists of a letter and three numbers.
Parameters which cannot be changed (parameters which can only be read) have lower-case
letters with a yellow background:
Parameters which can be changed have upper case letters and a green background:
Connectors are marked light-blue as opposed to parameters:
Binectors are marked dark-blue as opposed to parameters:
Column "index"
When you first open the parameter table, only the first index of indexed parameters is visible
(dependent on the type of the drive converter, index 000 or 001). In order to make all of the
parameter indices visible, click on the index symbol using the left-hand mouse key:
Now, all of the indices are displayed, the table contains the appropriate number of extra lines.
The index symbol changes to
106
Click on this if only the first index is to be displayed.
Operator control using the PC keyboard: The indices can be displayed or suppressed using the
<+> - or <-> - key of the numerical pad
Control bar
In the Control bar, you can enter a setpoint and ON- and OFF commands to the drive.
Prerequisites:
The drive is in the online mode (if this is not the case, the operator control line is gray and
cannot be used)
The drive is parameterized so that the setpoints and control commands are effective via the
interface (PROFIBUS or USS) of Drive ES.
Proceed as follows:
Enter a setpoint in the "Setpoint(%)" input field.
Click on the following:
Result: The drive is powered-up, the actual value is displayed in the control bar in the
"Actual value(%)" field.
Click on
Result: The drive is powered-down.
Unit status bar
The unit status bar is located at the lower edge of the DriveMon parameter window. You can use
this to obtain an overview of the status of the drive. The status display always refers to the drive
selected in the associated parameter window.
NOTE:
If several drive windows are simultaneously opened, then, for the windows which are
presently not active, only the drive status bars are updated, however, not the parameter
values themselves.
The actual drive converter status is displayed, next to the plain text messages such as ON, OFF,
OFFLINE, FAULT,... using an icon to the right next to the "drive status" field.
The color of these icons has the following significance:
Green: this drive is online and neither signals an alarm nor a fault.
Red: this drive is online and signals a fault.
Yellow: this drive is online and signals an alarm.
Blue: this drive is parameterized offline.
107
Black: DriveMon does not have a connection to the drive (the drive can only be
parameterized offline).
When in the online mode, the node address of the selected drive is displayed to the right of the
drive status icon. The drive connected to the bus system (PROFIBUS or USS) can be identified
via this address. The communications connection type between DriveMon and the drive can be
set using the DriveMon menu line: Tools> ONLINE settings > Bus type".
For MASTERDRIVES MotionControl and VectorControl devices with integrated tool
interface, the control bar is displayed in a different format and can be expanded to make a
drive control panel for operating the drive.
Splitting the drive window into two panes
Splitting the parameter display
Proceed as follows:
Select the menu command Window > Split horizontally.
Result: The parameter window is split.
Using the left-hand mouse key, click in one of the panes and then select the required contents
from the parameter, control or diagnostics menus.
Result: The required contents are displayed in the pane which was selected using the mouse.
Changing the size of the panes
The size of the pane can be changed by positioning the mouse pointer onto the line,
separating the panes and dragging the mouse to obtain the required size.
Operator control of the basic positioner
1. Go to the "Control/Observe" screen form and fetch the control command acceptance for the
drive onto your PC via the button "Request master control".
2. After the PC has accepted the control command the "drive control panel" will open.
Select "Input bits 1 to 6". This will set the drive to the ready-to-switch-on state.
3. You can now switch the drive ON and OFF via the green and red button. You can switch the
drive ON and OFF when the drive control panel is open and when it is minimized.
The drive can now be operated at variable speed via the drive control panel.
4. To operate the positioning functions activate the "Enabling Pos. Controller" button in the
"Control/Observe" screen form.
The "Release BPOS" LED should light up now.
5. The positioning functions can now be carried out via the corresponding fields and buttons.
108
Fig. 6.5 Drive Monitor response analysis window when No connection with 6RA70
6.2.2 DRIVE MONITOR CONFIGURATION
P051:- Access authorization levels
Key parameters
0 No access authorization
6 Do not set (for use by DriveMonitor)
7 Do not set (for use by DriveMonitor)
8 Do not set (for use by DriveMonitor)
21 Restore factory settings
All parameters are reset to their defaults. Parameter P051 is then
automatically reset to factory setting “40”.
22 Execute internal offset compensation
25 Optimization run for precontrol and current controller (armature and field)
26 Optimization run for speed controller
27 Optimization run for field weakening
28 Optimization run for compensation of friction and moment of inertia
29 Optimization run for the speed controller with an oscillating mechanical
system
30 Automatic setting of the parameters for SIMOREG CCP altered
parameters:
P351.i001, U577, U578, U800,
in the event of a fault, P790 if appropriate
109
40 Access authorization to parameter values for authorized service personnel
P790:- selection of protocol for G-SST2 basic converter interface
0 setting has no function
2 USS protocol
5 “peer to peer” communication
6 communication with the SIMOREG CCP
9 for internal factory test purposes
P927:- Parameterization enable
Enabling of interfaces for parameterization. A parameter value can only be altered via an
enabled interface.
0 None
1 Communications board(CB)
2 Parameterizing Unit (PMU)\
4 G-SST1 serial interface and OP1S
8 Reserved
16 Technology board (TB)
32 G-SST2 serial interface
64 G-SST3 serial interface
Setting information:
Every interface has a numeric code.
The number for one specifis interface, or the sum of various numbers assigned to several
interfaces, must be entered in this parameter in order to enable the relevant interface(s)
for use as a parameterization interface.
Example:
Factory setting value 6 (=4+2) means that the PMU and G-SST1 interfaces are enabled
for parameterization purposes.
P918:- CB bus address
Protocol-dependent bus address for communication boards
Note:
The availability of the bus address is monitored by the communication board. (Bus
addresses 0 to 2 are reserved for Master stations on PROFIBUS boards and must not
therefore be sent for other purposes). If the value is not accepted by the COM BOARD,
fault F080 is displayed with fault value 5.
n733:- CB/TB receive data
Display of control words and setpoints (process data ) that are transfeered to the basic
converter from a communication board(CB ) or technology board(TB).
i001: 1st process data word from 1
st CB/TB
..
..
i016: 16th
process data word from 1st CB/TB
110
i017 : 1st process data word from 2nd CB/TB
..
..
i032 : 16th
process data word from 2nd CB/TB
u734:- transmit data for first CB/TB
selection of connectors whose contents must be injected a transmit data to the first
communication board (CB) or technology board(TB).
0 = K0000
1 = K0001
etc.
this parameter not only defines the transmit data, but also their position in the transmit
telegram.
i001: word 1 in pzd section of telegram
i002: word 2 in pzd section of telegram
…..
i016: word 16 in pzd section of telegram
Status word 1(K0032)should be linked to word 1.
p785:- options for G-SST1
i001: 0 = Bus terminator OFF
1 = Bus terminator ON
i002: 0 = Bit 10 of the 1st receive word does not function as “Control by Master”
1 = Bit 10 of the 1st receive word does function as “Control by Master”, i.e. when
bit 10 = 0, all other bits of the 1st receive word, as well as receive words 2 to 16,
are not written to connectors K2001 to K2016, or to binectors B2100 to B2915.
All these connectors and binectors retain their old values.
n735:- Display of transmit data to CB/TB
i001: 1st process data word to 1
st CB or TB
…
i016: 16th
process data word to 1st CB or TB
i017: 1st process data word to 2
nd CB
…
i032: 16th
process data word to 2nd
CB
r001:- General visualization parameters
Display of terminals 4 and 5(main setpoint)
P701:- Normalization of “Main setpoint” analog input
This parameter specifies the percentage value which is generated for an input voltage of
10V (or an input current of 20mA) at the analog input.
The following generally applies:
111
For voltage input:
P701[%]=10V*Y/X X.. Input voltage in volts
Y.. % value which is generated for input voltage X
With current input:
P701[%]=20mA*Y/X X.. Input current in mA
Y.. % value which is generated for input current X
Fig. 6.6 Drive Monitor Run Time View
112
CHAPTER 7
PROGRAMME FILE OF SIMPLE DP /*****************************************************************************
@@COPYRIGHT
Copyright:
This source code is the proprietary confidential property of PEP Modular
Computers GmbH. Reproduction, publication, or any form of distribution to
any party other than the licensee is strictly prohibited.
@@END
@@FILEDESC
Filename: : simpledp.c
Description : Simple Profibus DP demoapplication
@@END
@@COMMON
Common description:
This simple DP-demo program initializes the protocol-stack and writes
to and reads from the DP-slave.
Configuration:
SlaveDevice: Siemens ET200B, 8 digital inputs and 8 digital ouputs
Master: Station 2
Slave: Station 13
Config-file: simpledp.cfg (.bin)
@@END
@@EDITION
Edition History
# date comments by
-- ---------- ------------------------------------------------------- ---
01 25-Jun-96 created RB
02 Jul/Aug-96 improved RB
03 28-Aug-96 released v5.01 I1.0 RB
04
05 25-Feb-97 Changed slave address to 13 RB
06 08-Sep-97 Ported to use new dpm.l library
07 May-98 IRQ- and mailboxtask handling modified RB
08 Jul-98 VxPFB support added RB
09 04-Dec-01 added pep version identifier, adapted to VxWorks SB
@@END
113
******************************************************************************
/
/* the following sequence will declare a character constant containing module
* name and version in the name and in the contents. A "." in the file name
* must be replaced by "_".
*/
#define PEP_MODNAME simpledp_c
#define PEP_VER_ID 09
#define PEP_VER_VARNAME_H(v,m,u) PEP_VER_##m##u##v
#define PEP_VER_VARNAME(v,m) PEP_VER_VARNAME_H(v,m,_)
#define PEP_VER_STR_H(m,v) "$PEPVERSION: " #m " " #v " $"
#define PEP_VER_STR(m,v) PEP_VER_STR_H(m,v)
#ifndef _ASMLANGUAGE
volatile static char PEP_VER_VARNAME(PEP_MODNAME,PEP_VER_ID)[]
__attribute__ ((unused)) = PEP_VER_STR(PEP_MODNAME,PEP_VER_ID);
#endif
#undef PEP_MODNAME
#undef PEP_VER_ID
#undef PEP_VER_VARNAME_H
#undef PEP_VER_VARNAME
#undef PEP_VER_STR_H
#undef PEP_VER_STR
#ifdef _OSK
_asm("_sysedit: equ 8");
#endif
/* includes */
/* for vxWorks support */
#include <stdlib.h>
#include <taskLib.h>
#include <ioLib.h>
#include <selectLib.h>
#include <signal.h>
#include <dp.h>
#include <profiv5.h>
#include "options.h"
/* defines */
#define SIGNAL 1 /* signaling required ? */
114
#define MAX_ARGC 20
#define SIGBUFSIZE 256
#define BIN_CFG_NAME "DP_DT.bin"
#define MASTER_DEFAULT_ADDRESS 0
#define LOWEST_SLAVE_ADDRESS 3
#define SLAVE_ADDRESS_MODE DP_AAM_COMPACT
#define DP_SLAVE_ADDRESS 3
/* tyedefs */
/* locals */
/*static path_id Path;*/
struct ConfigData
{
tBUS_PARAMETER_SET Bps;
tSLAVE_PARAMETER_SET Sps1;
OCTET GId1;
OCTET User_Data1[5];
USIGN16 Cfg_Data_Len1;
OCTET Cfg_Data1[2];
USIGN16 Add_Tab_Len1;
OCTET Add_Tab1[6];
USIGN16 Slave_User_Data_Len1;
} ConfigData;
/* extern declarations */
error_code SetSoftingDPConfig(
OCTET *pData,
long Size
);
/* globals */
u_int32 PollIntMode = POLLING_MODE;
long Signal;
long SigCount;
USIGN8 Service,
Primitive;
INT16 Result;
char ServiceResult[24][50] = {
"acknowledgement positive",
"remote user error",
"remote resource insufficient",
"remote service/SAP deactivated",
"access of remote SAP blocked",
"no reaction from remote station",
"local entity disconnected",
115
"not possible in this state",
"local resource not available",
"invalid parameter in request",
"timeout expired",
"format error in request frame",
"function not implemented",
"access denied",
"area too large",
"data block length exceeded",
"format error in response frame",
"invalid parameter",
"sequence conflict",
"sequence error",
"area non-existent",
"data incomplete",
"not connected",
"unknown result"
};
/* function prototypes */
u_int32 getpid(void);
/* functions */
void SetConfigData(void)
{
ConfigData.Bps.Fdl_Add = 2;
ConfigData.Bps.Baud_Rate = 4; /* 500 kbaud */
ConfigData.Bps.TSl = 500;
ConfigData.Bps.MinTsdr = 11;
ConfigData.Bps.MaxTsdr = 100;
ConfigData.Bps.TQui = 0;
ConfigData.Bps.TSet = 1;
ConfigData.Bps.TTr = 50000;
ConfigData.Bps.G = 10;
ConfigData.Bps.HSA = 126;
ConfigData.Bps.Max_Retry_Limit = 2;
ConfigData.Bps.Bp_Flag = 0;
ConfigData.Bps.Min_Slave_Interval = 100;
ConfigData.Bps.Poll_Timeout = 50;
ConfigData.Bps.Data_Control_Time = 20;
ConfigData.Bps.Master_User_Data_Len = 2+32+0;
ConfigData.Bps.Bus_Para_Len = sizeof( tBUS_PARAMETER_SET ) +
ConfigData.Bps.Master_User_Data_Len -2 -32;
ConfigData.Sps1.StationAddr = 3;
ConfigData.Sps1.Sl_Flag = 0xc0;
ConfigData.Sps1.Slave_Type = 0;
116
ConfigData.Sps1.Prm_Data_Len = 2+sizeof(tPRM_DATA)+1+5;
ConfigData.Sps1.Prm_Data.Station_Status = 0x08;
ConfigData.Sps1.Prm_Data.WD1 = 64;
ConfigData.Sps1.Prm_Data.WD2 = 1;
ConfigData.Sps1.Prm_Data.MinTsdr = 0;
ConfigData.Sps1.Prm_Data.IdH = 0x00;
ConfigData.Sps1.Prm_Data.IdL = 0x0b;
ConfigData.GId1 = 0;
ConfigData.User_Data1[0] = 0x11;
ConfigData.User_Data1[1] = 0;
ConfigData.User_Data1[2] = 0;
ConfigData.User_Data1[3] = 0;
ConfigData.User_Data1[4] = 0x77;
ConfigData.Cfg_Data_Len1 = 2+2;
ConfigData.Cfg_Data1[0] = 0x20;
ConfigData.Cfg_Data1[1] = 0x10;
ConfigData.Add_Tab_Len1 = 2+6;
ConfigData.Add_Tab1[0] = 1;
ConfigData.Add_Tab1[1] = 1;
ConfigData.Add_Tab1[2] = 0;
ConfigData.Add_Tab1[3] = 4;
ConfigData.Add_Tab1[4] = 0;
ConfigData.Add_Tab1[5] = 20;
ConfigData.Slave_User_Data_Len1 = 2+0;
ConfigData.Sps1.Slave_Para_Len = sizeof( tSLAVE_PARAMETER_SET ) -2 +
ConfigData.Sps1.Prm_Data_Len - sizeof(tPRM_DATA) -2 +
ConfigData.Cfg_Data_Len1 + ConfigData.Add_Tab_Len1 +
ConfigData.Slave_User_Data_Len1;
}
void AppDeinit(void)
{
DPDeinit();
MBTaskDeinit();
DPUnloadConfig();
}
void SigHand( u_int32 signal )
{
/*
Signal = signal;
if( Signal < 32 )
{
AppDeinit();
exit(Signal);
}
SigCount++;
117
_os_rte();
*/
}
void WaitForSignal(void)
{
/* u_int32 Ticks;
while( Signal != 1000 )
{
Ticks = 0;
_os9_sleep(&Ticks);
_os_sigmask(1);
}
Signal = 0;
_os_sigmask(0);
*/
}
void PrintResult( INT16 Result )
{
long i;
if( Result == E_DP_OK ) return;
switch( Result )
{
case E_DP_UE : i = 1;
break;
case E_DP_RR : i = 2;
break;
case E_DP_RS : i = 3;
break;
case E_DP_RA : i = 4;
break;
case E_DP_NA : i = 5;
break;
case E_DP_DS : i = 6;
break;
case E_DP_NO : i = 7;
break;
case E_DP_LR : i = 8;
break;
case E_DP_IV : i = 9;
break;
case E_DP_TO : i = 10;
break;
118
case E_DP_FE : i = 11;
break;
case E_DP_NI : i = 12;
break;
case E_DP_AD : i = 13;
break;
case E_DP_EA : i = 14;
break;
case E_DP_LE : i = 15;
break;
case E_DP_RE : i = 16;
break;
case E_DP_IP : i = 17;
break;
case E_DP_SC : i = 18;
break;
case E_DP_SE : i = 19;
break;
case E_DP_NE : i = 20;
break;
case E_DP_DI : i = 21;
break;
case E_DP_NC : i = 22;
break;
default: i = 23;
break;
}
printf("%s\n", ServiceResult[i] );
}
PB_BOOL GetResult(char *func, USIGN8 ReqService)
{
error_code err;
error_code ret;
PB_BOOL status = PB_TRUE;
#ifdef DEBUG
int resultCnt = 0;
#endif
/* wait for confirmation: */
do
{
#ifdef DEBUG
resultCnt ++;
#endif
if( PollIntMode == IRQ_MODE )
119
{
WaitForSignal();
printf("%ld signals received so far\n", SigCount );
}
ret = DPRcvConInd( &Service, &Primitive, &Result );
#ifdef DEBUG
if( (ret == NO_CON_IND_RECEIVED) && (resultCnt < 1000) )
{
taskDelay(1);
continue;
}
#else
if( ret == NO_CON_IND_RECEIVED ) continue;
#endif
if( Service != ReqService )
{
printf("*");
fflush(stdout);
}
}
#ifdef DEBUG
while( (!(ret != NO_CON_IND_RECEIVED && Service == ReqService)) &&
(resultCnt < 1000));
#else
while( !(ret != NO_CON_IND_RECEIVED && Service == ReqService) );
#endif
printf("\n%s ", func );
fflush( stdout );
/* complete error-handling: */
if( ret == CON_IND_RECEIVED )
{
err = DPGetConIndStatus();
if( err == E_OK )
{
printf(" was successful\n");
}
else
{
printf(" failed with errors %d / %d\n", err, DpError );
AppDeinit();
status = PB_FALSE;
}
}
else
{
#ifdef DEBUG
120
printf("recieved error %d, resultCnt = %d\n", ret, resultCnt);
#else
printf("recieved error %d\n", ret );
#endif
AppDeinit();
status = PB_FALSE;
}
#ifdef DEBUG
printf("resultCnt =%d\n",resultCnt);
#endif
return status;
}
/* void main(int argc, char **argv) */
STATUS simpledp ( char *param )
{
/* Added for Tornado to assume main (int argc, char *argv[]) compatibility */
int argc; /* Argument number including main() */
char *argv[MAX_ARGC]; /* Array for the argument strings */
error_code error, ret;
long i,
cnt=0;
u_int16 HostAccess,
HostCpu;
u_int32 DpramBaseAddr,
HostVmeMBAddr,
HostLocalMBAddr,
HostMBSize,
HostMBSetValue,
HostMBResetValue,
RegBaseAddr, /* required for VxPFB */
/* count=0,*/
SlaveAddr,
ReadFile,
Ticks;
USIGN8 Data[256],
RemoteAddress = DP_SLAVE_ADDRESS,
Length;
UINT32 usedConfigurator = 0;
u_int32 Vector = PEP_DEFAULT_VECTOR;
USIGN16 DataLength;
PB_BOOL status;
char str[80];
HostAccess = CPU_REMOTE; /* default */
121
HostCpu = CPU_OTHER;
DpramBaseAddr = 0x87002000; /* dummy, value not required for
CPU_LOCAL-access */
HostVmeMBAddr = 0xfcfe0083;/*0; changed for testing sajeed*/
HostLocalMBAddr = 0;
HostMBSize = 1;
HostMBSetValue = 0;
HostMBResetValue = 0;
RegBaseAddr = 0x8500c000; /* no VxPFB board used */
SigCount = 0;
ReadFile = 1;
/* Clean the argv[] array */
for (i=0; i<MAX_ARGC; i++) argv[i]= "\0";
/* Assume the argc, char *argv[] values in function of ParStr string */
t_PatchMain (param, &argc, argv);
/* setup host-configuration: */
/* error = _os_intercept( (void*) SigHand, _glob_data );
if( error )
{
printf("Error %d on _os_intercept() ... exit\n", error);
exit(error);
}
*/
for (i = 1; i < argc; i++)
{ /* additional library function, for flexible use of this demo: */
if (GetProgramOptions ( (char *) argv[i], &HostAccess, &HostCpu,
&DpramBaseAddr, &HostVmeMBAddr,
&HostLocalMBAddr,
&HostMBSize, &HostMBSetValue,
&HostMBResetValue) != OK)
{
return(ERROR);
}
if( strncmp( argv[i], "-sa=", 4 ) == 0 )
{
sscanf(argv[i]+4, "%d", &SlaveAddr );
printf("Slave address: %d\n", SlaveAddr );
RemoteAddress = (USIGN8) SlaveAddr;
}
else if( strncmp( argv[i], "-v=", 3 ) == 0 )
{
sscanf(argv[i]+3, "%d", &Vector );
printf("Irq vector: %d\n", Vector );
}
else if( strncmp( argv[i], "-regbase=", 9 ) == 0 )
{
122
sscanf(argv[i]+9, "%x", &RegBaseAddr );
printf("RegBaseAddr: %x\n", RegBaseAddr );
}
else if (strncmp (argv[i], "-irq", 4) == 0)
{
PollIntMode = IRQ_MODE;
printf ("Using IRQs\n");
}
else if (strncmp (argv[i], "-nofile", 4) == 0)
{
ReadFile = 0;
printf ("Using compiled data\n");
}
else if( strncmp( argv[i], "-conf=", 6 ) == 0 )
{
sscanf(argv[i]+6, "%d", &usedConfigurator );
printf("used Configurator: %d\n", usedConfigurator );
}
}
error = DPMLibInit( PB_V5X );
DPSetController(0);
DPSetConfigurator((UINT8)usedConfigurator);
printf("Calling SetHostConfiguration\n");
error = SetHostConfiguration (&DpramBaseAddr, RegBaseAddr, HostCpu, HostAccess,
HostVmeMBAddr, HostLocalMBAddr, HostMBSize, HostMBSetValue, HostMBResetValue);
printf("SetHostConfiguration Executed\n");
if (error)
{
printf ("SetHostConfiguration() returned error %d\n", error);
return (ERROR);
}
else
{
printf ("SetHostConfiguration ok\n");
}
error = MBTaskInit (DpramBaseAddr, Vector, 1000, PollIntMode);
if (error)
{
printf ("Error init mailboxtask %d\n", error);
123
MBTaskDeinit();
return (ERROR);
}
else
{
printf ("Mailboxtask init ok\n");
}
if(ReadFile)
{
if ( (error = DPLoadConfig(BIN_CFG_NAME)) != E_OK /*&& error !=
E_DP_SLAVE_PARA_FAULT */)
{
printf("Configurationfile '%s' not found\n",BIN_CFG_NAME);
/* For compatibility with previous releases: */
if ( (error = DPLoadConfig(BIN_CFG_NAME)) != E_OK )
{
MBTaskDeinit();
return(ERROR);
}
printf("Using configurationfile '%s' \n",BIN_CFG_NAME);
}
else
{
printf("Using configurationfile '%s'\n",BIN_CFG_NAME);
}
}
else
{
SetConfigData();
error = DPSetConfig((OCTET*) &(ConfigData.Bps), (long) sizeof(struct
ConfigData));
if ( error != E_OK && error != E_DP_SLAVE_PARA_FAULT )
{
printf("Configuration fault\n");
MBTaskDeinit();
return(ERROR);
}
else
{
printf("Using hard-coded configuration\n");
}
}
printf ("\n\nHostCpu = %x \n", HostCpu);
printf ("DpramBaseAddr %x\n", DpramBaseAddr);
124
printf ("HostAccessMode %x\n", HostAccess);
printf ("Host VME Mailbox addr %x\n", HostVmeMBAddr);
printf ("Host Local Mailbox addr %x\n", HostLocalMBAddr);
printf ("Host Mailbox size %x\n", HostMBSize);
printf ("Host Mailbox IRQ-set-value %x\n", HostMBSetValue);
printf ("Host Mailbox IRQ-reset-value %x\n", HostMBResetValue);
printf ("Register base address of VxPFB %x\n", RegBaseAddr );
printf ("\n");
/* Now initialize the Profibus protocol stack: */
error = DPInit( DpramBaseAddr );
if ( error != E_OK )
{
printf("DPInit() failed !\n");
MBTaskDeinit();
return(ERROR);
}
printf("DPInit() ok!\n");
DPSetMasterDefaultAddress( MASTER_DEFAULT_ADDRESS );
DPSetMasterClass2( PB_FALSE );
DPSetLowestSlaveAddress( LOWEST_SLAVE_ADDRESS );
DPSetSlaveAddressMode( SLAVE_ADDRESS_MODE );
DPSetClearOutputsOnInit( PB_TRUE );
DPSetAutoRemoteServices( DP_USER_REMOTE_SERVICES );
DPSetCyclicDataTransfer( PB_TRUE );
error = DPInitMasterReq();
if( GetResult("DPInitMasterRequest", DP_INIT_MASTER ) != PB_TRUE )
{
PrintResult( error );
DPUnloadConfig();
MBTaskDeinit();
return(ERROR);
}
error = DPDownloadLocReq( MASTER_DEFAULT_ADDRESS, RemoteAddress, 0 );
sprintf(str, "DPDownloadLocReq (%d)", RemoteAddress );
if( error != E_OK || GetResult(str, DP_DOWNLOAD_LOC ) != PB_TRUE )
{
PrintResult( error );
DPUnloadConfig();
MBTaskDeinit();
return(ERROR);
}
error = DPDownloadLocReq( MASTER_DEFAULT_ADDRESS, 127, 0 );
if( error != E_OK || GetResult("DPDownloadLocReq (127)", DP_DOWNLOAD_LOC )
!= PB_TRUE )
125
{
PrintResult( error );
DPUnloadConfig();
MBTaskDeinit();
return(ERROR);
}
error = DPActParamLocReq( MASTER_DEFAULT_ADDRESS,
DP_AREA_SET_MODE, DP_OP_MODE_STOP );
if( error != E_OK || GetResult("DPActParamLocReq stop", DP_ACT_PARAM_LOC )
!= PB_TRUE )
{
PrintResult( error );
DPUnloadConfig();
MBTaskDeinit();
return(ERROR);
}
Ticks = 60; /*0x80000010;*/ /* 1s */
taskDelay(Ticks); /*_os9_sleep( &Ticks );*/
printf("Waiting for slave diagnose, press RETURN to abort ...\n");
for(i=0;;i++)
{
error = DPSlaveDiagReq( RemoteAddress );
if( (error != E_OK && error != 22) /* timeout expired */ || kbhit())
{
while(kbhit()) getch();
DPDeinit();
PrintResult( error );
DPUnloadConfig();
MBTaskDeinit();
return(ERROR);
}
printf("Waiting for confirmation");
/* wait for confirmation: */
do
{
if( PollIntMode == IRQ_MODE )
{
/*WaitForSignal();*/
}
ret = DPRcvConInd( &Service, &Primitive, &Result );
}
while( Service != DP_SLAVE_DIAG );
if( ret == CON_IND_RECEIVED )
{
126
error = DPSlaveDiagCon( &RemoteAddress, &DataLength, (OCTET*)
Data );
if( error != E_OK )
{
if( !(i%10) ) PrintResult( error );
Ticks = 10;
taskDelay(Ticks); /*_os9_sleep( &Ticks );*/
}
else
{
printf("Diag-data (length = %d):\n", DataLength);
for( i=0; i<DataLength && i<256; i++ )
{
printf("0x%x ", (u_int32) Data[i] );
}
printf("\n--- end ---\n");
break; /* exit loop when diag message received */
}
}
}
taskDelay(sysClkRateGet()*5); /* stack needs some time to start up */
error = DPGetCfgReq( RemoteAddress );
if( error != E_OK )
{
PrintResult( error );
DPDeinit();
DPUnloadConfig();
MBTaskDeinit();
return(ERROR);
}
/* wait for confirmation: */
printf("Waiting for CFG-data ...\n");
do
{
if( PollIntMode == IRQ_MODE )
{
/* wait for IRQ from stack: */
WaitForSignal();
}
ret = DPRcvConInd( &Service, &Primitive, &Result );
if( ret == NO_CON_IND_RECEIVED ) continue;
}
while( Service != DP_GET_CFG );
printf("ok\n"); fflush(stdout);
127
if( ret == CON_IND_RECEIVED )
{
error = DPGetCfgCon( &DataLength, (OCTET*) Data );
if( error != E_OK )
{
PrintResult( error );
}
else
{
printf("Config-data (length = %d):\n", DataLength);
for( i=0; i<DataLength && i<256; i++ )
{
printf("0x%x ", (u_int32) Data[i] );
}
printf("\n--- end ---\n");
}
}
error = DPActParamLocReq( MASTER_DEFAULT_ADDRESS,
DP_AREA_SET_MODE, DP_OP_MODE_CLEAR );
if( error != E_OK || GetResult("DPActParamLocReq clear ", DP_ACT_PARAM_LOC )
!= PB_TRUE )
{
PrintResult( error );
DPUnloadConfig();
MBTaskDeinit();
return(ERROR);
}
error = DPActParamLocReq( MASTER_DEFAULT_ADDRESS,
DP_AREA_SET_MODE, DP_OP_MODE_OPERATE );
if( error != E_OK || GetResult("DPActParamLocReq operate", DP_ACT_PARAM_LOC
) != PB_TRUE )
{
PrintResult( error );
DPUnloadConfig();
MBTaskDeinit();
return(ERROR);
}
Ticks = 10; /*0x80000100;*/
taskDelay(Ticks); /*_os9_sleep( &Ticks );*/
/* now enter loop to read and write the slave: */
Length = 4;/*changed by sajeed*/
fflush(STD_IN);
printf("Address of Data is: %x",&Data[0]);
128
do
{
if( (cnt%1000) == 0 )
{
/* without taskDelay the host shell does not get enough time to */
/* print, so some printfs might get lost */
taskDelay(1);
error = DPReadIOByAddReq( RemoteAddress, &Length, Data );
if( error == E_OK )
{
printf("%d bytes read: ", Length );
fflush( stdout );
for( i=0; i<Length && i < 20; i++ ) printf("%4x", Data[i] );
printf("\n");
}
}
else
{
Data[0] = cnt;/*0x11; /*cnt; set to provide a constant value sajeed*/
Data[0] = 0xff;/*just to check the integrity changed by dinesh0x11; /*cnt;
set to provide a constant value sajeed*/
status = DPWriteIOByAddReq( RemoteAddress, 1, Data );
}
cnt++;
/*error = _os_gs_ready( stdin->_fd, &count );*/
/*if( error != 0 ) count = 0;*/
}
/* exit, when keyboard hit */
while( ! kbhit() /*count<=0*/ );
while(kbhit()) getch();
DPDeinit();
/* Now deinitialize the Profibus protocol stack: */
Ticks = 10; /*0x80000100;*/
taskDelay(10/*Ticks*/); /*_os9_sleep( &Ticks );*/
MBTaskDeinit();
DPUnloadConfig();
printf("\n --- End ---\n");
return(OK);
}
/* END OF FILE */
129
CHAPTER 8
Execution of data transfer between CBP2 module and VME interface card
through PROFIBUS
1. As shown in fig.1 the connection between the 6RA70 drive master controller and laptop is
done by DB9 pin connection and with VME system by PROFIBUS cable for analog data
transfer.
Fig. 8.1:- Connection between 6RA70 & VME system
2. On 6RA70, there are analog channel inputs where we can apply 0 to 10 V dc on pin number 4
& 5. as shown in the figure, we are giving 4 V dc supply to analog channel input of 6RA70.
130
Fig. 8.2:- Input reference signal
and the reference signal (4 V dc) is converted into digital (HEX value) by 6RA70 controller that
is shown in following figure.
Fig. 8.3:- Communication Status by viewing LEDs
131
3. As per the 4 V analog input, 40% of loading is displayed on the Drive Monitor Screen. The
HEX value corresponding to 4 V (4 * 666 HEX) is 1998 HEX. This value is going to 6RA70
controller and the green LED is ON. This means that the communication is taking place.
Fig. 8.4:- Drive Monitor Status for reference signal
133
4. the corresponding HEX value (1998 H) is transferred to the VME interface card by
PROFIBUS as shown in following figure.
Fig. 8.6:- Data transfer through VME interface card
5.The same value through VME rack and processor is displayed on shell window from VME
interface card.
134
6. Now, from Tornado Shell, the data ff H is written from the master to slave number3 and again
this data will go to VME interface card. Through PROFIBUS, this data will go to 6RA70
controller CBP2 module.
136
8. Thus, the two way communication takes place. Every time 4 bytes are being read and 4 bytes
are written.
137
APPLICATION:-
• 6RA70 6,12 pulse converter is used as the firing of TF & PF.
• In other power supplies where 6,12 pulse conerter is required; the 6RA70
pulse converter is usable.
138
CONCLUSION:-
• We learnt Real Time Operating Systems of VME (TORNADO), Drive
Monitor software of Controller & Interfacing of two different systems.
139
REFERENCE:-
1. The VMEbus Handbook,4th Edition by Wade D. Peterson, VITA 1997 pp 3-10.
2. tornado Training workshop VOL1.
3. www.vita.com
4. www.ipr.res.in
5. www.windriver.com
6. http://www.wrs.com/training
7. User manual of AVME 9668 acromag
8. User manual of IP330 acromag
9. Siemens Energy & Automation