ElectroYou

Salve, nella mia ricerca di informazioni, ho letto per il web che il linguaggio da utilizzare dipende molto dai compiti da effettuare, ad esempio per alcune cose è preferibile il KOP, per altre l' AWL, per altre ancora l' SCL e cosi via, dunque alla fine mi sembra di capire che è inutile fossilizzarsi su un singolo linguaggio, ma la migliore strategia potrebbe essere quella di conoscerli tutti ed all'occorrenza utilizzare quello più indicato.

Detto ciò, nei miei primi programmini sto utilizzando il KOP, in quanto ho deciso di partire da questo, ciò che ho notato è che nel richiamo di una FC dall' OB1 il KOP è molto immediato in quanto si vanno proprio a vedere "i segnali" che si passano al blocco ed alla fine quello che il blocco ci restituisce, come nella figura seguente:



Mentre convertendo tale richiamo in AWL ciò che si va a visualizzare è un bel po' di roba:



molto "ad occhio" in tal caso mi sembra più immediato l'utilizzo del linguaggio KOP o al max del FUP che ho visto essere molto simile nel richiamo dei blocchi, però questo mio discorso è molto di basso livello, in quanto potrebbero esserci cose che poi alla fine fanno preferire l'AWL in tal caso....

In ambito reale, quale linguaggio si preferisce utilizzare nell'OB1 nel caso di soli richiami di blocchi ?

Ciao,
un anno fa ho fatto un corso regionale serale di programmazione in STEP 7 e ho lavorato sugli S7300.
L'intero corso a meno di qualche piccolo caso (fatto unicamente per dare idea di come si proceda con altri linguaggi) era improntato sul KOP.
Con il KOP abbiam fatto dalla programmazione di FB, FC a interi programmi strutturati, con gestione di regolatori PID ingressi da encoder o uscite PWM, e non abbiamo avvertito una vera limitazione di qualche tipo.
Da quanto ho potuto apprendere la vera capacità con la piattaforma S7 sta nel conoscere e saper usare bene e con coerenza i vari blocchi messi già a disposizione dalla piattaforma.

Il KOP inoltre è più intuitivo anche per chi lavora in ambiente elettrico; molti dei partecipanti al corso erano tecnici e/o elettricisti e con linguaggi informatici avevano dimestichezza pressoché nulla, mentre erano molto agevolati nel fare manutenzione anche usando schemi a contatti.

In termini di leggibilità credo che il KOP sia l'ottimale nell'OB1, dove di solito crei l'impostazione di massima del programma affidando i compiti specifici a FC o FB.

Come hai giustamente detto la scelta del linguaggio è figlia delle esigenze e dell'esperienza nella sua praticità d'uso.
Restiamo in ambiente SIEMENS.
Il codice AWL è praticamente un codice macchina, (anche se interpretato). I codici grafici invece comprendono una serie di istruzioni che permettono di costruire un ambiente familiare alla visualizzazione.
Da sempre per i PLC esiste la caratteristica di poter leggere il programma in esso in funzione e visualizzarlo sul PC senza dover necessariamente possedere il sorgente. Se capisci questo, ti rendi facilmente conto che il programma o sorgente, o pseudo tale, deve risiedere nel PLC. Ogni costruttore ha adottato la propria strategia in tal senso, per SIEMENS la scelta è stata quella di inserire nel set di istruzioni AWL anche dei codici di rappresentazione grafica che, non hanno alcun effetto all'interno del programma, se non aumentarne le dimensioni, ma permettono, collegandosi on-line col PLC, di ricostruire parte del programma in modo grafico, (eccezione per i commenti).
Quando osservi quindi il codice AWL convertito da in programma scritto in in modo grafico, ti ritrovi quindi di fronte a passaggi ed istruzioni apparentemente macchinose.

