Implementarea API pentru diverse module de comunicatie

Se propune definirea unui API unificat de suficienta generalitate permitand accesul la

informatie utilizand diverse tehnologii si interfete de comunicatie.
In acest scop, se propune dezvoltarea unei palete de mecanisme de comunicatie de tip
DDE, OPC, ActiveX, HLI, etc, in functie de echipamentul cu care se realizeaza
comunicatia, indiferent de protocolul de comunicatie ales. Fiecare dintre aceste
module de comunicatie trebuie sa initieze o conexiune in functie de mecanismul de
comunicatie utilizat, sa citeasca/scrie date, sa primeasca evenimente.

Mecanism de Comunicatie DDE

Caracteristici si functionalitate
 Asigura un canal de comunicatie bidirectional DDE
(dynamic data exchange), cu orice aplicatie (cu suport DDE)
 Tipuri de date: Celule de date (scalari), Vectori de date
(lineari sau matriceali bidimensionali)
 Asigura comunicatia cu alte module din cadrul
aplicatiei care o creeaza:
Accepta comenzi de la modulele aplicatie (pentru iesire de date catre
canalul DDE) prin CALL de metode declarate publice. Datele catre
canalul DDE sunt transmise de la modulele aplicatie catre entitatea de
comunicatie prin intermediul unei zone PUBLICE de date.

Datele de la canalul DDE sunt puse la dispozitia modulelor aplicatiei prin

intermediul unei zone PUBLICE de date. Notificarea (modulelor aplicatie) de
schimbare a datelor se face prin intermediul unor EVENIMENTE.

79
 Canale DDE

APLICATIE
cu suport DDE
(Excel, MatLab)
Data Form
Data Arrays, Data Cells

Canale DDE

Componenta de
comunicatie
CALL CALL

EVENIMENTE
Data Class

Module CALL

Segment
public de
date

Fig. 5.1 Mecanism de comunicatie DDE

Prin adoptarea acestui mecanism de transmisie de date in tre Data Class

(Clasa de date – de comunicatie) si modulele aplicatiei, se asigura
“independenta ca fir de executie” a entitatii de comunicatie DDE. Acest
modul de comunicatie trebuie sa fie capabil sa urmareasca schimbarea
dinamica a datelor aplicatiei partenere de comunicatie DDE. Pentru a avea
aceasta capacitate, trebuie realizata o “ruptura” in firul de executie a
transmisiei de date catre modulele “consumatoare” (modulele care proceseaza
datele). Cu alte cuvinte: Clasa de comunicatie nu ASTEAPTA ca dat ele sa fie
procesate – ea depune datele si notifica prin intermediul unor Evenimente
(Broadcasted) aparitia unor modificari a datelor. Dupa aparitia
Evenimentelor, modulele “interesate” in modificarea de date vor achizitiona
aceste noi informatii din zona Publica dedicata, si le vor consuma (le vor
procesa) in cadrul propriului lor “fir de executie” (Thread).
In cadrul aplicatiei dezvoltate, nu s-a gasit utila “independenta ca fir de
executie” a producatorului de date catre DDE de Clasa de comunicatie.
Aceasta “rupere” a firelor de executie este oricand posibila prin adpotarea
aceluiasi mecanism al Evenimentelor. Am preferat o restrictionare a
vizibilitatii modulelor in locul independentei in ambele sensuri. Astfel: Clasa
de comunicatie nu “cunoaste” (nu vede) nimic altceva decat Zona de Date

80
Publice, doar Modulele “interesate” in receptia de date DDE sunt obligate sa
cunoasca instanta Clasei de comunicatie.

Structura

Untitatea de comunicatie este formata din:

 Forma de date (Data Form)
 Clasa de date (Data Class)

FORMA de Date: este suportul controalelor care contin legatura DDE (DDE
Link). Aceste controale sunt de tip Label (comunicatia se face prin
intermediul proprietatii “Caption” si a evenimentului “Change”).
FORMA executa la initializare urmatoarele actiuni:
 lanseaza in executie aplicatia EXCEL cu fisierul de
lucru dorit
 seteaza Topica conversatiei DDE: LinkTopic =
"Excel|Sheet1"
 seteaza sursa sau destinatia de date de conversatie
(celula sau vectorul de date): LinkItem
 seteaza modul de legatura: LinkMode = Automatic

FORMA este creata de catre Clasa si ea are vizibilitate catre Clasa creatoare.
Astfel, FORMA primeste comenzi prin apelare directa (CALL) de la Clasa
creatoare a ei si este capabila de a trimite Date catre aceeasi clasa prin
apelare directa. Firele de executie ale FORMEI de Date si a Clasei creatoare a
ei sunt conectate (nu este utila deconectarea celor doua fire de executie).
CLASA de Date are rolul de a furniza o vizibilitate a caracteristicilor
FORMEI de Date catre modulele consumatoare si producatoare de date de la
si catre canalul DDE. Cu alte cuvinte Clasa va fi creata de unul din modulele
aplicatiei si va fi facuta vizibila catre celelalte module. Aceasta Clasa, fiind
un obiect distinct, va avea alocat propriul sau Thread (fir de exec utie) si pot
sa-i fie apelate metodele declarate publice si receptionate Evenimentele emise
de ea prin faptul ca este “vizibila” (celelalte module cunosc “referinta” ei).

Mecanism de Comunicatie Socket

Un socket este un „capat” de comunicatie – un obiect prin intermediul unei

aplicatii de socket, unitatile de calcul transmit sau receptioneaza pachete de
date in retea.
Un socket este de un anumit tip (socket-uri orientate pe flux - TCP sau Socket-uri
orientate pe datagrama - UDP), si este asociat unui anume proces si poate avea un
nume. Ambele tipuri de socket-uri sunt bidirectionale, full-duplex.

81
Cele doua tipuri de socket-uri sunt:

 socket-uri orientate pe flux (TCP - Transport Control

Protocol): trimite un flux de bytes. Se garanteaza ca fluxurile de date
sunt primite, isi pastreaza secventialitatea (pachetele sunt primite in
ordinea in care au fost trimise) si sunt corecte si neduplicate (un
anumit pachet se primeste o singura data). Acest tip de socket-uri se
preteaza in cazul transmiterii unui volum mare de date. Socket-urile
orientate pe flux sunt preferate de asemenea in cazul in care este
necesara garantia ca datele s-au primit si atunci cand dimensiunea
datelor este mare (de exemplu fisiere imagine). .Acest protocol
asigura stabilirea unei conexiuni intre cele doua calculatoare pe
parcursul comunicatiei. Odata conexiunea stabilita, protocolul TCP
mentine conexiunea si asigura integritatea datelor

 socket-uri orientate pe datagrama (UDP - User

Datagram Protocol ): trimite un flux de date orientat pe inregistrare
(pachete de date, numite datagrame). In acest caz nu se garanteaza
secventierea corecta sau neduplicarea datelor, nu se garanteaza
receptionarea datagramelor, acestea pot fi duplicate insa dimensiunea
datagramei se pastreaza. In cazul datagramelor nu se realizeaza o
conexiune explicita, se poate trimite un mesaj datagrama catre un
socket specificat si se poate primi un mesaj de la un socket specificat.
Socket-urile de tip datagrama sunt preferate celor de tip flux in cazul
datelor orientate pe inregistrari (record-oriented data). Acest protocol
nu stabileste o conexiune intre cele doua calculatoare.

