Prezentarea platformei NI CompactRIO (Partea a II-a)

by donpedro

Aspecte ale arhitecturii de bază, a unui controller


Dezvoltarea sistemelor complexe necesită o arhitectură care permite reutilizarea codului, asigură scalabilitate şi capacitate de administrare a execuţiei. Următoarele două secţiuni prezintă modul de dezvoltare a unei arhitecturi de bază pentru aplicaţiile de control precum şi tehnici de implementare a unei bucle simple PID utilizând această arhitectură.

O arhitectură de bază a unui controller are trei stări principale:
1. Iniţializare (administrare internă)
2. Control (I/O şi drivere de comunicaţie, tabel de memorie, sarcini de control şi măsurare)
3. Shutdown (administrare internă)

Figura 2.1. Cele trei stări principale ale arhitecturii de bază specifice unui controller

Rutina de iniţializare


Înainte de execuţia buclei principale de control, programul trebuie să efectueze o rutină de iniţializare. Aceasta pregăteşte controller-ul pentru execuţie şi nu se referă la logica caracteristică maşinii, precum logica pentru pornirea sau iniţializarea automatului. Acest tip de logică ar trebui să treacă în bucla principală de control.

Această rutină de iniţializare:
1. Setează toate variabilele interne la stări implicite.
2. Creează orice structuri de programare necesare pentru operare, inclusiv şiruri, memorii tampon de tip FIFO (primul intrat, primul ieşit) în timp real, numere logice VI şi downloadare de fişiere bitstream FPGA.
3. Îndeplineşte orice logică suplimentară definită de utilizator pentru a pregăti controller-ul pentru operare, precum pregătirea fişierelor jurnal.

Rutina de control

I/O, communicaţii şi tabel de memorie
Mulţi programatori sunt familiarizaţi cu accesul direct I/O, în timpul căruia, subrutinele trimit şi primesc în mod direct intrările şi ieşirile de la hardware. Această metodă este ideală pentru achiziţia de forme de undă şi procesare a semnalului, cât şi pentru aplicaţiile mai mici, într-un singur punct. Totuşi, aplicaţiile de control utilizează în mod normal citiri şi scrieri de fişiere într-un singur punct şi pot deveni extrem de complexe, având stări multiple – dintre care toate au nevoie de acces la I/O. Accesarea I/O cauzează suprasarcină în sistem şi îl poate încetini. În plus, administrarea de accese I/O multiple pe toate nivelurile programului, îngreunează considerabil schimbarea intrărilor/ieşirilor şi implementarea caracteristicilor de simulare sau forţare. Pentru evitarea acestor probleme, rutina de control utililzează o arhitectură de scanare I/O. În acest tip de arhitectură, puteţi accesa hardware-ul fizic doar o dată per fiecare iteraţie a buclei utilizând I/O şi divere de comunicaţie (marcate drept „IO” şi „Comm Drivers” în figura 2.1). Valorile de input şi output sunt stocate într-un tabel de memorie, iar sarcinile de măsurare şi control accesează spaţiul de memorie în loc să acceseze direct hardware-ul.

Acest tip de arhitectură prezintă numeroase beneficii:
• Abstractizare I/O, astfel încât puteţi reutiliza subVI-urile şi funcţiile (fără a coda I/O-urile în sistem hadware)
• Overhead scăzut
• Operare deterministă
• Suport pentru simulare
• Suport pentru “forţare”
• Eliminarea riscului de schimbări de I/O în timpul execuţiei logice

Sarcini de control şi măsurare
Sarcinile de control şi măsurare reprezintă logica specifică automatului de stare care defineşte aplicaţia de control. Aceasta poate însemna fie controlul procesului, sau controlul mult mai complex al automatului. În multe cazuri, se bazează pe un automat de stare pentru a se ocupa de logica complexă cu stări multiple. O secţiune ulterioară explorează cum trebuie utilizate automatele de stare pentru proiectarea logicii.

Pentru a executa în arhitectura de control, sarcina principală de control trebuie să:
• execute mai rapid decât rata de scanare a I/O-urilor
• acceseze intrările/ieşirile prin intermediul tabelului de memorie decât direct prin citiri şi scrieri de I/O
• nu utilizeze “bucle while” în afară de reţinerea informaţiilor în registrele de decalare
• nu utilizeze “bucle for” cu excepţia folosirii acestora în algoritmi
• nu utilizeze “stări de aşteptare”, ci funcţii de cronometrare sau de “Tick Count” pentru logica de sincronizare
• nu efectueze operaţii de forme de undă, înregistrare sau non-deterministe (folosiţi bucle paralele, cu prioritate scăzută, pentru acest tip de operaţii)

Figura 2.2. Cele trei stări principale ale arhitecturii de bază specifice unui controller

Logica utilizator poate să
• includă operaţii mono-punct precum PID sau analiza punct cu punct
• utilizeze un automat de stare pentru structurarea codului
Rutina de control poate fi ilustrată ca şi o singură buclă, unde I/O este citit şi scris şi o sarcină de control rulează cu driverele de comunicaţie prin intermediul unui tabel de memorie; însă, în realitate, există bucle sincronizate multiple, întrucât pot fi mai multe sarcini de control sau de măsurare.

Rutina de shutdown

Atunci când un controller trebuie să se oprească din cauza unei comenzi sau a unei defecţiuni, bucla principală de control se opreşte şi rulează o rutină de shutdown. Aceasta opreşte controller-ul şi îl transpune într-o stare de siguranţă. Utilizaţi-l doar pentru oprirea controller-ului – nu este locul potrivit pentru rutinele de shutdown, care ar trebui plasate în bucla principală.

Rutina de shutdown:
1. setează toate ieşirile la stări sigure
2. opreşte orice bucle paralele în funcţionare
3. efectuează orice logică suplimentară, cum ar fi notificarea operatorului cu privire la o defecţiune la nivelul controller-ului sau referitor la orice informaţii aflate în stare de înregistrare.

SC

National Instruments Romania

SRL
B-dul Corneliu Coposu, nr. 167A, et.I, Cluj Napoca, CP 400228
Tel.: 0800 894 308
E-mail: ni.romania@ni.com
www.ni.com/romania

S-ar putea să vă placă și