Implementarea Api Pentru Diverse Module de Comunicatie

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.

Fig. 5.1 Mecanism de comunicatie DDE

Prin adoptarea acestui mecanism de transmisie de date intre 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 datele 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 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 executie) 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.

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 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), 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.

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

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 rol 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).

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 'tipul protocolului UDP/TCP

Private myRemotePort As Long 'portul partenerului

Private myRemoteHost As String 'adresa partenerului

Private myLocalPort As Long 'portul local

Private myLocalHost As String '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

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)

'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 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.

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

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:

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 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:

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])

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

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 eroare 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

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

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

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

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.

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

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”

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 diferite 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

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:

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, 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

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

IBS_HLI_PD_Input( Controller_ID, Reference_to_Object)

permite actualizarea unui obiect individual de intrare de tip date de proces 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 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)

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_Possible)

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