Se pot evidentia trei aspecte care trebuie luate in considerare in evaluarea

celor doua tipuri de protocole:
 “relatia protocolului cu conexiunea” - TCP este un
protocol orientat pe conexiune (connection-oriented). Aceasta
inseamna ca nu poate comunica sau transporta date pana cand nu
stabileste o conexiune cu punctul de destinatie. Spre deosebire de
TCP, UDP face parte din categoria protocoalelor care nu necesita
stabilirea unei conexiuni cu destinatarul inainte de a incepe transmisia
datelor (connectionless).
 Siguranta transferului de date – atat din punctul de
vedere al faptului ca toate pachetele transmise sunt receptionate
(gradul de pierdere a pachetelor in procesul de transmisie), din punct
de vedere al duplicarii datelor, cat si din punctul de vedere al
secventialitatii lor (capacitatea de a asigura consistenta temporala a
pachetelor de date transmise – ordinea transmisiei pachetelor de date
sa fie reflectata la receptie): - TCP este un protocol sigur, utilizand
sume de control, mesaje de confirmare si o serie de alte tehnici pentru
a garanta ajungerea la destinatie a tuturor pachetelor de date in mod

82
 corect, - UDP este un protocol de transport nesigur (nu este garantata
ajungerea unor date corecte la destinatie).
 Modul in care se face transmisia datelor – prin care se
poate face distinctia intre protocoale de tip byte-stream (sir de octeti)
si protocoale de tip datagram. TCP este un protocol de tip byte-stream
(transmite toata informatia considerand-o ca pe un sir de octeti). UDP
este un protocol de tip datagrama, transmitand datele ca unitati
independente de informatie. O astfel de unitate independenta de
informatie este numita datagrama. Protocolul de tip datagrama
transmite fiecare datagrama independent de orice alta datagrama. Daca
pentru transmiterea unei informatii este necesar sa se transmita mai
multe datagrame la aceeasi destinatie atunci nu este sigur ca
datagramele vor ajunge in aceeasi ordine in care au fost transmise. Pe
de alta parte, UDP ofera diferentierea datagramelor intre ele (orice
receptie de date, reprezinta receptia unei datagrame, in conditiile in
care pachetul de date reprezentat de datagrama nu depaseste
dimensiunea maxima admisa la receptor), in timp ce in cazul TCP nu
se asigura nici transmiterea inregistrarii intr-un singur mesaj, si nici
concatenarea a doua sau mai multe inregistrari in acelasi byte-stream
(la nivel de aplicatie care utilizeaza un socket cu protocol de tip TCP,
trebuie utilizat un mecanism – protocol de diferentiere a
inregistrarilor).

TCP versus UDP

Alegerea tipului de protocol de transmisie prin socket in aplicatii de

transmisie de date in mediul industrial, este de regula impusa de mediul
informational, care poate avea unele caracteristici cu pondere in luarea
deciziei:

 Dimensiunea pachetelor de date transportate.

Transportul unor pachete de date de dimensiune mare impune
utilizarea protocolului TCP. In cazul unor date de proces care se
dispun in pachete de date de mici dimensiuni, UDP este mult mai
eficient din punct de vedere al timpului de raspuns al procesului de
transport, cat si al incarcarii suportului de transport (largimea de
banda a retelei utilizate). Intreaga “incarcare a costului protocolului”
(costul in termen de complexitate: verificarea erorilor, calculul si
transportul calculul sumelor de control) devine cu atat mai
semnificativa, cu cat pachetele de date transportate sunt de
dimensiune mai mica.
 Caracterul datelor de transportat. Se pot identifica
multe tipuri de aplicatii de comunicatie in care, prin semnificatia
datelor transmise, siguranta protocolului este mai putin relevanta ca
performantele de timp de raspuns ale procesului de transport al
datelor. Spre exemplu, datele de tip inregistrari (record oriented data),

83
 contin valori ale unor variabile de proces reprezentand stari ale unor
parametri, transmise cu un caracter informativ (exemplu: date de
proces care periodic sunt afisate pe un ecran de operator). Un alt
exemplu este cazul mesajelor de sincronizare temporala (timpul
sistem al tuturor echipamentelor in intregul sistem informational al
procesului industrial) periodice care trebuie distribuite (broadcasting)
de catre o unitate de calcul, la toate celelelte echipamente din sistem.
 Tipul topologic al suportului de transport de date –
tipul de retea de comunicatie utilizata. In cazul retelelor locale (LAN –
Local Area Network) gradul de siguranta a datelor pentru un protocol
de tip UDP este considerat bun, dar in conditiile WAN (Wide Area
Network) TCP se impune, deoarece un protocol de tip UDP nu poate
asigura un grad acceptabil de siguranta a transportului datelor.
 Partenerul de comunicatie (in unele aplicatii de
comunicatie, partenerii de comunicatie nu ofera optiuni pentru ambele
tipuri protocoale).

Socket-uri Windows

In cadrul Socket-urilor Windows, canalele de comunicatie intre aplicatii sunt

reprezentate prin structuri de date numite socket-uri. Un socket este
identificat printr-o adresa de IP si un numar de port.
O conexiune pe retea, intre doua aplicatii se identifica printr-un set de cinci
proprietati:
 port local care specifica unde anume primeste un
program sau un proces (aplicatie) mesajele sau datagramele;
 adresa locala a hostului - identifica unitatea de calcul
gazda ce va receptiona pachetele de date;
 portul partener - identifica programul sau procesul
(aplicatia) la unitatea de calcul partener de comunicatie;
 adresa partener care identifica unitatea de calcul host
(partenerul de comunicatie, aflat la distanta, sau nu) cu care se doreste
comunicarea;
 protocolul care ajuta la specificarea modului in care
programele vor face transferul de date pe retea;

Un port este ca si o adresa IP cu diferenta ca TCP/IP asociaza un port cu o

anumita aplicatie ce utilizeaza un anumit protocol si nu cu anumit calculator.
Cu alte cuvinte unei aplicatii care utilizeaza socket ii este asociat de catre
sistemul de operare un port, si acesta nu poate fi utilizat de catre alte
aplicatii. Pe aceeasi unitate de calcul se pot gasi mai multe porturi alocate
pentru aceeasi adresa IP.

84
Adresa (adresa locala / adresa partener) – reprezinta adresele IP (valori pe 32
biti identificand in mod unic interfata IP, sau asa numitul Computer
“Friendly” Name) care identifica in mod unic unitatea de calcul (gazda,
locala si respectiv host, partener) . Aceasta afirmatie necesita o nuantare – in
realitate nu identifica unitatea de calcul, ci “unitatea de calcul pe o retea”.
O unitate de calcul poate avea mai multe placi de retea (mai multe placi de
ethernet, wireless etc.), deci ea se poate conecta la mai multe retele.
“Unitatea de calcul pe o retea” identifica unitatea de calcul in cauza, pe o
anumita retea (acel modul hardware – interfata IP - care face vizibila si
identificabila in mod unic unitatea de calcul pe o retea data). Cum am spus,
socket-ul este un capat de conexiune, aceasta trebuie sa existe pe o retea de
comunicatie (si se identifica pe acea retea cu adresa) si deoarece pe aceeasi
adresa pot exista mai multe socket-uri (aceeasi aplicatie sau mai multe
aplicatii pot deschide conexiuni pe acelasi modul hardware de conectare)
acestea se identifica intre ele prin port.
Global, exista mai multe module hardware de conectare la retea cu aceeasi
adresa (dar pe o retea adresele sunt unice), pe aceeasi retea pot exista mai
multe socket-uri cu acelasi port local dar nu pe aceeasi unitate de calcul
(sistemul de operare va permite alocarea uni port in mod unic).
In acest mod (prin adresa si port) se poate identifica socket -ul local si
respectiv socket-ul partener (remote) in vederea crearii conexiunii.

