Dati Temporanei Scl

[Christian Vaiti]

Salve a tutti

Ho la necessita' di convertire un sw da AWL a SCL; mi sono scaricato i vari manuali Siemens, ma non mi e' sembrato siano particolarmente esaustivi; mi sembrano che ignorino troppe cose; comunque attualmente i miei problemi principali sono:

In AWL posso trasferire facilmente dei blocchi di dati tra una DB e dei dati temporanei, tipo L DBx.DBD2 -> T LD0; da LD0 posso dichiarare i dati come INT, BOOL, BYTE etc. non ho trovato pero' un metodo per farlo in SCL; e' forse impossibile?

E ancora, ho una funzione che apre una DB come parametro, come posso poi utilizzarne i dati in SCL? In AWL faccio ad es. AUF DB3, dopodiche' faccio L DBW0 -> T MW45 , U DBX2.3 etc. etc. in SCL come si puo' fare?

Un grazie a tutti coloro che vorranno rispondermi.

[cagliostro]

Salve,

non ho trovato pero' un metodo per farlo in SCL; e' forse impossibile?

no, non lo è.

Allego esempio banale dove all'interno di FC100, viene assegnata la costante 5 alla variabile temporanea pluto definita come word, che scrive il valore verso il DB10.DBW2.....Per fare l'opposto ovvero assegnare a pluto il valore di DB10......basta invertire le variabili.

Eventualmente se ti è più comodo puoi utilizzare l'indirizzamento simbolico anzichè DB10.DBW2

mi sono scaricato i vari manuali Siemens, ma non mi e' sembrato siano particolarmente esaustivi

A mio modesto parere non mi sembra che il manuale dell' SCL sia avaro di informazioni.

Sicuramente come molto spesso accade, ed in particolar modo nei manuali tecnici, bisogna avere la pazienza di interpretare le cose che il più delle volte ad una prima lettura sono solo chiare a chi ha redato il manuale.

Se consulti il capitolo 10 paragrafo 3 (pagina 10-7) del manuale S7-SCl V5.3 vengono spiegati gli indirizzamenti dei DB e delle varie aree di memoria.

Modificato: 3 luglio 2010 da cagliostro

[Christian Vaiti]

Ti ringrazio della risposta che chiarisce efficacemente come trasferire una variabile da DB a TEMP; ma la domanda era differente: effettuato il trasferimento della DWORD, come posso poi utilizzarne singolarmente, nella variabile temporanea, i 32 bit che la compongono?

[Christian Vaiti]

Scusa, non mi ero accorto che la prima domanda era incompleta...

Scusa ancora.

[cagliostro]

come posso poi utilizzarne singolarmente, nella variabile temporanea, i 32 bit che la compongono?

a seguire allego immagine e posto il codice.

Viene attivata nella variabile di uscita della FC100 la variabile out, interrogando il bit 15 della variabile temp pluto (word) e del bit 12 della variabile temp paperino (dword).

Quello che in sostanza chiedi, viene realizzato attraverso il comando AT che effettua l'accesso con un tipo diverso di dati ad una variabile dichiarata. Fai attenzione che però i byte restituiti come singoli bit degli ARRAY sono swappati rispetto a quanto scritto come valore nella word e nella dword.

FUNCTION FC100: void

VAR_OUTPUT
out:BOOL;
END_VAR

VAR_TEMP
Pluto:WORD;
pluto_bit AT pluto : ARRAY[0..15] OF BOOL;

paperino:DWORD;
paperino_bit AT paperino : ARRAY[0..31] OF BOOL;
END_VAR

BEGIN
    // Parte istruzioni
pluto:=w#16#00FF;
paperino:=DW#16#00FF_FF00;

out:= pluto_bit[15] AND paperino_bit[12];

END_FUNCTION

Modificato: 5 luglio 2010 da cagliostro

[Christian Vaiti]

Semplice e pulito; ti ringrazio molto.

Perche' non ci ho pensato da solo?

[cagliostro]

Per ovviare al problema dello SWAP che in SCL non esiste come istruzione, se di tuo interesse allego immagine a seguire

dove dal codice postato nel precedente messaggio, sono state aggiunte le istruzioni ROL e ROR che permettono di effettuare lo swap

dei byte di una word e di una doppia word.

Modificato: 5 luglio 2010 da cagliostro

[walterword]

personalmente , uso scl da parecchi anni .

Lo uso prevalentemente per muovere dati , fare calcoli abbastanza complessi, lavorare con array e array di strutture (tabelle) , matrici , indici di indici ect .

Viene compilato in maniera alla "tedesca" e con le nuove cpu non pesa nulla .

Tutto questo lavoro dopo aver dichiarato per bene le variabili nei db o le statiche di istanza , qualora fosse in fb.

L'utilizzo avviene in forma simbolica come se fosse un linguaggio informatico per pc.

Non lo trovo utile o veloce per le logiche booleane di macchina come comandi manuali , sequenze di passi automatici o interblocchi .Questo per un fatto di vista personale , ma ricorda che il debug non e' il massimo della vita se sei in cantiere oppure officina a collaudare gli impianti .

ciao

walter

p.s. io credo che non si debba sposare un linguaggio o preferirlo ad un altro .si devono usare tutti a seconda del contesto e del senso .Per le logiche di livello macchina va benissimo il kop , poi per le routine allarmi o gestioni che sono default nei progetti va bene anche awl .Il fup lo usano i tedeschi ed i russi e mi viene da star male a vedere tutti quei blocchetti , lo ritengo piu un linguaggio per descrivere hardware per esempio negli fpga piuttosto che nei plc .

il s7 graph eì troppo pastoso e pesante , preferisco le sequenze set-reset in kop , il cfc poi e' da dementi .Per capire un allarme bisogna smacchinare in mezzo ai blocchetti e alle scatolette , naaaaaaaaa

[batta]

Concordo con Walter.

Il bello di avere più linguaggi a disposizione consiste proprio nel poter utilizzare quello più adatto per ogni scopo.

L'scl è comodissimo per fare calcoli complessi, trasferire dati, lavorare con puntatori ed array. Tutte cose comunque che si possono fare tranquillamente in awl, con poco sforzo in più e ottenendo un codice molto più leggero.

Non si può dire che sia altrettanto comodo per gestire logiche booleane, specialmente nel debug.

Su una sola cosa non sono pienamente d'accordo con Walter, ed è sulla poca importanza della maggior pesantezza del codice awl generato da sorgenti scl.

Questo può non rappresentare un problema quando si lavora con cpu di alta gamma, con velocità di elaborazione e memoria elevate.

Quando però si devono fare i conti con cpu più economiche, la differenza di codice non è più trascurabile.

Non dimentichiamo che cpu piccoline, come una 314 o cpu della serie ET200S (con memoria di lavoro di 96KB), sono spesso utilizzate per impianti di una certa complessità (e valore anche di alcune centinaia di migliaia di euro), dove arrivare ad esaurire la memoria non è certo impossibile. Quel 10-20% di codice in più che viene generate dall'scl potrebbe essere importante.

[walterword]

ciao Batta.

Tra le miriadi di problemi che mi trovo ad affrontare ogni giorno , in ufficio , in officina , o in cantiere per fortuna che non ho quello di dover spulciare la cpu .

In questa azienda , la macchinetta piu piccola monta una cpu 313-314 per sfruttare le analogiche a bordo per pilotare gli inveters.

Per impianti medi normalmente uso sempre una bella 315 2DP e per impianti medio-grandi con comunicazioni a basso livello o calcoli da fare richiedo una 317 , bella macchinetta.

Quindi di memoria ne ho da buttar via nel vero senso della parola .

Il fatto sta che ormai tra cpu , relays di sicurezza varie , pc , pannelli e comunicazone seriale su pci -express con applicazione scritta in delphi buttiamo via tanti di quei soldi , spazio , cavi , morsetti e cose inutili che veramente se mi fanno la pulce sulla cpu do le dimissioni e cambio mestiere .

Mi piaerebbe fare il falegname , sto montando un box a casa 5x8 con punte del legno , livella ad acqua , saette per piombare le colonne ....mi ritrovo la schiena rotta ma con grandi soddisfazioni .

Nel mio mestiere la soddisfazione la vedo quando le macchine girano come un violino , di ogni macchina si sa cosa stia facendo ect ,se devo anche star li a contare i bytes della memoria butto tutto per aria e mando a cagare tutti quanti

Io comunque sono sempre piu propenso a sostiruire il tutto con un bel sistema pc-plc embedded almeno per macchine singole o con pochi accessori .Tutto li dentro , hmi , plc ,diagnostica , programma per creare etichette linkate a database e compilazione automatica di scanner o celle di carico direttamente dal bus , e storie varie .

Relays di sicurezza in ethercat , un bel pannello al posto degli op marci e da calcoli che ho fatto risparmiamo circa il 40% bello bello come il sole .

Solo che gli imprenditori italiani son tutti da capire

ciao

walter

Modificato: 19 agosto 2010 da walterword

[batta]

Solo che gli imprenditori italiani son tutti da capire

Purtroppo così è ed è difficile far cambiare idee.

Che dire, io sono un po' più "tradizionalista" di te.

Sono convintissimo che su macchine "stand alone" si potrebbe risparmiare parecchio (anche in tempo di sviluppo sw, non solo come hw) ottimizzando il tutto e buttando tutto su un pc.

Il discorso cambia quando si lavora su impianti o su macchine che non possono essere fermate.

Prova a dire ad uno stampatore: "Scusa, ti fermo 10 secondi la rotativa perché devo fare una piccola modifica". Diglielo però da almeno 10 metri di distanza, ed assicurati che non abbia nulla di pesante in mano

Ci sono software (es. Twincat, ma non credo certo sia l'unico) che permettono di fare modifiche online, ma i sistemi basati su pc sono comunque più soggetti ad arresti obbligati di un normale plc.

Un plc lo devi fermare solo se apporti modifiche hardware, e nemmeno sempre.

Poi, per tornare al discorso memoria, mi capita spesso di proporre prodotti alternativi, pur mantenendo la stessa filosofia. Per esempio, installando VIPA al posto di Siemens, riesci ad ottenere contemporaneamente un discreto risparmio ed un incremento di prestazioni.

Invece il cliente vuole sì risparmiare, ma vuole restare su Siemens.

Non mi posso quindi assolutamente permettere di prendere una cpu di taglia superiore.

Ad oggi non mi è mai capitato di sbagliare taglia (non so se per esperienza o per fortuna. Forse un po' entrambe le cose), ma di arrivare ad occupare oltre l'80% della memoria di cpu come 314 o 315 mi capita non dico spesso, ma con una certa frequenza. Una volta con una 315 sono arrivato al 97%.

A volte è anche una questione di abitudini.

A metà anni '80 uno studio di commercialista teneva la contabilità dei suoi clienti con un IBM XT o un Olivetti M24 con disco fisso da 10 MB (mega, non giga) e 128 o 256 KB di RAM.

Oggi per fare le stesse cose c'è bisogno di pc con prestazioni nemmeno paragonabili.

Va beh, ammettiamo che no si fanno proprio "le stesse cose". Lavorare ora con un pc non è come a metà anni '80. Ora con i pc si fanno cose che in quel periodo nemmeno si immaginavano.

Però io sono convinto che buona parte delle prestazioni necessarie per far girare bene il software odierno sia dovuta alla scarsa attenzione che i programmatori pongono all'utilizzo delle risorse.

Ed in questo spreco di risorse, a giudicare dai software di sviluppo che sfornano, penso che i tecnici Siemens sarebbero candidati alla medaglia d'oro.

[Livio Orsini]

Ed in questo spreco di risorse, a giudicare dai software di sviluppo che sfornano, penso che i tecnici Siemens sarebbero candidati alla medaglia d'oro.

Che succede Batta? E' la prima volta che scrivi di difetti Siemens.

Sono anni che lo vado ripetendo. Sia nei programmi di sviluppo, sia nelle funzioni di libreria il Sw Siemens è una bella collezione di UCAS.

Molto dello spreco di risorse è dovuto anche alle facilitazioni che si implementano per gli utilizzatori.

Un sistema operativo come il DOS, a riga di comando e senza tanti automatismi per l'installazione delle periferiche occupa un centesimo delle risorse di WinXP o Win7; anche la necessità di risorse di memoria e di CPU è irrisoria. I programmi applicativi diventano enormemente più snelli e veloci, però richiede impegno e conoscenze specifiche, da aprte dell'utente, molto maggiori degli attuali sistemi.

E' un po' come paragonare la 500 degli anni '60 con quella attuale.

[batta]

Che succede Batta? E' la prima volta che scrivi di difetti Siemens.

Non è vero. Io non ho mai sostenuto che Siemens sia esente da difetti.

Io ho sempre sostenuto che i sistemi di sviluppo Siemens, sia per i plc che per i pannelli operatore/scada sono di una pesantezza allucinante.

Non è certo questa la prima volta

Qui si parla di un fatto oggettivo, che nemmeno in casa Siemens possono negare.

Casomai, ho sempre fatto notare che tutti hanno difetti

Solo per fare un veloce esempio, in un recente passato ho avuto occasione di lavorare con i plc Panasonic. Per certi versi sono delle macchine stupende, ma quando salta fuori che in online riesci a fare un numero limitato di modifiche (credo dipenda dalla complessità delle modifiche stesse) e poi ti ritrovi a dover ricompilare tutto e ad arrestare l'impianto, per me diventa un prodotto da scartare nel 90% almeno dei miei utilizzi.

E anche il cross reference lascia molto a desiderare, punto invece di forza di Step7.

Diverso il discorso delle funzioni di libreria di Step7.

Diciamo che quando mi sono cimentato personalmente nella costruzione di una funzione analoga ho sempre raggiunto il risultato con funzioni più leggere.

In parte è dovuto, tanto per rimanere più o meno in tema, al fatto che molte funzioni sono state scritte proprio in SCL.

In parte invece è perché una funzione di libreria deve adattarsi a molteplici esigenze.

Per arrivare allo stesso risultato con funzioni più leggere, per ogni funzione se ne dovrebbero creare magari 4-5, ognuna delle quali dovrebbe svolgere un unico compito.

Tanto per fare un esempio con una funzione tra le più gettonate: FB41 CONT_C (PID).

E' una funzione apparentemente complicata, con molti più parametri di quelli strettamente necessari.

Questa complicazione è dovuta al fatto che la stessa funzione può essere utilizzata lavorando direttamente con i valori degli ingressi e delle uscite analogiche, oppure con valori ingegneristici in REAL.

Per semplificare le cose, sarebbero state necessarie 4 diverse funzioni.

Forse, alla fine, è più facile studiarne una ed imparare quali sono i parametri da utilizzare per il caso specifico. E ti accorgi così che in meno di 5 minuti (concedo una veloce ripassata al manuale in linea della funzione) hai già fatto un PID.

Altra cosa invece complicata di Siemens, è il modo di fare diagnostica.

[Livio Orsini]

Io non ho mai sostenuto che Siemens sia esente da difetti.

Ammetto di aver volutamente esagerato, ma l'occasione era troppo ghiotta , visto che sei sempre pronto ad insorgere quando si picchia su Siemens.

Poi se dici che nessuno PLC è esente da difetti affermi una verità evidente. Ci sono difetti più o meno gravi e difetti più o meno sopportabili in funzione delle abitudini/preferenze dell'utente.

Il difetto di Panasonic, che citi ad esempio, a parer mio è molto fastidioso e rivela una non ottimizzazione delle tecniche di controllo dei programmi. In effetti eseguire modifiche on line, con macchina funzionante, è un'operazione molto delicata che presuppone controlli molto accurati dei dati che vengono scaricati e dei tempi in cui si effettua lo scambio tra vecchia versione e nuova.

In queste operazioni ritengo che Siemens sia tra i più sicuri ed affidabili.

Poi ci sono difetti che personalmente ritengo molto indisponenti. Ad esempio io trovo la gestione dei dati quasi assurda. Sarà perchè provengo dal mondo dei microprocessori.

[mubeta]

Per favore, apriamo un eterno thread sui linguaggi e difetti di PLC, in cui parteciperemo tutti.

Frazionare il discorso qua e là in vari thread, oltre che O.T. sta diventando cervellotico.

Modificato: 20 agosto 2010 da mubeta