Într-un tablou de automatizare, controlerul programabil pare să lucreze continuu, fără pauză. În realitate, un PLC clasic nu urmărește procesul în permanență, ci îl fotografiază periodic. Fiecare fotografie, decizia luată pe baza ei și comanda trimisă mai departe spre ieșiri formează împreună un ciclu de scanare. Durata acestui ciclu, de obicei câteva milisecunde, decide cât de repede poate reacționa echipamentul la o schimbare reală din proces.
Pentru o bandă transportoare care pornește și se oprește la câteva secunde, diferența dintre 3 ms și 12 ms nu se vede niciodată. Pentru o mașină de debitat la lungime care avansează materialul cu 2 m/s, aceeași diferență de 9 ms înseamnă aproape 2 centimetri de material trecuți pe lângă cuțit. Aici începe discuția despre timpul de ciclu: nu este o cifră de raportat în documentație, ci o limită fizică a aplicației.
Cele trei faze care se repetă la nesfârșit
Ciclul standard al unui PLC are trei etape distincte, executate în ordine strictă.
- Citirea imaginii intrărilor. Controlerul preia starea tuturor intrărilor digitale și analogice și o copiază într-o zonă de memorie. Din acest moment, programul lucrează cu copia, nu cu intrarea fizică. Dacă un senzor își schimbă starea imediat după această copiere, programul nu află până la ciclul următor.
- Execuția programului. Instrucțiunile sunt parcurse de sus în jos, rețea după rețea, bloc după bloc. Rezultatele se scriu tot în memorie, în imaginea ieșirilor.
- Scrierea ieșirilor. Abia la final imaginea ieșirilor este transferată efectiv către modulele de ieșire, deci către contactoare, electrovalve, drivere.
La acestea se adaugă un timp de gestiune internă: comunicații, diagnoză, actualizarea variabilelor pentru vizualizare. Pe controlere mici, această componentă poate fi o fracțiune deloc neglijabilă din ciclu, mai ales când se transmit multe date către un panou operator sau către un sistem de supraveghere.
Consecința practică a modelului cu imagine de proces este că un semnal de intrare mai scurt decât un ciclu poate fi pur și simplu ratat. Un impuls de 2 ms pe un PLC care scanează în 10 ms are șanse mari să nu fie văzut niciodată. Nu este un defect al echipamentului, ci felul în care funcționează arhitectura.
Latența reală este mai mare decât timpul de scanare
Greșeala frecventă este să echivalezi timpul de reacție cu timpul de ciclu afișat în software. Între momentul fizic în care ceva se întâmplă pe utilaj și momentul în care contactorul chiar comută se adună mai multe întârzieri:
- întârzierea proprie a senzorului, inclusiv filtrul lui intern;
- filtrul de intrare al modulului, adesea configurabil între câteva zecimi de milisecundă și câteva milisecunde, pus acolo tocmai ca să elimine zgomotul;
- așteptarea până la următoarea citire a imaginii intrărilor;
- execuția programului până la instrucțiunea relevantă;
- așteptarea până la scrierea ieșirilor;
- timpul de comutare al elementului de execuție, de la câteva sute de microsecunde pentru o ieșire tranzistorizată până la zeci de milisecunde pentru un contactor de putere.
În cel mai rău caz, punctele 3 și 5 se adună și dau aproape două cicluri complete. De aceea, când cineva cere garanția unui timp de reacție, calculul corect pornește de la dublul timpului de ciclu, la care se adaugă întârzierile hardware. O aplicație care are nevoie de reacție sub 20 ms nu se rezolvă cu un ciclu de 15 ms, oricât de bine ar arăta media.
Unde milisecundele se transformă în milimetri sau în rebut
Nu toate aplicațiile sunt sensibile. Merită să identifici din start categoriile care chiar sunt.
Măsurare și tăiere din mers. Orice funcție de tip flying cut, marcare sau perforare pe material în mișcare transformă direct timpul în lungime. Formula este banală: eroarea de poziție este viteza înmulțită cu latența totală. Dacă toleranța este de 1 mm la 1,5 m/s, bugetul total de întârziere este sub 0,7 ms, ceea ce depășește ce poate face un ciclu normal de PLC. Astfel de funcții se rezolvă cu ieșiri comandate de poziție direct de modulul de numărare rapidă, nu din program.
Dozare și umplere volumetrică. La debite mari, întârzierea la închiderea valvei se traduce în mililitri în plus la fiecare produs. Pe un lot de zeci de mii de bucăți, pierderea devine vizibilă în consumul de materie primă.
Sortare și respingere pneumatică. Un sistem de inspecție care detectează un produs neconform trebuie să comande duza de suflare exact când produsul trece prin dreptul ei. Aici se lucrează cu ferestre de câteva milisecunde, iar dispersia timpului de ciclu, nu doar valoarea lui medie, decide dacă piesa greșită este scoasă sau nu.
Sincronizarea axelor. Când două axe trebuie să respecte un raport de mișcare, comanda nu se mai face în ciclul normal. Se folosesc funcții de motion cu buclă proprie, iar PLC-ul rămâne să dea doar parametrii. Într-o discuție mai largă despre rolurile diferite pe care le au straturile de control, exact aici se vede de ce nivelul de supraveghere nu are ce căuta în bucla rapidă.
Funcțiile de siguranță. Acestea nu se dimensionează după timpul de ciclu al PLC-ului standard. Ele au propriul lanț, cu timpi de reacție declarați de producător, și se calculează separat, ca parte din distanța de siguranță.
Cum măsori corect timpul de ciclu, nu cum îl estimezi
Aproape orice mediu de programare afișează trei valori: ciclul curent, ciclul minim și ciclul maxim de la ultima pornire. Valoarea utilă este maximul, nu media. Media te liniștește, maximul îți spune ce se întâmplă în ziua în care totul merge prost simultan.
Pași concreți pentru o măsurătoare care înseamnă ceva:
- Resetează contoarele de ciclu și lasă utilajul să lucreze un schimb complet, cu produse reale, nu în gol.
- Provoacă intenționat situațiile grele: alarme multiple, schimbare de rețetă, deschiderea mai multor ecrane pe panoul operator, conectarea unui laptop de programare. Fiecare dintre acestea adaugă sarcină de comunicație.
- Notează maximul obținut și compară-l cu cerința aplicației, nu cu o valoare considerată acceptabilă în general.
- Verifică setarea watchdog-ului. Dacă un ciclu depășește pragul configurat, controlerul intră în stop. Un watchdog setat prea aproape de maximul real produce opriri aparent inexplicabile, la intervale de săptămâni.
Pentru diagnostic pe teren, o metodă simplă este să comanzi o ieșire liberă la începutul programului și să o resetezi la final, apoi să măsori impulsul cu un osciloscop. Vezi direct durata reală a execuției, fără să depinzi de statistici din software.
Ce faci când programul e prea lent: ordinea intervențiilor
Înainte de a schimba hardware-ul, merită parcursă lista de cauze frecvente, în ordinea raportului dintre efect și efort.
Primul suspect sunt buclele. O buclă care parcurge un tablou de câteva sute de elemente la fiecare ciclu, pentru o operație care ar putea fi făcută o dată pe secundă, este cel mai des întâlnit consumator inutil. Soluția este să împarți parcurgerea pe mai multe cicluri sau să o muți într-un task periodic mai lent.
Al doilea sunt operațiile cu șiruri de caractere și cu numere în virgulă mobilă, care pe controlere mici sunt de ordine de mărime mai lente decât operațiile pe întregi. Formatarea unor texte pentru afișare la fiecare ciclu este risipă curată.
Al treilea sunt blocurile de comunicație. Multe instrucțiuni de citire sau scriere pe rețea blochează ciclul până primesc răspuns, mai ales dacă partenerul nu răspunde. Un dispozitiv Modbus deconectat poate dubla timpul de ciclu doar prin timeout-uri repetate. Diferențele de comportament dintre protocoale sunt un subiect în sine, iar alegerea între magistralele folosite curent în automatizare are efect direct asupra sarcinii pe care o duce controlerul.
Al patrulea este structura programului. Blocuri apelate mereu, deși privesc un mod de lucru inactiv, cod de punere în funcțiune rămas activ, secvențe de test uitate în program. Aici ajută enorm o disciplină de organizare a proiectului; un cod curat, cu blocuri clar delimitate, se optimizează mult mai ușor, iar regulile pentru un program lăsat în stare de a fi modificat de altcineva se suprapun în bună măsură peste regulile care îl fac și rapid.
Funcții care ies din ciclul normal: întreruperi, task-uri rapide, module inteligente
Când optimizarea programului nu ajunge, soluția nu este un controler mai scump, ci mutarea funcției critice în afara ciclului principal.
Intrările de întrerupere hardware execută un bloc scurt imediat ce apare frontul, indiferent unde se află programul principal. Se folosesc pentru captarea unui eveniment rapid sau pentru memorarea unei poziții. Blocul trebuie să fie scurt: cât timp rulează, programul principal așteaptă.
Task-urile periodice permit rularea unei bucle de reglare la interval fix, de exemplu la 5 ms, în timp ce restul programului rulează mai lent. Regulatoarele PID pierd calitate dacă intervalul de eșantionare variază, deci merită puse în task periodic, nu în cel ciclic.
Modulele de numărare rapidă și cele de poziționare au electronică proprie și pot compara poziția cu o valoare prestabilită, comandând direct o ieșire, în microsecunde. Aceeași logică se aplică modulelor de cântărire sau celor de măsurare a temperaturii, care fac filtrarea local.
Un ultim aspect ține de așteptări. Un timp de ciclu de 10 ms nu este un defect și nu trebuie corectat dacă aplicația lucrează cu rezervoare, cuptoare sau transportoare lente. Problema apare doar când cerința reală a procesului este mai strictă decât ce poate livra arhitectura aleasă, iar acest lucru se stabilește la proiectare, cu cifre, nu după punerea în funcțiune. Dacă aplicația are componente de siguranță a persoanelor, calculul distanțelor și al timpilor de oprire trebuie făcut sau validat de un specialist în siguranța mașinilor, pe baza standardelor aplicabile și a datelor declarate de producătorul echipamentelor.