Modelul Server / Client al aplicatiilor de comunicatie prin socket

O aplicatie de comunicatie prin retea, ce foloseste socket -uri este o aplicatie

de tip client / server datorita faptului ca intregul mecanism de comunicatie
prin socket se bazeaza pe un model de tip client / server.

Pentru a folosi o interfata socket programele trebuie sa urmeze un proces

compus din cinci etape in cazul TCP si patru etape in cazul UDP:
 Crearea socket-ului,
 Configurarea socket-ului pentru a putea fi folosit
(conectarea la un host la distanta sau legarea la un port de local),
 Realizarea conexiunii cu socketul partener de
comunicatie – in cazul protocolului TCP (in cazul UDP nu exista
aceasta etapa)
 Transmiterea si/sau receptionarea datelor prin socket,
 Inchiderea socket-ului.

Relatia Client – Server in comunicatia prin socket-uri utilizand protocolul

TCP

85
Socket-ul ofera un mijloc de transport de date de tip full-duplex, deci la nivel
de transmitere/receptionare a datelor intre doua socket-uri, nu exista un
dezechilibru intre cei doi parteneri de comunicatie (partenerii sunt egali,
oricare poate initia o transmisie de date si celalalt le va receptiona).
In schimb, la nivelul realizarii conexiunii cei doi parteneri nu au r ol identic.
Stabilirea conexiunii pentru o comunicatie utilizand socket -uri se face prin
pozitionarea unui socket ca server si pozitionarea partenerului de comunicatie
in calitate de client.
Prin definitie modelul Client / Server implica: Server-ul ofera servicii, iar
Clientul apeleaza la serviciile Server-ului. In situatia comunicatiei prin
intermediul socket: socket-ul in pozitia Server ofera un singur serviciu –
receptioneaza cererile de conectare ale socket-ului Client sau socket-urilor
Clienti.
Serverul nu are initiativa in crearea unei conexiuni, acesta se gaseste in starea
de asteptare a cererilor de stabilire de conexiuni de la oricare Client („Listen”
– ascultare pasiva la un port a cererilor de conectare). Este in sarcina socket -
ului Client sa initieze cererea de conectare prin apelul metodei „Connect”.

Relatia Client – Server in comunicatia prin socket-uri utilizand protocolul

UDP

In acest caz clientii nu trebuie sa stabileasca o conexiune cu serverul pentru a

comunica, ci se trimit direct datagrame. In acelasi mod, serverul nu asteapta apeluri
de conexiune, ci asteapta sosirea datagramelor cu date de la clienti.

In cadrul mediului de programare Visual Basic socket-urile sunt

implementate intr-un obiect generic Winsock Control.

Implementarea comunicatiei prin socket-uri realizata (implementare realizata

sub mediul Visual Basic), se constituie intr-o componenta de tip ActiveX care
sa poata oferi functionalitatea de componenta de comunicatie prin socket, de
tip Client sau Server, cu protocol de tip TCP sau UDP.
Aceasta componenta ActiveX gestioneaza o instanta a unei clase
(SRV_clsWinsock) vizibila la nivel de applicatie client (client de ActiveX)
de nivel ierarhic superior. SRV_clsWinsock este parinte al unor instante ale
clasei copil – SRV_clsWinsockItem. Fiecare clasa copil detine un control
Windows Winsock (numit myWinsockCTL) rezident pe o forma proprie
copilului. Acesti copii sunt instantele implementarilor de socket, clasa parinte
avand doar rolul de a realiza o interfata unica intre o colectie de socket-uri si
programul de aplicatie de nivel inalt, cat si acela de a gestiona (crea si
distruge) instantele de tip copil.
Interfata unica este introdusa in scopul de a oferi aplicatiei care utilizeaza
ActiveX-ul o unica referinta la clasa de comunicatie (prin aceasta referinta se
pot capta toate evenimentele de la intregul set de socket -uri instantiate –
indiferent de numarul lor. Orice eveniment de la copii este transmis ca
eveniment catre parinte – insotit de un index de identificare a copilului care
emite acel eveniment).

86
Declararea variabilelor la nivel SRV_clsWinsockItem

'index de identificare copil

Private myIndex As Long
'referinta la clasa parinte
Private myWinsock As SRV_clsWinsock
'forma continand controlul Winsock
Private myfrmWinsockItem As SRV_frmWinsockItem
'referinta la controlul Winsock
Private WithEvents myWinsockCTL As Winsock

Private myIsServer As Boolean 'tipul de socket Server/Client

Private myIsUDP As Boolean
Private myRemotePort As Long
Private myRemoteHost As String
Private myLocalPort As Long
Private myLocalHost As String
'tipul protocolului UDP/TCP
'portul partenerului
'adresa partenerului
'portul local
'adresa locala

' metoda de initializare a controlului Winsock

Private Sub InitWinsockCTL()
On Error GoTo ErrorHandler 'in caz de eroare _
'(la inchidere socket)
While True
myWinsockCTL.Close 'inchidere socket
' setare protocol
myWinsockCTL.Protocol = IIf(myIsUDP, _
sckUDPProtocol, _
sckTCPProtocol)
If myIsUDP Then 'daca este UDP
myWinsockCTL.RemotePort = myRemotePort
myWinsockCTL.RemoteHost = myRemoteHost
myWinsockCTL.Bind myLocalPort, myLocalHost
If myIsServer Then 'daca este server UDP se inchide socket
myWinsockCTL.Close
End If
Else 'este protocol TCP
myWinsockCTL.Bind myLocalPort, myLocalHost
myWinsockCTL.Close 'inchidere socket
If myIsServer Then
myWinsockCTL.Listen 'Daca este Server
Else 'este client
myWinsockCTL.Connect myRemoteHost, myRemotePort
End If
End If
Exit Sub

87
ErrorHandler: 'in caz de eroare la inchidere socket
'se reancearca peste o secunda
Call sleep(1000)
Wend
End Sub

Metoda InitWinsockCTL() realizeaza initializarea controlului Winsock pentru

cazurile Server sau Client si pentru protocol de tip UDP sau TCP.
In cazul protocolului UDP comportamentele instantelor clasei
SRV_clsWinsockItem atat pentru Server cat si pentru Client sunt similare.
In cazul protocolului TCP, copii de tip SRV_clsWinsockItem se pozitioneaza
in trei categorii comportamentale:

- Server – o instanta cu comportament pasiv, care executa Listen (asculta pe un

port si o adresa la cererile de conectare ale unor clienti).

Server-ul de tipul (SRV_clsWinsockItem) poate primi un eveniment de cerere de

conectare de la un client

Private Sub myWinsockCTL_ConnectionRequest(ByVal requestID

As Long)
'informeaza parintele de aparitia unei cereri de
conectare
'cu identificatorul = requestID
Call myWinsock.OnEventConnectionRequest(myIndex, _
requestID)
End Sub

La nivel de clasa parinte (SRV_clsWinsock):

Declaratii:

Private myWinsockItem() As SRV_clsWinsockItem 'Colectia

copiilor

' Evenimentul de cerere de conectare prin care este

'informata aplicatia client de nivel ierarhic superior
Public Event EventConnectionRequest(ByVal Index As Long, _
ByVal requestID As
Long)

Friend Sub OnEventConnectionRequest(ByVal Index As Long, _

ByVal requestID As
Long)

88
 'se va crea o noua instanta copil - cu comportament de
'"Partener de Client"
'prin apelul metodei AddItem - care returneaza un index
al
'noii instante.
'Acestei instante ii este apelata metoda DoAccept
Call myWinsockItem(AddItem).DoAccept(requestID)
' informeaza aplicatia client de nivel ierarhic superior
' de aparitia cererii de conectare
RaiseEvent EventConnectionRequest(Index, requestID)
End Sub

- Partener de Client – o instanta cu comportament activ (transporta date), dar care

nu este Server (nu asculta la cereri de conectare) si nu este nici Client (nu poate
initia cereri de conectare).

La nivel de copil (SRV_clsWinsockItem)

Public Sub DoAccept(ByVal requestID As Long)

With myWinsockCTL
' Inchide conexiunea daca este deschisa
'(prin testare stare)
If .State <> sckClosed Then
Call DoClose
End If
Call .Accept(requestID)
End With
End Sub

- Client – o instanta cu comportament activ (transporta date), si care are abilitatea

de a initia cereri de conectare catre Server-ul ale carui identificatori (adresa si
port) le-a primit in faza de configurare.

Clientii sunt singurele instante asupra carora se pot implementa proceduri de refacere
a conexiunilor care s-au intrerupt. Clientii pot sa genereze o deconectare si o alta
cerere de conectare in cazul identificarii unor erori de comunicatie. Serverii sunt
pasivi si asteapta ca alte socket-uri sa se deconecteze respectiv sa ceara sa se
conecteze la ei. Partenerii de Clienti sunt in imposibilitatea de a regenera o

89
comunicatie. In cazul deconectarii Clientului, acesta informeaza clasa parinte, iar
aceasta este responsabila cu distrugerea instantei de Partener de Client.

Mecanism de Comunicatie OPC

OPC reprezinta abrevierea de la “OLE for Process Control”. OLE fiind

abrevierea de la “Object Linking and Embedding” – tehnica de “includere” a
“Obiectelor” in documente. Arhitecura OPC este bazata pe o abordare “obiectuala”
– un OPC fiind prin structura un “COM for Process Control” (COM – “Component
Object Module”).

Fig. 5.2 Mecanism OPC

“Interfata OPC” reprezinta o arhitectura software prin care programele de aplicatii

de tip control de proces, pot schimba informatii in mediul industrial. Interfata OPC
este o arhitectura prin care care se asigura schimbul de date intre hardware si
software de la diferiti producatori. Interfata OPC este localizata la nivel inferior
programelor de aplicatii – ea fiind un suport de comunicatie cu celelate aplicatii
din mediului industrial. Scopul introducerii acestui nivel ( Interfata OPC) este acela
ca aplicatiile de tip control de proces sa utilizeze un mecanism de tip unic de
schimb de date sau evenimente cu celelalte module ale mediului industrial
(independent de caracteristicile lor structurale sau functionale, sau de
caracteristicile de comunicatie – protocol, suport de comunicatie)

Din punct de vedere structural, Interfetele OPC au o arhitectura Client / Server.

OPC Server: - Componentele OPC care furnizeaza servicii unei alte componente
prin intermediul unei interfete. Acestea implementeaza interfata cu sistemele de
comunicatie existente si de asemenea schimba informatii cu clientul OPC.

90
OPC Client: - Componentele OPC care acceseaza unul sau mai multe servere
OPC ca sursa de servicii.
In pricipiu Client-ul OPC, care este atasat nivelului de aplicatie, are o
interfata de tip standard cu Server-ul OPC. Server-ul OPC ofera servicii
Clientilor OPC dar este responsabil si cu implementarea interfetei (cu un
puternic caracter non standard) cu modulele (mediului industrial) pentru care
acest OPC Server este dedicat. Aceasta inseamna ca prin intermediul acestei
abordari - nivelul de aplicatie este facut insensibil la modificari in detaliile
de implementare ale modulelor de la nivelele inferioare.
Producatorul de “module de date de proces” (module hardware care sunt
sursa de date de la proces sau/si destinatie de date catre proces) pune la
dispozitie server-ul OPC pentru aceste module.

OPC Foundation a creat pentru domeniul automatizarilor urmatoarele

specificatii:
 Accesul datelor: schimbul de date prin intermediul
variabilelor de proces
 Alarme si evenimente: servicii de alarme si evenimente
 Acces date XML: schimb de date prin intermediul
Internet
 Schimbul de date: schimbul de date intre serverele
OPC.
 Lucrul cu retete: procesare de secvente de sevicii
(batch)
 Accesul la datele arhivate

Ca interfata a sistemelor in comunicatii industriale, Server-ele OPC asigura

functionalitatea:
 acesului de date de proces,
 serviciilor de alarme si evenimente,
 accesului de date XML
 schimbului de date (Data Exchange).

Acces de Date OPC (OPC Data Access): reprezinta o specificatie pentru

accesul la date de proces utilizand variabile: Un Server OPC asigura pentru
accesul de date:
 Citirea valorilor uneia sau mai multor variabile de
proces
 Modificarea valorilor uneia sau mai multor variabile de
proces, prin inscrierea unor noi valori

91
  Monitorizarea valorilor uneia sau mai multor variabile
de proces
 Semnalarea schimbarilor de valori

Modelul ierarhic al claselor, pentru OPC Data Acces contine trei nivele (trei
nivele de clase):
 OPC Server
 OPC Group
 OPC Item

Fig. 5.3 Modelul ierarhic OPC

Aplicatia client va crea o instanta a clasei OPC Server. Crearea instantelor
claselor copii se face prin apelul unei metode dedicate a clasei parinte
(construirea unei instante a clasei OPC Group se face printr-o metoda a clasei
OPC Server, iar construirea unei instante a clasei OPC Item se face prin
intermediul clasei OPC Group).

Clasa OPC Group - Orice instanta a clasei OPC Group are ca parinte o clasa
OPC Server si structureaza variabile de proces utilizate de OPC Server. Se
pot defini mai multe instante ale OPC Group, avand aceeasi clasa parinte. In
acest fel se poate defini o partitionare a multimii de variabile de proces
(utilizate de aplicatia client) in submultimi alocate fiecare unui OPC Group
(spre exemplu – variabilele continute intr-un ecran de aplicatie pot sa fie
alocate aceluiasi OPC Group). OPC Group defineste operatii de citire si
scriere a variabilelor de proces alocate.
Clasa OPC Item – Orice instanta a clasei OPC Item are ca parinte o clasa
OPC Group si reprezinta o variabila de proces. O variabila de proces este un
element (item) in spatiul de “nume” de variabile ale OPC Server, si este
identificata in mod unic printr-un “nume” ItemID.
Fiecare Item are asociate urmatoarele proprietati:

92
  Value (ultima valoare achizitionata a variabilei)
 Quality (este un indicator de calitate a procesului
achizitiei, aratand gradul de certitudine a valorii citite)
 Time Stamp (momentul de timp cand a fost
achizitionata valoarea actuala a variabilei)

Variabilele de proces sunt elemente de date de proces de tip Intrare/Iesire

(I/O), care pot sa fie citite si/sau scrise. In cadrul modelului ierahic de clase
al OPC Server, variabilele sunt reprezentate de clasa OPC Item. Doar
elementele acestei clase sunt valori reale ale procesului OPC.
O variabila de proces este reprezentata in mod unic de ItemID – un string de
caractere. Fiecare ItemID specifica server-ului variabila de proces care este
alocata fiecarei instante OPC Item. Prin intermediul clasei OPC Item,
aplicatia client are acces la variabila de proces.

OPC Server al SIMATIC NET utilizeaza (pentru identificarea diferitelor

servicii de comunicatie) segmente ale ItemID ca parametri de apel ai functiei
de comunicatie. Un ItemID este compus din:

<protocolID>:[<connectionname>]<variablename>

 <protocolID> - specifica protocolul (DP, PROFIBUS, Industrial

Ethernet, FMS, SNMP, etc ) utilizat pentru accesul variabilelor de proces.
 <connectionname> - identifica conexiunea sau modulul de
comunicatie prin care partenerul de comunicatie (PLC, PC, DP) poate fi
accesat.
 <variablename> - variabila adresata.

Tipuri de acces la variabilele de proces

Exista doua tipuri de acces ale clasei OPC Item la variabilele de proces:
Acces Sincron si Acces Asincron.
Atat pentru accesul de tip Sincron cat si pentru cel de tip Asincron exista
doua moduri de acces la variabilele de proces: citire (Read) si scriere (Write).

Accesul de tip Sincron versus Accesul de tip Asincron

Accesul sincron:
 mecanismul de acces sincron: applicatia client apeleaza
functia de citire sau functia de scriere a unor variabile de proces,
printr-un apel de subrutina (metoda) a clasei OPC Item

93
 corespunzatoare acelei variabile. Intoarcerea din metoda apelata se
face cand procesul de citire sau scriere a luat sfarsit.
 avantaje: asigura cea mai mare viteza posibila a
schimbului de date intre OPC Server si OPC Client (deoarece, in
cadrul procesului de acces, exista un singur transfer de date intre
aceste doua componente).
 dezavantaje: aplicatia client este intrerupta
(suspendata) in timpul executiei accesului sincron. Atata timp cat
accesul de tip sicron nu este utilizat in propriul sau “fir de executie”
(thread), executia aplicatiei client este suspendata.

Accesul asincron:
 mecanismul de acces asincron: applicatia client
porneste procesul de citire sau functia de scriere a unor variabile de
proces, printr-un apel de subrutina (metoda) a clasei OPC Item
corespunzatoare acelei variabile. Intoarcerea din metoda apelata se
face imediat, indicand daca procesul de transfer a sarcinilor catre OPC
Server a fost terminat cu succes. Dupa aceasta aplicatia client continua
executia. OPC Server asociaza un identificator (TransactionID)
sarcinilor apelate, urmand ca aplicatia client sa identifice raspunsul
primit pentru aceasta tranzactie prin acest identificator. In momentul
in care tranzactia ceruta a luat sfarsit, OPC Server apeleaza cu unul
din parametri TransactionID, functia AsyncReadComplete in cazul in
care operatia a fost de citire (Read) sau functia AsyncWriteComplete
in cazul in care operatia ceruta a fost de scriere (Write). Timpul de
trimitere a unui raspuns de catre OPC Server, este nedefinit, si nu este
dependent de aplicatia OPC Client (este dependent doar de capacitatea
suportului de comunicatie).
 avantaje: aplicatia client practic nu este intrerupta de
apelul functiilor de citire si scriere a variabilelor de proces. Pentru un
numar mare de variabile de proces, sau in conditiile unui suport de
comunicatie susceptibil de saturare acest tip de acces este practic
singura optiune.
 dezavantaje: viteza schimbului de date intre OPC
Server si OPC Client este mai mica decat in cazul accesului sincron
(deoarece, in cadrul procesului de acces, exista doua transferuri de
date intre aceste doua componente)

Accesul Sincron la variabilele de proces

Exemplul 1. Comunicatia sincrona:

94
 Fig. 5.4 Mecanismul comunicatiei sincrone

Pentru a putea crea o instanta a clasei “OPCItem”, este necesara o instanta a

clasei “OPCGroup”. Acest lucru este posibil daca exista o instanta a clasei
“OPCServer” si conexiunea cu serverul de OPC a fost stabilita.

Variabile globale:

Dim WithEvents ServerObj As OPCServer

Dim WithEvents GroupObj As OPCGroup
Dim ItemObj As OPCItem

Generarea unei instante al clasei OPCServer ( se genereaza o noua instanta a

clasei OPCServer)

Set ServerObj = New OPCServer

Stabilirea unei conexiuni cu OPC Server al SIMATIC NET:

ServerObj.Connect (”OPC.SimaticNET”)

metoda Connect (a clasei OPCServer):

Sub Connect(ProgID As String, [Node])

95
Adaugarea unui grup (fiecare instanta a clasei OPCServer are o colectie de
obiecte OPCGroups ):

Set GroupObj = ServerObj.OPCGroups.Add(”MyOPCGroup”)

Function Add([Name]) As OPCGroup

Adaugarea unui Item (variabila de proces) (fiecare instanta a clasei

OPCGroup contine o colectie de obiecte OPCItems)

Set ItemObj =GroupObj.OPCItems.AddItem(”S7:[DEMO]MW1”,

1)
Function AddItem(ItemID As String, ClientHandle As Long)
As OPCItem

Citirea sincrona (se foloseste metoda Read a clasei OPCItem):

Dim myValue As Variant

Dim myQuality As Variant
Dim myTimeStamp As Variant

ItemObj.Read OPCDevice, myValue, myQuality, myTimeStamp

Declararea metodei Read:

Sub Read(Source As Integer, [Value], [Quality],

[TimeStamp])

Source ”OPCDevice” este o constanta definita in

structura OPCDataSource
Value intoarce parametrul care contine valoarea
variabilei.
Quality intoarce parametrul care contine informatii
referitoare la integritatea datelor dupa o citire cu
succes.
TimeStamp specifica momentul ultimei modificari a
valorii variabilei citite.

Scrierea sincrona:
Declararea si initializarea de variabile locale:

Dim Serverhandles(1) As Long

Dim MyValues(1) As Variant
Dim MyErrors() As Long

96
 LongServerhandles(1) = ItemObj.ServerHandle
GroupObj.SyncWrite 1, Serverhandles, MyValues, MyErrors

Metoda SyncWrite a clasei OPCGroup scrie in mod sincron valorile

variabilelor de proces specificate in OPC items:

Sub SyncWrite(NumItems As Long,

ServerHandles() As Long,
Values() As Variant,
Errors() As Long)

NumItems - numarul variabilelor de proces

Values - valorile care se vor scrie
Errors - include codurile de eroare

Functia GetErrorString a clasei OPCServer converteste un cod de eroare intr -