Inutile dire che tentare di scrivere un programma AWL, in modo compatibile con l'interprete grafico è impossibile e, quindi, chi scrive in AWL, (l'assembler del PLC), opta per perdere la convertibilità, cosa però molto sgradita ai più. (In un contesto di debug o futura modifica, l'ambiente grafico da indubbiamente i suoi ritorni, ed il costo della poca memoria in più utile si ripaga senza problemi).
Vero è che Siemens ha sempre fatto pagare tutto caro e la cosa ha fatto maturare molti programmatori di AWL puro che sceglievano CPU da 32 k, invece che 64 k o 128 k proprio per questa ragione.

Poi, per ripondere a tutto, per come la vedo io, il blocco organizzativo OB1 che è sostanzialmente quello deputato ai richiami dei blocchi programma, lo vede bene scritto in KOP o FUP. Non andrei, in questo caso, con SCL.

Rileggendo la precedente risposta, mi è sorto all'istante un dubbio.... ovvero in KOP per verificare il programma selezionando controllo on/off vado proprio a vedere come "il flusso" a partire dagli ingressi arriva alle uscite, ma in awl come faccio?

Ovviamente non potevo farmi scappare l'occasione di vedere cosa "avrei visto" in awl..... converto la FC da KOP ad AWL e mi ritrovo la seguente cosa:



non è il massimo della praticità, rispetto al vedere una linea che da continua diventa tratteggiata quindi di immediata interpretazione, dunque capisco un po' meglio ciò che mi si indicava in precedenza.

Però per il web leggo che per l' s7-300 l' AWL sia quasi un dogma..... attualmente le mie scarsissime conoscenze dell'argomento non mi permettono di capire il motivo ed in particolare le differenze, non mi resta che cercare di avvicinarmi ad entrambi per poi poter fare una valutazione

Quando analizzi un programma in animazione, ossia, animando lo stato dell'elaborazione, nella schermata, più a destra, ti compare lo stato dell'elaborazione, ovvero lo stato dei registri interni del PLC che tengono il filo e permettono di realizzare la logica.
In base alle impostazioni di visualizzazione, potrai vedere i due accumulatori a 32 bit, che memorizzano le variabili numeriche, lo stato delle interrogazioni, ed il risultato logico combinatorio RLC.

Brevissimo esempio:

Codice: Seleziona tutto

CLR
SET
A I 0.0
A M 0.4
= O 0.7


Ipotizziamo che I 0.0 sia ad uno, mentre M 0.4 sia a zero, avrai in animazione:

Codice: Seleziona tutto

          STA     RLC
CLR        0        0
SET        1        1
U I 0.0    1        1
U M 0.4    0        0
= O 0.7    0        0 


Vediamo di leggerlo:
CLR effettua il clear ossia la pulizia di tutti i registri logici interni, quindi, la logica che segue avrà un funzionamento unico dipendente dal programma che segue. Perché l'ho messo? Perché non so che codice programma fosse elaborato prima di questo ed il registro RLC potrebbe valere anche uno... Il discorso è lungo.
SET forza il valore di RLC ad 1, ma non tocca altri registri importanti, che ometto per brevità.
Quindi ora RLC vale sicuramente 1, mentre BA ed altri restano al valore neutrale. (Memoria corta la mia).
A I 0.0: interroghiamo l'ingresso I 0.0 come serie (and). Vale 1, il suo valore visualizzato da STA è 1, RLC valeva 1 e quindi la serie continua a dare risultato RLC 1.
A M 0.4: interroghiamo M0.4 in serie alla logica precedente. M 0.4 vale 0, STA diviene 0, RLC precedente valeva 1, in and con l'attuale STA darà RLC 0.
= O 0.7: il valore ultimo di RLC passa ad O 0.7. RLC valeva 0, O 0.7 quindi assume il valore di 0.

Tutto quello che vedi in grafica è la rappresentazione dei ragionamenti che ti ho illustrato. Io ho fatto le cose semplici per pigrizia, mi si possono fare logiche molto complesse, con molteplici livelli di parentesi, ecc.

Una nota in merito la precedente uso delle istruzione CLR e SET. Dopo una istruzione "=", "S", o "R" i flag della network si resettano e per iniziare una nuova network non serve più utilizzare CLR e SET. Però non bisogna omettere di conoscerli. AWL fa massiccio uso di salti, sopratutto sulle operazioni matematiche e di confronto, quindi, avere padronanza di queste due istruzioni fa la differenza.

Chiedo scusa se sono stato troppo restrittivo. Dove non è chiaro, chiedi.

Adesso mi creo un progetto di prova e cerco di "vedere" ciò che mi indichi

Per adesso mastico un po' di KOP e l'AWL non l'ho mai toccato, inizio questa sera

Lascia un segno sul calendario.

Forse ho capito qualcosina.... ho provato a cambiare i tuoi valori in modo da ragionarci da solo ed il risultato finale sembra coerente, ti posto la simulazione con il ragionamento e poi un paio di dubbi/domande:



Allora come tu mi dicevi con CLR vado a pulire tutti i registri, dunque inizialmente ho uno 0 in tutti i registri, poi con SET imposto il bit RLO ad 1, a questo punto supponendo (come nella simulazione) che l'ingresso sia nullo 0, la AND tra quello che è contenuto in RLO e l'ingresso mi restituisce uno 0, come visualizzo nella simulazione, adesso supponendo che il merker abbia come valore 1, la nuova AND tra il valore del merker ed il valore di RLO mi restituirà nuovamente un valore 0 nella RLO, alla fine con quell'uguale vado a riportare il valore di RLO nel bit di uscita il quale sarà 0 in quanto RLO è 0.

Con lo stesso ragionamento considerando un ingresso pari ad 1 mi ritrovo una uscita pari ad 1:



Dunque alla fine è come se seguissi una scaletta e ad ogni passo vado a combinare l'operazione logica con il valore del bit RLO, memorizzo il risultato in RLO e lo utilizzo per il passo successivo.

qualche domanda:

1) perché in TIA si parla di RLO mentre in PLCSIM nella parola di stato vedo scritto RLC ?

2) Non mi è tanto chiara la funzione di STA, cioè STA contiene il valore da combinare con RLO, ovvero il valore dell'ingresso/uscita o merker ?

3) In Tia non riesco a visualizzare niente sulla destra dove è indicato registro AS, ciò dipende dal fatto che nn ho l'hardware giusto?

1) TIA si sta un poco internazionalizzando e quindi fa un uso ormai sistematico dell'inglese e dei suoi acronimi. Lo STEP 7 precedente molto meno, era un mix anglotedesco. Non so perché RLC sia divenuto RLO. Poco importa. il bit è quello.
2) STA in TIA lo vedi come "Valore". STA da status, inteso come stato dell'operando interrogato.
3) Che registro è AS? Non lo vedo dalle schermate. Non è detto che la CPU lo riporti al PC, ma fammi capire chi è!

Candy ha scritto:1) TIA si sta un poco internazionalizzando e quindi fa un uso ormai sistematico dell'inglese e dei suoi acronimi. Lo STEP 7 precedente molto meno, era un mix anglotedesco. Non so perché RLC sia divenuto RLO. Poco importa. il bit è quello.
2) STA in TIA lo vedi come "Valore". STA da status, inteso come stato dell'operando interrogato.

Perfetto, capito.

Candy ha scritto:3) Che registro è AS? Non lo vedo dalle schermate. Non è detto che la CPU lo riporti al PC, ma fammi capire chi è!

Penso sia il registro di stato, in TIA me lo ritrovo sulla destra, visualizzato durante un controllo ON/OFF, ti riporto una foto: