Driver Configuration on InduSoft Web

Studio

InduSoft (Eng. Andre Bastos) Company Overview

The need of Comm Drivers for HMI/SCADA systems

Drivers on InduSoft Web Studio architecture

How the drivers get data from devices: Physical and

Logical layers

Concept of Communication Protocols

Communication Drivers configuration on InduSoft Web

Studio

Optimizing your communication

Troubleshooting drivers

Agenda

Company Overview

Corporate profile

Established in US in 1997

Pioneer in industry: First HMI/SCADA package for Microsoft Windows CEWeb solution and XML integration in HMI/SCADAPatent for database connectivity

Certifications:

Awards:

Worldwide Offices

Austin, TX, USAHeadquarters

São Paulo/Campinas, Brazil Walldorf, Germany

ArgentinaAustraliaAustriaBahrainBelgiumBelizeBrazilBruneiBulgariaCambodiaCanadaCaribbeanChileChinaColombia

Costa RicaCzech RepublicDenmarkEcuadorEgyptEl SalvadorFinlandFranceGermanyGreeceGuatemalaHondurasHungaryIcelandIndia

IndonesiaIrelandIsraelItalyJapanLaosMacedoniaMalaysiaMexicoMoldaviaMontenegroNew ZealandNetherlandsNicaraguaNorway

PakistanPanamaPeruPhilippinesPolandPortugalPuerto RicoRomaniaRussiaSerbiaSingaporeSlovakiaSouth AfricaSouth KoreaSpain

SwedenSwitzerlandThailandTurkeyUkraineUnited KingdomUruguayVenezuelaVietnamand growing…

The need for Communication

Drivers on HMI/SCADA

systems

The need for Comm Drivers

Ref.: http://www.marketsandmarkets.com

When Process and Machines need to interact with Human Beings they need to speak a common language. As an example, let us think about an Industrial Furnace:

Supposing this is a gas-burning type of Furnace In order to have a flare, you need gas In order to know how much gas the furnace needs to feed the flames and generate

the correct temperature, you need to know what temperature you have in the Furnace

Once you know the temperature, you can send more or less gas to the Furnace You do that by controlling how much the gas valve will be open or closed

The need for Comm Drivers

Ref.: http://www.marketsandmarkets.com

So, if you want to know the temperature and control the gas valve position, you need: A thermocouple in the furnace that translates temperature into electric signals A valve head that will move according to electric signals sent to it

Controlling the electric signals A process controller, such as a PAC, PLC, single and multi-loop controllers will be the

ones with the logic to control the valve according to the temperature The converters from analog electric signals into digital is made by specific cards in

the controllers The controller, thus, has the actual temperature values and is able to process them

an d send the signal to properly control the gas valve

The need of Comm Drivers

How will the temperature value and Setpoint be reached by the process operator, if: The process values are being processed by the process controller, and These values are bits and bytes, being processed in low-level process language?

The first thing is that the controller is usually not a completely closed Black-box!

It has a way to communicate with the outside world!!!

Process controllers, usually have: One or more communication ports An I/O Image table The capability of transmitting data

from the I/O image table through the communication ports

Ref.: http://programlogiccontrol.com

The need of Comm. Drivers

Since the Process Controllers are capable of exchanging data with the outside world through these communication ports, Human-Machine Interfaces (HMIs) and SCADA systems should be capable of finding a way to reach this process data

The part of the HMI/SCADA systems that will be responsible to reach the process control data and process it is the

Communication Driver

Communication Drivers on

InduSoft Web Studio

Drivers on InduSoft Web Studio

InduSoft Web StudioCore Process

Tags Database

Comm.Driver

Process Controller

Communication Channel

Local Viewer

Remote SecureViewer

Web Thin Client

TCP/IP Communications

How the Drivers get the Data from Process ControllersThe 2 Layers of communications with Process Controllers:

Logical Layer Physical Layer

How the Driver gets the Data

Physical Layer:

Using default Windows resources APIs Serial Communication Channels:

default: RS232 (Voltage) RS422/485 (Current)USB

Ethernet

Using 3rd-Party APIs specific bus types, such as CAN, Profibus, DeviceNet,

ControlNet, Interbus, ASi, DH+, and so forth

Ref.: http://icpdas-usa.com

How the Driver gets the Data

Physical Layer - Serial:The physical port will be used ONLY by that specific communication type!

RS232 (Voltage) – short distances, only peer to peer

RS422/485 (Current) – supports multi-drop and longer distances

How the Driver gets the Data

Physical Layer - Ethernet:The physical port can be used for the communication with the Process Controllers, but also with anything else that goes through Ethernet, such as web server and clients (internet), e-mails, etc…For Process Controllers, it does support several devices and usually the Controller supports multiple connections

How the Driver gets the Data

Physical Layer - Other:Depending on the bus that you want to be, you may need specific PC-Adaptors that will allow your PC or WinCE device to be a node on that specific bus.

The PC-Adaptor comes with Device Drivers and it would need an API to allow access to it

Some of the most common Industrial Buses that require specific PC cards are: Profibus-DP ControlNet DeviceNet DH+ / DH485 / RIO Interbus Modbus Plus ControllerLink

How the Driver gets the Data

Logical Layer:

The Data Exchanged by the Process Controllers through the Physical Channels usually obeys some kind of convention

Something like: This combination of bytes means that the HMI wants to know the Temperature of the Thermocouple from the First Zone in the Furnace A

This convention or language spoken by these controllers is what we call Communication Protocol

Ref.: http://www.modbus.org

How the Driver gets the Data

Logical Layer:

Protocols: Messaging Scheme

Most of the drivers is based on the concept of Master x Slave

Master: Side of the communication that starts the conversation and sends the messages

Slave: Side of the communicationthat listens and wait to receive messages from the Master, and then replies back

Ref.: http://www.modbus.org

How the Driver gets the Data

Logical Layer:Protocols: Messaging Scheme

Example of a message frame

Master: Sends the message. This is what we call TX (Transmit)

Header: usually the bytes that identify the beginning of the message, total number of bytes of the message, slave address that the message is addressed to, etc…Message: usually the Command (Read, Write, etc…), the Controller Register type, the initial address and the quantity of registers that will be read

Error Check: Error check calculation, executed on both ends, to see if the messages are valid, using bytes from the message, header, or both

Header Message Error Check

How the Driver gets the Data

Logical Layer:Protocols: Messaging Scheme

Example of a message frame

Slave: Replies to the message sent by the Master. This is what we call RX (Receive)

Header: bytes that identify the beginning of the message, total number of bytes of the message, slave address that the message was addressed to, so the Master can identify the response, etc…

Message: it may have a Reply Command (Read, Write, etc…), and then the values requested by the Master

Error Check: Error check calculation, executed on both ends, to see if the messages are valid, using bytes from the message, header, or both

Header Message Error Check

Communications

Logical Layer:Factors that Impact the Communication:Message Size: Depending on the protocol, the Controller supports only a certain number registers to be sent in a RX message. It varies a lot depending on the device manufacturer.

Some devices support only 32 words per messageOthers, 64 words or even 512

If the driver requests a message larger than what the protocol supports, the Controller replies with an error message

Number of Messages: Because of the limitations for size of the message that the Controller supports, some protocols require several messages to acquire a certain amount of registers, impacting the overall driver performance

Less Messages = Faster CommunicationsProgram your Controller in a way that the registers can fit in fewer messages

Communications

Logical Layer:Factors that Impact the Communication: Special CasesPACs, CIP: Most of new Programmable Automation Controller, have programming language and protocols based on variables or tag names

One example of this kind of device and protocol is the Ethernet/IP PLC families from Rockwell: ControlLogix, FlexLogix, CompactLogix, Micrologix 1100/1400

The communication with these devices is impacted byThe max message sizes supported by the CIP protocol are FIXED in

TX: 544 bytesRX: 493 bytes

The name of the Tags that will be accessed are part of the message

This means that shorter tag names yield more tags per message = faster communication

Use Arrays!!! - 1 Tag Name + several values!

Communications

Logical Layer:Factors that Impact the Communication: Special Case3rd Party APIs based drivers:Some drivers were developed using specific 3rd-Party APIs, for different reasons

Beckhoff TwinCAT (TWCAT) - ADSOMRON – Fins/Sysmac Gateway (OMRON)CodeSys (COSYS) - PLCHandlerModbus Plus (MODPL) – Cyberlogic MBX Suite Straton (STRAT) – Q-InterfaceDH+ / RIO using SST Card (SSTDH/STRIO)

The Driver calls functions from these APIs to reach the field device’s registers values

The performance of this kind of driver depends (a lot) on the 3rd-Party API

Ethernet

Physical + Logical LayersEthernet-based drivers

Fast baud-rateSame physical port accessing several different devices and protocolsMultiple connections to the same device

ConfiguringCommunication

Driver Worksheets onInduSoft Web

Studio

Driver Sheets

Choosing between:Main Driver Sheet (MDS) vs Standard Driver Sheet (SDS)Main Driver SheetPros:

Simple Configuration: usually uses the same PLC address syntaxAutomatic calculation of block sizes and group of messagesPossibility of configuring Scan for Always, Screen, Auto

Cons:Fixed scan RateEvery row requires a Station configurationHard to identify a faulty communication groupWrites Items Only

Main Driver Sheet Standard Driver Sheet(s)

Qty./project 1 9999

Rows/sheet 4096 4096

Scan period approx 600ms

(default)

You decide what triggers each sheet independently:

-Independent Read/Write Triggers -Enable Read When Idle -Enable Write On Tag Change

PLC address Mix type Single type for each sheet

Driver Sheets

Choosing between:Main Driver Sheet (MDS) vs Standard Driver Sheet (SDS)Standard Driver SheetPros:

Total Control of your Communication: choose when you want to read or writeRead constantly or on-demandWrite an entire Group of variables or one single itemIndividual Group Communication Feedback1 Station configuration for the entire group

Cons:Configuration is less-friendly than MDSManual configuration of Blocks obeying Block SizesOnly 1 Station per worksheetOnly 1 Register type per worksheetYou may end up using several worksheets – harder maintenance

Main Driver Sheet Standard Driver Sheet(s)

Qty./project 1 9999

Rows/sheet 4096 4096

Scan period approx 600ms

(default)

You decide what triggers each sheet independently:

-Independent Read/Write Triggers -Enable Read When Idle -Enable Write On Tag Change

PLC address Mix type Single type for each sheet

How to Contact InduSoft

Email(US) info@indusoft.com(Brazil) info@indusoft.com.br(Germany) info@indusoft-germany.de

Support support@indusoft.comWeb site

(English) www.indusoft.com(Portuguese) www.indusoft.com.br(German) www.indusoft-germany.de

Phone (512) 349-0334 (US) +55-11-3293-9139 (Brazil) +49 (0) 6227-732510 (Germany)

Toll-Free 877-INDUSOFT (877-463-8763) Fax (512) 349-0375

Contact InduSoft Today

Germany

USA

Brazil