un string:
Function GetErrorString(ErrorCode As Long) As String

Functia GetQualityText furnizeaza pentru fiecare cod de eroa re un mesaj de

eroare

Private Function GetQualityText(Quality) As String

Select Case Quality
Case 0: GetQualityText = “BAD”
Case 64: GetQualityText = “UNCERTAIN”
Case 192: GetQualityText = “GOOD”
Case 8: GetQualityText = “NOT_CONNECTED”
Case 13: GetQualityText = “DEVICE_FAILURE”
Case 16: GetQualityText = “SENSOR_FAILURE”
Case 20: GetQualityText = “LAST_KNOWN”
Case 24: GetQualityText = “COMM_FAILURE”
Case 28: GetQualityText = “OUT_OF_SERVICE”
Case 132: GetQualityText = “LAST_USABLE”
Case 144: GetQualityText = “SENSOR_CAL”
Case 148: GetQualityText = “EGU_EXCEEDED”
Case 152: GetQualityText = “SUB_NORMAL”
Case 216: GetQualityText = “LOCAL_OVERRIDE”
Case Else: GetQualityText = “UNKNOWN ERROR”
End Select

97
 End Function

Accesul Asincron la variabilele de proces

Exemplul 2: Comunicatia asincrona:

Fig. 5.5 Mecanismul comunicatiei asincrone

Pentru a putea crea o instanta a clasei “OPCItem”, este necesara o instanta a

clasei “OPCGroup”. Acest lucru este posibil daca exista o instanta a clasei
“OPCServer” si conexiunea cu serverul de OPC a fost stabilita.

Declararea de constante si variabile globale:

Const WRITEASYNC_ID = 1
Const READASYNC_ID = 2
Const REFRESHASYNC_ID = 3

Public WithEvents ServerObj As OPCServer

Public WithEvents GroupObj As OPCGroup
Dim ItemObj1 As OPCItem
Dim ItemObj2 As OPCItem
Dim Serverhandle(2) As Long

Generarea unui obiect al clasei OPCServer

Set ServerObj = New OPCServer

98
Stabilirea unei conexiuni cu serverul OPC al SIMATIC NET

ServerObj.Connect (”OPC.SimaticNET”)

Conectarea:

Sub Connect(ProgID As String, [Node])

ProgID – specifica numele (unic) al OPCServer.

Node – specifica serverul atunci cand se utilizeaza DCOM

Adaugarea unui grup:

Fiecare instanta a clasei OPCServer are o colectie de obiecte OPCGroups.

Functia Add adauga un obiect de tipul OPCGroup.

Set GroupObj = ServerObj.OPCGroups.Add(”MyOPCGroup”)

Function Add([Name]) As OPCGroup

Setarea proprietatii IsSubscribed

Proprietatea IsSubscribed a clasei OPCGroup trebuie setata True in cazul

transmisiei asincrone.

GroupObj.IsSubscribed = True

Adaugarea de Item-uri

Fiecare instanta a clasei OPCGroup contine o colectie de obiecte de tipul

OPCItems. Functia AddItem creeaza un nou obiect al clasei OPCItem.

Set ItemObj1=GroupObj.OPCItems.AddItem(”S7:[DEMO]MB1”,
1)
Set ItemObj2=GroupObj.OPCItems.AddItem(”S7:[DEMO]MW3”,
2)

Function AddItem(ItemID As String, ClientHandle As Long)

As OPCItem

Citirea asincrona:

Dim ClientID As Long

99
 Dim ServerID As Long
Dim ErrorNr() As Long
Dim ErrorString As String
ClientID = READASYNC_ID

La apelarea metodei AsyncRead a clasei OPCGroup se incepe citirea

asincrona.
Daca metoda AsyncRead returneaza un cod de eroare diferit de 0, se
utilizeaza GetErrorString pentru a obtine mesajul de eroare.

GroupObj.AsyncRead 1, Serverhandle, ErrorNr, ClientID,

ServerID
If ErrorNr(1) <> 0 Then
ErrorString = ServerObj.GetErrorString(ErrorNr(1))
MsgBox ErrorString, vbCritical, ”Error AsyncRead()”
End If
Erase ErrorNr

Sub AsyncRead(NumItems As Long,

ServerHandles() As Long,
Errors() As Long,
TransactionID As Long,
CancelID As Long)

NumItems - numarul variabilelor de proces care vor fi

citite.
Errors – furnizeaza codul de eroare
TransactionID – pentru identificarea tranzactiei
asincrone.

Scrierea asincrona:

La apelarea metodei AsyncWrite a clasei OPCGroup se incepe scrierea

asincrona.
In cazul in care metoda AsyncWrite returneaza un cod de eroare diferit de 0,
se utilizeaza GetErrorString pentru a vizualiza mesajul de eroare.

Dim Serverhandles(1) As Long

Dim MyValues(1) As Variant

100
 Dim ErrorNr() As Long
Dim ErrorString As String
Dim Cancel_id As Long
MyValues(1) = Edit_WriteVal

GroupObj.AsyncWrite 1, Serverhandle, MyValues, _

ErrorNr, WRITEASYNC_ID, Cancel_id
If ErrorNr(1) <> 0 Then
ErrorString = ServerObj.GetErrorString(ErrorNr(1))
MsgBox ErrorString, vbCritical, “Error AsyncRead()”
End If
Erase ErrorNr

Sub AsyncWrite(NumItems As Long,

ServerHandles() As Long,
Values() As Variant,
Errors() As Long,
TransactionID As Long,
CancelID As Long)

NumItems - numarul variabilelor de proces care vor fi

scrise.
Values - valorile care vor fi scrise.
Errors – furnizeaza codul de eroare
TransactionID – pentru identificarea tranzactiei
asincrone.

Descrierea Metodei AsyncReadComplete

Event AsyncReadComplete(TransactionID As Long,

NumItems As Long,
ClientHandles() As Long,
ItemValues() As Variant,
Qualities() As Long,
TimeStamps() As Date,
Errors() As Long)

NumItems - numarul de variabile care vor fi citite.

101
 ItemValues - contine valorile variabilelor care s-au
modificat.
Qualities - informatii despre integritatea datelor.

Implementarea metodei AsyncReadComplete

Dim ErrorString As String

If (TransactionID = READASYNC_ID) Then
If Errors(1) = 0 Then
Edit_ReadVal = ItemValues(1)
Edit_ReadQu = GetQualityText(Qualities(1))
Edit_ReadTS = TimeStamps(1)
Else
ErrorString = ServerObj.GetErrorString(Errors(1))
MsgBox ErrorString, vbCritical,
“Error AsyncReadComplete()”
End If
End If

Descrierea Metodei AsyncWriteComplete

Event AsyncWriteComplete(TransactionID As Long,

NumItems As Long, ClientHandles() As Long, Errors() As
Long)

NumItems - numarul de variabile care vor fi citite.

Dim ErrorString As String

If (TransactionID = WRITEASYNC_ID) Then
If Errors(1) = 0 Then
Edit_WriteRes = ServerObj.GetErrorString(Errors(1))
Else
ErrorString = ServerObj.GetErrorString(Errors(1))
MsgBox ErrorString, vbCritical,
”Error AsyncWriteComplete()”
End If
End If

Descrierea Metodei DataChange

