Download - InduSoft Driver Configuration Webinar
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) [email protected](Brazil) [email protected](Germany) [email protected]
Support [email protected] 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