Variabili su PLC S7-300 e SCADA

[Candy]

Non so se prima cazziarti e poi risponderti, solo cazziarti, o fare uno strappo alla regola e solo risponderti. (Anche se non centra nulla, per questa sera non me la sento di arrabiarmi).
E, scrivo questo lungo incipit perché voglio farti osservare quanto nebbiosa e fumosa è la tua mente, (non so il resto). Leggendoti: sai programmare, ma non sai fare i calcoli... Ma allora cosa programmi? E poi leggendo tutto il resto. Sorgono solo molti dubbi. Dubbi che quanto mi sto accingendo a spiegare serva a qualcosa. Penso proprio di no.

Ora io cercherò di essere il più completo possibile, perché non interverrò più in questo thread. (Thread che ho creato perché come ti avevo scritto, il tuo discorso è fuori e molto dal precedente thread dove ti eri attaccato).

I PLC in generale nascono e sono ancora oggetti programmabili orientati ad una utenza non sempre all'altezza della situazione. Quando si svilupparono, le uniche persone che ne avrebbero fatto uso erano manutentori di natura elettomeccanica che vedevano solo quadri a relè, ragionavano in termini di autoritenute, timer e contatori e nulla sapevano di numeri interi, a virgola fissa od a virgola mobile. I PLC si sono dunque sviluppati con un linguaggio di programmazione assai semplice e semplificato. Fortunatamente oggi i linguaggi si sono evoluti, un poco standardizzati e sopratutto, sono stati introdotti e largamente diffusi linguaggi testuali, molto più pratici e veloci dei linguaggi grafici. Tuttavia i linguaggi grafici mantengono un loro ampia gamma di utenti e pertanto resistono all'età. Il LADDER è forse il più diffuso tra tutti, perché ricorda fin troppo bene lo schema elettrico. Non mi dilungo oltre.
Nella estrema semplificazione che si è fatta nello scrivere gli ambienti di sviluppo si è dovuto tenere conto di molti fattori, che hanno indotto scelte. Condivise o meno, quelle sono.
Raramente ti troverai davanti a linguaggi di programmazione evoluti: per ristrettezza di risorse e di memoria, all'interno di un PLC, contrariamente ai PC, tutti i dati numerici sono memorizzati e gestiti nella loro forma grezza: un byte, un intero, un doppio intero, un float, sono aree di memoria precise, ben definite, accessibili però, per la natura del PLC, da chiunque, in qualunque modo. Significa, in soldoni, che il programma utente non è in grado da solo di capire la natura del dato ed usarla al meglio. E' lo sviluppatore che deve sapere esattamente cosa sta facendo.
Fotunatamente vengono in aiuto molte limitazioni messe qua e la dagli sviluppatori dei compilatori. Limitazioni che fanno dei controlli di massima, peraltro però facilmente raggirabili.
Che cosa significa?
Parlando per il Siemens S7, che è il PLC che stai usando:
Significa che, assumento in via del tutto ipotetica una MW20 contenente un dato di tipo intero, lo dovrai usare nel programma sempre come intero, assumendo una ipotetica MD22 come un dato di tipo float, lo dovrai usare sempre e solo come tale.
Nel linguaggio KOP, (mi sembra di ricordare tu usassi quello), le operazioni matematiche sono per forza di cose funzioni elementari che si rappresentano come "box" elaborati secondo lo stato di RLC come se fossero delle bobine di uscita.
In primo luogo dovrai quindi sincerarti che il programam sia scritto in modo tale da attivare sempre tutti gli EN dei box desiderati e, facendo attenzione che le uscite ENO per la concatenazione orizzontale si interrompono se una funzione va in errore.
Ammesso dunque che tu scriva correttamente la parte logica del programma di calcolo, dovrai predisporre come minimo tre variabili di tipo REAL: due potranno essere di memoria temporanea, una magari di memoria globale come l'area M, oppure un dato di DB. A tua libera scelta con le CPU moderne. Con le più vecchie meglio se ti limiti all'uso dell'area M.
Assumiamo che tu abbia dichiarato nell'itestazione del blocco, le seguenti variabili

Codice: Seleziona tutto

rLacc1 : REAL;
rLacc2 : REAL;


Ed una terza variabile dichiarata nell'area merker

Codice: Seleziona tutto

rGquality AT %MD24 : REAL;


A questo punto, assumo che tu abbia già i due contatori di pezzi buoni e scarto che stanno contado, appoggianti sulle seguenti variabili:

Codice: Seleziona tutto

ulGgps AT %MD16 : UDINT;
ulGbps AT %MD20 : UDINT;


La prima operazione da fare sarà quella di convertire il dato da DINT a REAL, e poi fare il calcolo:

ss.jpg (21.78 KiB) Osservato 4690 volte

Per i restanti calcoli basterà fare la stessa cosa, ricordando che la migrazione da un formato ad un altro deve sempre essere fatta utilizzando le conversioni, perché, appunto, come scrivevo, il firmware del PLC non conosce a priori il tipo di dato memorizzato nella RAM e non è in grado di fare conversioni a livello dei moderni linguaggi di programmazione per PC.

[badilant]

Mi permetto di dissentire Candy.

Nel linguaggio KOP, (mi sembra di ricordare tu usassi quello), le operazioni matematiche sono per forza di cose funzioni elementari che si rappresentano come "box" elaborati secondo lo stato di RLC come se fossero delle bobine di uscita.

In qualsiasi modalità di editazione , salvo STL che ha un set di istruzioni tutto suo, tutte le operazionei semplic o complesse, su numeri interi fino agli array, possono essere gestite.
Le differenze sono solo in termini di legigbilità e limiti di editazione nel segmento, oltre che ad un uso più o meno diveso della memoria programma, inteso come dimensioni del programma utente.
Le trasposizioni grafiche hanno sempre un peso maggiore in termini di memoria.
Mi sembrava di leggere nelle tue parole (sempre che sia legittimo interpretarle) che se programmi in KOP o in FUP certe operazioni non si possano fare, cosa non vera.

[Candy]

Allora non hai letto quello che forse non ho scritto, od ho dato per sottinteso. Ho scritto che i firmware ed i compilatori per PLC non gestiscono in automatico variabili "atipizzate" come possono essere ad esempio un VisualBasic e compagni. Nei linguaggi di basso e bassissimo livello come il caso del PLC, è indispensabile conoscere ed usare l'esatto tipo di variabile, se si vuole che tutto funzioni e bene. Mentre i linguaggi letterali che devono essere compilati, hanno qualche controllo e limitazione in più nell'uso dei tipi, per i linguaggi grafici i controlli fatti dal verificatore del programma sono più limitati.

[badilant]

Scusa se vado OT ma mi fermo qui poi lasico a te che sei il capo, la conduzione del programma.
Soprattutto perché mi aspetta un taxi che mi porta da un 1200 da collaudare.
Stai cercando farmi credere che il compilatore non individua assegnazioni errate di tipi variabili agli ingressi dei box KOP o cosa?
Se cerchi di fare digerire una variabile float in ingresso ad un box operazione come ADD_I , il compilatore se ne accorge eccome.
Forse è la tua poca dimestichezza nell'uso di linguaggi grafici ti induce a pensare che siano limitati o quant'altro rispetto alla lista istruzioni.
Io che li uso entrambe ti assicuro che le sole limitazioni sono nella memoria.
Poi che io faccia un programma in AWL o in KOP non mi cambia nulla.

Una volta, quandoi non avevo i capelli bianchi, con S5 avevi delle restrizioni nell'editor, dove gli FB dovevano per forza di cose essere scritti in lista istruzioni.
Ma da allora questo limite del programma, è stato rimosso.

[Candy]

Non so se lo devi digerire o meno, ma se in un linguaggio grafico ometti di utilizzare la variabile per nome, e scrivi il programma con indirizzamento assoluto, il compilatore nulla sa sul tipo di variabile usato e la interpreta a suo piacimento.
Un esempio pratico:
"a" e "b" sono due interi, il primo dichiarato in MW0, il secondo dichiarato in MW2. Se programmi un box KOP per la somma di MW1 e MW3, per il compilatore e per il firmware della CPU sarà tutto Ok, poi, cosa ne verrà fuori, saranno tutti problemi tuoi... Se invece programmi la somma in REAL tra "a" e "b" il compilatore borbotta un poco. Ancora, però, se programmi un box per la moltiplicazione tra MW0 e MW24, per il compilatore tutto bene.

Ancora peggio è dal lato dello SCADA. Se lo programmi tramite il simbolico, ti assiste nel dichiarare il tipo delle variabili, ma se lo programmi con indirizzamento assoluto, pensa pure di fare attenzione a cosa stai facendo, perché non hai controlli.

Buon viaggio a te.

[ibra842]

per ora sto programmando in kop non ho mai detto di saper programmare i plc ma sto imparando(e c'è molto da imparare)...comunque ho poi risolto in questo modo...tramite move ho sposato la word di uscita di ognuno dei tre contatori in DWORD poi ho convertito le Dword col blocco DI_R in numeri REAL ho diviso pezzi ok/pezzi totali ho memorizzato il risultato in una LD0 ho moltiplicato la stessa LD0X100 è ho dichiarato nel DB "verso scada" un numero real chiamato qualità pezzi ok,quindi con l'altra DWORD trasformata in real ho eseguito pezzi non ok/pezzi totali memorizzato il risultato in LD4,ho moltiplicato LD4x100 e in DB "verso scada" ho dichiarato un numero real chiamato qualità pezzi non ok,ho testato sul simulatore e funziona quindi sul pannello wincc avrò due campi I/O uno qualità pezzi conformi,l'altro qualità pezzi non conformi,usare la local area mi è sembrato comodo premetto sto imparando.
Comunque ringrazio tutti e mi scuso di aver scritto inizialmente sul post dei robot abb

[ibra842]

questo è ciò che fatto su ognuna delle tre word di uscita dai contatori

[ibra842]

poi ho concluso cosi ricavando i due dati che mi servivano...

[ibra842]

l 'uscita dei contatori Z_VORW IN DUAL sono WORD quindi le ho trasformate in double word per poi convertirle in real e fare i calcoli...

[Candy]

Non è molto bello a vedersi: nel tuo lavoro MD28 ed altre variabili, assumono valori diversi, addirittura di tipo diverso, con l'avanzare della scansione programma. Un problema per i sistemi di comunicazione non sincroni, che possono così essere ingannati da dati non coerenti.