102
 Event DataChange(TransactionID As Long,
NumItems As Long,
ClientHandles() As Long,
ItemValues() As Variant,
Qualities() As Long,
TimeStamps() As Date)
MsgBox ErrorString, vbCritical,
”Error AsyncWriteComplete()”
End If
End If

Implementarea metodei DataChange

Dim i As Long
For i = 1 To NumItems
Edit_OnDataVal(i - 1) = ItemValues(i)
Edit_OnDataQu(i - 1) = GetQualityText(Qualities(i))
Edit_OnDataTS(i - 1) = TimeStamps(i)
Next i

GetQualityText – specifica fiecare cod de eroare

Private Function GetQualityText(Quality) As String

Select Case Quality
Case 0: GetQualityText = “BAD”
Case 64: GetQualityText = “UNCERTAIN”
Case 192: GetQualityText = “GOOD”
Case 8: GetQualityText = “NOT_CONNECTED”
Case 13: GetQualityText = “DEVICE_FAILURE”
Case 16: GetQualityText = “SENSOR_FAILURE”
Case 20: GetQualityText = “LAST_KNOWN”
Case 24: GetQualityText = “COMM_FAILURE”
Case 28: GetQualityText = “OUT_OF_SERVICE”
Case 132: GetQualityText = “LAST_USABLE”
Case 144: GetQualityText = “SENSOR_CAL”
Case 148: GetQualityText = “EGU_EXCEEDED”
Case 152: GetQualityText = “SUB_NORMAL”
Case 216: GetQualityText = “LOCAL_OVERRIDE”
Case Else: GetQualityText = “UNKNOWN ERROR”

103
 End Select
End Function

Mecanism de Comunicatie HLI Interbus

INTERBUS a fost dezvoltata de Phoenix Contact in 1993 si a devenit

un standard industrial pentru transmiterea de date intre d iferite tipuri de
sisteme de control.

Descriere HLI (High-Level Language Interface) Interbus

HLI (High-Level Language Interface) ofera utilizatorului o interfata de

programare. Se bazeaza pe DDI (Device Driver Interface) de la Phoenix
Contact. HLI converteste apelurile de functii din aplicatie in proceduri
complexe de comunicatie cu modulul de control al magistralei INTERBUS.
Functionalitatea integrata a HLI este urmatoarea:
 initializarea modulul de control al magistralei si
pornirea INTERBUS
 managementul datelor de proces
 managementul erorilor si evenimentelor
 controlul INTERBUS
 managementul serviciilor PCP
 servicii de informare

Initializarea modulului de control al magistralei si pornirea INTERBUS

HLI ofera doua posibilitati de pornire a INTERBUS.

Initializare standard
Modulul de control al magistralei INTERBUS incepe transmisia cu
configuratia fizica disponibila a magistralei.
Initializare cu configuratie specificata

Managementul datelor de proces

HLI pemite transferul datelor de proces in variablie declarate in programul-

aplicatie. In acest fel este posibila programarea usoara a functiilor de control.
Sunt necesare trei etape pentru a transfera datele de proces:
 declararea obiectelor de tip date de proces (PDO)
 iregistrarea obiectelor de tip date de proces

104
  actualizarea obiectelor de tip date de proces
inregistrate

1. Declararea obiectelor de tip date de proces (PDO)

Pentru a declara obiecte de tip date de proces, HLI defineste urmatoarele

tipuri de date:

T_IBS_BOOL : Boolean object (bit object)

(Visual Basic: Boolean)
T_IBS_BITSTRING : Bit string object (1 ... 16 bits)
(Visual Basic: Integer)
T_IBS_BYTE : Byte object (8-bit object)
(Visual Basic: Byte)
T_IBS_WORD : Word object (16-bit object)
(Visual Basic: Integer)
T_IBS_DWORD : Double-word object (32-bit object)
(Visual Basic: Long)

2. Inregistrarea obiectelor de tip date de proces

Inregistrarea obiectelor de tip date de proces este caracterizata prin faptul ca

unui obiect de tip date de proces declarat in aplicatie ii este alocata o imagine
a unui dispozitiv INTERBUS.
Inregistrarea obiectelor de tip date de proces cuprinde:
 numarul logic (numarul segmentului si pozitia
segmentului) al dispozitivului
 tipul datelor (intrare sau iesire)
 offsetul octetului din zona datelor de proces a
dispozitivului
 lungimea bitului si pozitia bitului (pentru obiecte pe
bit)

3. Actualizarea obiectelor de tip date de proces inregistrate

Managementul datelor de proces de intrare este diferit fata de cel al datelor

de iesire. Actualizarea obiectelor de intrare (transferul imaginii intrarilor de
proces in obiecte de intrare), si transferul obiectelor de iesire (transferul
starilor obiectelor de iesire la imaginea iesirilor de proces) sunt controlate de
aplicatie si se realizeaza separat.

Managementul evenimentelor

Actiuni ale magistralei, mesaje sau erori sunt evenimente pe care HLI le
codeza intr-o inregistrare de date de tip eveniment si le stocheaza intr-o lista
interna FIFO. Evenimentele sunt clasificate dupa cum urmeaza:

105
  erori interne (de ex., daca nu este destul spatiu de
memorie)
 erori ale DDI
 erori ale modulului de control al magistralei
 erori ce cauzeaza oprirea magistralei
 mesaje de la dispozitive
 controlul schimbarii starii INTERBUS
 erori de comunicare PCP
 erori de aplicatie

Specificarea unui grup de filtre de evenimente permite determinarea

evenimentelor care vor fi indicate in aplicatie.

Controlul INTERBUS

Pentru controlul sistemului INTERBUS, sunt disponibile urmatoarele

servicii:
 start, stop si alarm stop pentru transferul de date pe
magistrala
 comutarea segmentelor de magistrala

Servicii de informare

HLI permite cererea urmatoarelor informatii despre sistemul HLI:

 informatii despre modulul de control al magistralei
 statistici de diagnoza
 configuratia magistralei
 informatii despre dispozitive

Functii HLI

1. Initializarea modulul de control al magistralei si pornirea INTERBUS

Interbus permite initializarea magistralei in doua moduri:

 initializare standard
 initializare cu configuratie data
Initializarea standard - initializeaza modulul de control al magistralei si
managementul HLI asociat fara a specifica o configuratie de magistrala.
Modulul de control al magistralei citeste configuratia si o activeaza,

106
presupunand ca o configuratie operabila de magistrala este conectata la
modulul de control al magistralei. Dupa executia cu succes a functiei de
initializare, modulul de control al magistralei este in starea “Activ”. Ciclurile
de date nu sunt pornite inca, fiind necesar apelul functiei
“HLI_IBS_StartBus”.

Apelare: IBS_HLI_Init ( CID, lpState, ibs_mode )

CID: USIGN16
ID-ul controller board-ului ce trebuie initializat:
ISASC1 ... ISASC4: IBS PC ISA SC - board 1 ... 4
ETHDSC1 ... ETHDSC4: IBS ETH DSC - controller board
1 ... 4
SCCOP: IBS PC ISA SC/486DX
lpState: Pointer la T_HLI_STATE
HLI transfera starea sistemului INTERBUS la un
obiect de tipul T_HLI_STATE din programul-aplictie.
Ibs_mode: USIGN16
Modurile de operare ale sistemului INTERBUS:
IBS_STANDARD: Modul de operare standard
IBS_CONTROLLED : Operarea magistralei prin
aplicatiei
Return value: HLI_OKAY: Initializare reusita

