Figura 2.1. Cele trei stari principale ale arhitecturii de baza specifica unui controller

Rutina de initializare

Inainte de executia buclei principale de control, programul trebuie sa efectueze o rutina de initializare. Aceasta pregateste controller-ul pentru executie si nu se refera la logica caracteristica masinii, precum logica pentru pornirea sau initializarea automatului. Acest tip de logica ar trebui sa treaca in bucla principala de control. Aceasta rutina de initializare:
 

1. Seteaza toate variabilele interne la stari implicite.
2. Creeaza orice structuri de programare necesare pentru operare, inclusiv siruri, memorii tampon de tip FIFO (primul intrat, primul iesit) in timp real, numere logice VI si downloadare de fisiere bitstream FPGA.
3. Indeplineste orice logica suplimentara definita de utilizator pentru a pregati controller-ul pentru operare, precum pregatirea fisierelor jurnal.

Rutina de control

I/O, communicatii si tabel de memorie
Multi programatori sunt familiarizati cu accesul direct I/O, in timpul caruia, subrutinele trimit si primesc in mod direct intrarile si iesirile de la hardware. Aceasta metoda este ideala pentru achizitia de forme de unda si procesare a semnalului, cat si pentru aplicatiile mai mici, intr-un singur punct. Totusi, aplicatiile de control utilizeaza in mod normal citiri si scrieri de fisiere intr-un singur punct si pot deveni extrem de complexe, avand stari multiple – dintre care toate au nevoie de acces la I/O. Accesarea I/O cauzeaza suprasarcina in sistem si il poate incetini. In plus, administrarea de accese I/O multiple pe toate nivelurile programului, ingreuneaza considerabil schimbarea intrarilor/iesirilor si implementarea caracteristicilor de simulare sau fortare.  Pentru evitarea acestor probleme, rutina de control utililzeaza o arhitectura de scanare I/O. In acest tip de arhitectura, puteti accesa hardware-ul fizic doar o data per fiecare iteratie a buclei utilizand I/O si divere de comunicatie (marcate drept „IO” si „Comm Drivers” in figura 2.1). Valorile de input si output sunt stocate intr-un tabel de memorie, iar sarcinile de masurare si control acceseaza spatiul de memorie in loc sa acceseze direct hardware-ul. Acest tip de arhitectura prezinta numeroase beneficii:
·         Abstractizare I/O, astfel incat puteti reutiliza subVI-urile si functiile (fara a coda I/O-urile in sistem hadware)
·         Overhead scazut
·         Operare determinista
·         Suport pentru simulare
·         Suport pentru “fortare”
·         Eliminarea riscului de schimbari de I/O in timpul executiei logice
Sarcini de control si masurare
Sarcinile de control si masurare reprezinta logica specifica automatului de stare care defineste aplicatia de control. Aceasta poate insemna fie controlul procesului, sau controlul mult mai complex al automatului. In multe cazuri, se bazeaza pe un automat de stare pentru a se ocupa de logica complexa cu stari multiple. O sectiune ulterioara exploreaza cum trebuie utilizate automatele de stare pentru proiectarea logicii. Pentru a executa in arhitectura de control, sarcina principala de control trebuie sa:
·         execute mai rapid decat rata de scanare a I/O-urilor
·         acceseze intrarile/iesirile prin intermediul tabelului de memorie decat direct prin citiri si scrieri de I/O
·         nu utilizeze “bucle while” in afara de retinerea informatiilor in registrele de decalare
·         nu utilizeze “bucle for” cu exceptia folosirii acestora in algoritmi
·         nu utilizeze “stari de asteptare”, ci functii de cronometrare sau de “Tick Count” pentru logica de sincronizare
·         nu efectueze operatii de forme de unda, inregistrare sau non-deterministe (folositi bucle paralele, cu prioritate scazuta, pentru acest tip de operatii)
Logica utilizator poate sa
·         includa operatii mono-punct precum PID sau analiza punct cu punct
·         utilizeze un automat de stare pentru structurarea codului
Rutina de control poate fi ilustrata ca si o singura bucla, unde I/O este citit si scris si o sarcina de control ruleaza cu driverele de comunicatie prin intermediul unui tabel de memorie; insa, in realitate, exista bucle sincronizate multiple, intrucat pot fi mai multe sarcini de control sau de masurare. 



Figura 2.2. Cele trei stari principale ale arhitecturii de baza specifica unui controller