2. Inregistrarea obiectelor de tip date de proces

Pentru accesarea datelor de proces, sunt disponibile urmatoarele tipuri de

obiecte de tip date de proces:

– T_IBS_BOOL Obiect de tip date de proces digital reprezentand

(Visual Basic: Boolean) starea unui bit in
imaginea datelor de proces
– T_IBS_BITSTRING Obiect de tip date de proces multi-bit
(Visual Basic: Integer) reprezentand starea a n (=
2 pana la 15) biti din imaginea datelor de proces
– T_IBS_BYTE Obiect de tip date de proces pe 8 biti
(Visual Basic: Byte) reprezentand starea unui byte
in imaginea datelor de proces
– T_IBS_WORD Obiect de tip date de proces pe 16 biti
(Visual Basic: Byte) reprezentand starea unui word
in imaginea datelor de proces
– T_IBS_DWORD Obiect de tip date de proces pe 32 biti
(Visual Basic: Byte) reprezentand starea unui
doubleword in imaginea datelor de proces

107
3. Functii pentru inregistrarea datelor de proces

IBS_HLI_RegisterPDO_BOOL( Controller_ID,IBS_PDO_INPUT
or_IBS_PDO_OUTPUT,
Segment, Position, Byte_Offset, Bit_Position,
Reference_to_Object,
Reference_to_State_Changed_Indication_Variable)

IBS_HLI_RegisterPDO_BITSTRING(Controller_ID, IBS_PDO_INPUT or
IBS_PDO_OUTPUT, Segment, Position, Byte_Offset,
Bit_Position,
Bit_Length, Reference_to_Object,
Reference_to_State_Changed_ Indication_Variable)

IBS_HLI_RegisterPDO_BYTE( Controller_ID, IBS_PDO_INPUT or

IBS_PDO_OUTPUT,
Segment, Position, Byte_Offset, Reference_to_Object,
Reference_to_State_Changed_Indication_Variable)

IBS_HLI_RegisterPDO_WORD( Controller_ID, IBS_PDO_INPUT or

IBS_PDO_OUTPUT, Segment, Position, Byte_Offset,
Reference_to_Object,
Reference_to_State_Changed_Indication_Variable)

IBS_HLI_RegisterPDO_DWORD( Controller_ID, IBS_PDO_INPUT or I

BS_PDO_OUTPUT, Segment, Position, Byte_Offset,
Reference_to_Object,
Reference_to_State_Changed_Indication_Variable)

4. Prelucrarea datelor de proces

Citirea datelor de intrare

La apelarea functiei
IBS_HLI_PD_In( Controller_ID)
HLI citeste imaginea curenta a datelor de intrare proces ale modulului de
control al magistralei INTERBUS si actualizeaza toate obiectele inregistrate,
de tip date de intrare.

Apelarea functiei
IBS_HLI_PD_DeviceIn( Controller_ID, Segment, Position)
permite actualizarea valorilor obiectelor de intrare de tip date de proces de la
un dispozitiv specificat direct din imaginea curenta a procesului.

Apelarea functiei

108
IBS_HLI_PD_Input( Controller_ID, Reference_to_Object)
permite actualizarea unui obiect individual de intrare de tip date de proce s
direct din imaginea curenta a procesului.

Scrierea datelor de iesire

La apelarea functiei
IBS_HLI_PD_Out( Controller_ID)
HLI transmite valorile curente ale obiectelor de tip date de proces la imaginea
de iesire a procesului INTERBUS.
Apelarea functiei
IBS_HLI_PD_DeviceOut( Controller_ID, Segment, Position)
permite transferul valorii unui obiect de iesire de tip date de proces direct la
imaginea curenta a procesului.

Apelarea functiei
IBS_HLI_PD_Output( Controller_ID, Reference_to_Object)
permite transferul valorii unui obiect de iesire de tip date de proces la
imaginea curenta a procesului.

5. Controlul INTERBUS

Pornirea transferului de date

Dupa initializarea reusita a sistemului INTERBUS, transferul de date poate fi

pornit prin apelarea functiei:

result = IBS_HLI_StartBus( Controller_ID).

In cazul in care executia functiei a fost reusita, valoarea returnata este

HLI_OKAY.

Oprirea transferului de date

Transferul de date INTERBUS poate fi oprit prin apelul functiei:

result = IBS_HLI_StopBus( Controller_ID).

In cazul in care executia functiei a fost reusita, valoarea returnata este

HLI_OKAY.

6. Tratarea erorilor si evenimentelor

Daca o functie HLI nu a fost procesata corect, valoarea returnata

corespunzatoare functiei este diferita de HLI_OKAY. In functie de tipul

109
erorii si de functia ce a generat-o, aceasta (functia apelata) genereaza unul
sau mai multe evenimente ce pot fi citite pentru informatii suplimentare.

Citirea evenimentelor

Elementul EventIndication informeaza aplicatia de evenimentele aparute.

Odata cu aparitia unui nou eveniment, HLI incrementeaza valoarea acestui
element.

result = IBS_HLI_GetEventInfo( Controller_ID,

Reference_to_Event)

unde Reference_to_Event este un obiect de tipul T_HLI_EVENT.

Functia determina aplicatia sa citeasca datele evenimentelor in ordine

cronologica. Cu fiecare apelare reusita a functiei valoarea elementului
EventIndication este decrementata. Deci valoarea elementului
EventIndication indica numarul de evenimente care nu au fost inca citite de
aplicatie.

Setarea unui filtru de evenimente

Evenimentele sunt clasificate in urmatoarele grupuri:

– HLI_EG_INTERNAL: Erori interne, de exemplu daca nu este
destul spatiu de memorie
– HLI_EG_DDI: Erori ale DDI (Device Driver Interface)
– HLI_EG_CTRL: Erori ale controller board-ului
– HLI_EG_BUSFAULT: Erori cauzate de intreruperea magistralei
– HLI_EG_DEVICES: Mesaje de la dispozitive
– HLI_EG_BUSSTATE: Schimbari ale starii magistralei INTERBUS
– HLI_EG_APP: Erori de aplicatie
– HLI_EG_ALL: Toate grupurile de evenimente

Prin setarea filtrelor, aplicatia determina tipul evenimentelor care sa fie

stocate si indicate aplicatiei.

La apelarea functiei:

IBS_HLI_DisableEvents( Controller_ID,Group_Code_Combination)
grupurile de evenimente sunt dezactivate. Acestea sunt activate prin apelarea
functiei:

IBS_HLI_EnableEvents( Controller_ID, Group_Code_Combination)

110
Fereastra de evenimente

HLI permite deschiderea unei ferestre de evenimente pentru fiecare controller

de magistrala INTERBUS. Aceasta fereastra indica starea controllerului de
magistrala INTERBUS si evenimnetele aparute.

Apelarea functiei:
IBS_HLI_CreateLogWindow(Controller_ID,Language_Code,Filter_Setting_P
ossible)
determina crearea ferestrei de evenimente pentru Controller_ID.
unde:
Filter_Setting_Possible = 0 => nu este posibila filtrarea evenimnetelor
Filter_Setting_Possible ≠ 0 => filtrarea evenimentelor este posibila

111