Assegnazione in e out in blocchi

[Silvio_G]

Salve a tutti, 

Sono alle prese con un problema su Step7 V5.6 SP1 e non so se è risolvibile. Ho due blocchi che utilizzo in un FB e ognuno ha la sua interfaccia di uscita e ingresso. Se a questi due blocchi assegno un blocco dati separato, cioè non li creo come multi-istanza posso assegnare all'ingresso di uno direttamente l'uscita dell'altro. Per esempio se il primo blocco ha un'uscita chiamata "RIFERIMENTO" e il blocco associato di nome "DB_ROUTINE" posso assegnare sul secondo direttamente al pin di ingresso il valore "DB_ROUTINE.RIFERIMENTO" e non mi da errori (e soprattutto il tutto funziona).

Se adesso i due blocchi li definisco in multi-istanza e associo il nome all'istanza "ROUTINE", provando a scrivere in ingresso del secondo blocco "ROUTINE.RIFERIMENTO" il sistema reagisce dicendomi che non posso farlo dato che sto mettendo un output in un input. Il problema lo risolvo passando da variabili temporanee volendo, ma il prolificare di variabili rende meno leggibile il programma, oltretutto avendo come ingresso direttamente il nome del blocco da cui viene il dato in uscita mi da chiaramente l'idea in un secondo del flusso dati.

Qualcuno ha avuto il medesimo problema? Penso sia un errore del compilatore e magari da qualche parte esiste un'impostazione per farglielo ignorare.

 

Notare che in TIA Portal la stessa procedura non mi da errori col procedimento in multi-istanza o col procedimento passando da DB separati.

[pigroplc]

forse non ho capito bene, ma basta che l'output lo dichiari come input/output e dovrebbe funzionare.

[batta]

La variabile "RIFERIMENTO" è dichiarata come OUT.
Se colleghi ad un ingresso del blocco "DB_ROUTINE".RIFERIMENTO, colleghi una variabile di un DB. Che sia un DB di istanza, non fa differenza: ogni variabile di un DB, anche di istanza, può essere letta e anche scritta.
Quando, invece, dichiari il blocco come multiistanza, e accedi con ROUTINE.RIFERIMENTO, non interroghi direttamente il DB di istanza, ma le variabili all'interno del blocco. Il compilatore, in questo caso, si accorge che la variabile RIFERIMENTO è dichiarata come OUT, e non gli piace che tu la voglia usare come IN. Il compilatore ha ragione.
Appoggiati ad una variabile temporanea, non c'è nulla di male in questo e, se alla variabile dai un nome comprensibile, non è vero che rende il codice meno leggibile.
In alternativa, anziché dichiarare RIFERIMENTO come OUT, la dichiari come INOUT.

[Silvio_G]

Grazie batta,

 

Non si può fare e questo è quanto. Peccato

 

Il fatto che un uscita output non possa essere assegnata ad un input non è normale che sia una restrizione, se il compilatore fosse furbo dovrebbe segnare eventualmente errore il viceversa. E' chiaramente un "buco" risolto in TIA portal dove la stessa cosa la posso fare. Ora: il compilatore non ha sempre ragione se fosse così avrebbero mantenuto la stessa filosofia anche in TIA non ti pare? Ma i tedeschi hanno sempre ragione!

 

 

 

 

[batta]

Il TIA è migliorato sotto tantissimi aspetti rispetto al Simatic Manager.

Ma, ad essere precisi, non è il TIA che accetta questa scrittura, ma le CPU S7-1200/1500. Se, col TIA, provi a scrivere la stessa cosa con una CPU S7-300, non la accetta.
Evidentemente, il compilatore 1200/1500 non si limita a controllare il tipo di variabile (IN, OUT, INOUT), ma fa un controllo più approfondito.
Io però non lo definirei un baco, ma solo una restrizione che, nei nuovi sistemi, è stata superata.
Si tratta solo di sapere cosa il compilatore digerisce, e cosa no. Poi, come detto, la soluzione non mi pare poi tanto complicata.

Mi pare però ci sia sempre una certa predisposizione alla lamentela: anziché essere contenti per il miglioramento, ci si lamenta perché nel (oramai) vecchio sistema c'era questo limite.
Se torniamo al S5, vedrai che di limiti ce n'erano molti di più.

[pigroplc]

49 minuti fa, batta ha scritto:

Mi pare però ci sia sempre una certa predisposizione alla lamentela: anziché essere contenti per il miglioramento, ci si lamenta perché nel (oramai) vecchio sistema c'era questo limite.

😁😁😁 d'accordo al 100%

[Cesare Nicola]

Il 9/1/2020 alle 15:36 , batta ha scritto:

Mi pare però ci sia sempre una certa predisposizione alla lamentela

Tra un po' servirà una sezione apposita del forum "critiche a Siemens". 🙂

 

Il 9/1/2020 alle 13:07 , Silvio_G ha scritto:

se il compilatore fosse furbo dovrebbe segnare eventualmente errore il viceversa

Se ho ben capito ciò che vuoi fare, il compilatore te lo accetta ma ti segna l'istruzione in giallo e se ci vai sopra col mouse, ti dice che non è consigliato l'accesso in lettura a quella variabile. Quindi, diciamo che il compilatore se accorge ma ti lascia scegliere: a me è capitato sia di fregarmene e lasciarlo così, sia di usare una variabile di appoggio.

[batta]

Credo che la cosa sia un po' diversa.
Si tratta di collegare un parametro di uscita di una FB all'ingresso di un'altra FB. Se le FB hanno il loro DB di istanza, il compilatore vede solo che si tratta di un bit di un DB, e accetta la scrittura.
Se, invece, le due FB sono dichiarate come multiistanza all'interno di un'altra FB, il compilatore vede che si sta cercando di mettere in ingresso una variabile dichiarata come OUT. In realtà si tratta dell'OUT di un'altra funzione, quindi sarebbe corretto accettarlo. Probabilmente, il compilatore del 300 si limita a considerare che si tratta di una variabile OUT e, erroneamente, non te lo lascia fare. Con il 1500, invece, è possibile. Evidentemente, il 1500 effettua dei controlli più approfonditi.

Silvio ha quindi ragione nel sostenere che quanto sta facendo è corretto. Si tratta di un limite del compilatore del 300. In ogni caso, io lo definirei un peccato veniale, visto che si può ovviare in modo estremamente semplice, con l'appoggio ad una variabile temporanea.

Ribadisco che la differenza non è tra Simatic Manager e TIA, ma tra cpu 300-400 e cpu 1200-1500.

Aggiungerei che trovo sensato mettere ancora le mani su un 300 solo per modifiche ad impianti già esistenti. C'è chi usa ancora il 300 per nuovi lavori e, questo, proprio non lo capisco.
Non dimentichiamo che il 300 sta arrivando al phase out (se non ci sono novità, era previsto per il 2020), che le CPU e i moduli del 300 costano di più dei corrispondenti del 1500, che il 1500 è superiore sia in termini di memoria che di prestazioni. E, da non trascurare, una volta investito il tempo necessario all'apprendimento del TIA, al Simatic Manager non ci torni più.

[acquaman]

 

29 minuti fa, batta ha scritto:

Non dimentichiamo che il 300 sta arrivando al phase out

 

Da questo Documento si parla non prima del 2023.

[batta]

Grazie, Acquaman.
Comunque, il 2023, per chi fa il nostro lavoro, è dopodomani. Che senso ha fare nuovi lavori con un PLC vicino al suo fine vita, quando esiste un degno sostituto, con prestazioni superiori e che costa meno?

[Cesare Nicola]

15 ore fa, batta ha scritto:

C'è chi usa ancora il 300 per nuovi lavori e, questo, proprio non lo capisco.

Da noi lo si fa su impianti che sono più o meno simili da tanti anni, per riciclare il software e risparmiare sui tempi di sviluppo. Ne stiamo uscendo, però, con mia soddisfazione. 🙂

 

[Silvio_G]

Ciao a tutti,

 

Mi sono riconnesso al forum solo l'altro ieri

 

Grazie delle risposte Poi alla fine ho optato per delle variabili d'appoggio chiamate in maniera diciamo "furba" mettendo come prefisso il blocco che le scrive in uscita.

Purtroppo avrei fatto volentieri rinuncia al simatic manager passando al TIA; Mi sono lasciato irrimediabilmente convincere dal cliente ad usare un progetto già esistente e, dato che usa anche una CU320 programmata con starter non posso convertire il tutto per importarlo in TIA dato che lo stesso non supporta i telegrammi liberi che invece si potevano gestire in simatic manager. Interpellata SIEMENS mi hanno detto che è così e basta e se voglio devo ristrutturare anche tutto il progetto starter (un delirio).

Quindi sono rimasto bloccato al simatic manager. 

La via migliore sarebbe stata rifare tutto utilizzando una 1500 e ci avrei messo meno tempo. Poi mi sono abituato ad usare l'SCL per scrivere le routine di regolazione e con l'AWL ero capace ma attualmente sono arrugginito.

Vabbè pazienza tutto è bene ciò che finisce bene.

 

Per quanto riguarda il phase-out della 300 spero che sappiano quello che fanno perché decisamente scoprirebbero la gola a VIPA che è già li che si frega le mani visto che essa può garantire continuità di pezzi di ricambio sulle linee già esistenti. Poi c'è da tenere presente ciò che è già stato studiato dagli utenti che non sono certo propensi a cambiare sistema. Notare che le VIPA, a quanto pare, si possono programmare anche col TIA. 

 

Silvio

[batta]

10 minuti fa, Silvio_G ha scritto:

scoprirebbero la gola a VIPA

Io non credo. Chi vuole usare VIPA, già oggi lo fa.
E credo che Siemens non sia interessata a mantenere in vita ancora troppo a lungo il 300.
VIPA, essendo programmabile come un S7-300, sicuramente si potrà programmare anche con TIA (come si fa anche con il 300), ma le differenze tra 300 e 1500 non sono solo nel sistema di sviluppo (come appena detto, si può usare TIA anche con il 300), ma proprio nelle prestazioni e delle funzioni in più supportate dal 1500.
Molti limiti che spesso vengono attribuiti al Simatic Manager, in realtà non sono del sistema di sviluppo, ma delle CPU S7-300.
Gli stessi limiti si trovano anche nel TIA, quando si programma un S7-300.
Io mi sono sempre trovato bene con S7-300 (mentre ho sempre detestato, e continuo a detestare S5), è stato un grande PLC, ma ha fatto il suo tempo. È ora di farlo uscire di scena.
VIPA potrà giovarsi di una uscita di produzione del 300 per qualche anno, ma poi sarà VIPA che si dovrà aggiornare proponendo alternative compatibili con il 1500. Accordi commerciali permettendo, ovviamente.

[acquaman]

17 minuti fa, Silvio_G ha scritto:

Per quanto riguarda il phase-out della 300 spero che sappiano quello che fanno perché decisamente scoprirebbero la gola a VIPA

Il 300 rimarrà ma fornibile solo come ricambio ad un prezzo maggiorato ancora per moltissimi anni, calcola che siemens ha definitivamente cessato qualunque fornitura dell'S5 in questo periodo.

Si dovrà passare ai plc di nuova generazione.

Su Vipa dubito possa disturbare siemens manterrà la sua fettina di mercato. 

[ken]

5 ore fa, Silvio_G ha scritto:

CU320 programmata con starter non posso convertire il tutto per importarlo in TIA dato che lo stesso non supporta i telegrammi liberi che invece si potevano gestire in simatic manager.

Scusa? Non mi sembra vera questa cosa. Io uso i telegrammi liberi senza problemi.

Puoi usare anche starter con tia portal, non è vietato. Devi solo creare un file gsdml con starter.

[Cesare Nicola]

12 ore fa, Silvio_G ha scritto:

importarlo in TIA dato che lo stesso non supporta i telegrammi liberi che invece si potevano gestire in simatic manager. Interpellata SIEMENS mi hanno detto che è così e basta

Ho usato solo una volta, tre anni fa, i telegrammi liberi, di solito uso il telegramma 111. Il progetto era fatto con TIA V13 e gli azionamenti erano parametrizzati con Starter. Nessun problema. Come ha detto @ken, per usare Starter devi importare nella configurazione dispositivi il gsd della CU320 che trovi da qualche parte sul sito Siemens (attenzione alla versione di firmware, ogni versione ha un suo GSD). Se invece usi Stardrive integrato nel TIA V15 o superiore, supporta i telegrammi liberi e puoi non usare Starter. Anche i tecnici Siemens sbagliano, a volte. 😃

[batta]

Confermo quanto detto da Ken e da Nicola: anche nel TIA puoi gestire i telegrammi liberi.

Se il drive è gestito da StartDrive, non hai nemmeno bisogno di Starter. In questo caso, potresti non poter gestire tutti i telegrammi.
Se il drive non è gestito da StartDrive, o se vuoi più libertà nella gestione dei telegrammi, allora nel progetto TIA inserisci il GSD e parametrizzi il drive con Starter, come facevi con Simatic Manager.

 

Io, se mi trovo a lavorare con progetti sviluppati in Simatic Manager, se l'hardware utilizzato me lo consente (TIA non gestisce hardware troppo vecchio), faccio la migrazione in TIA.
 

[leleviola]

Scusate l'intromissione ma con i blocchi SINASPEED e SINAPOS i telegrammi usati sono fissi o possono essere modificati a piacere? Nel senso se ho da trattare informazioni in più lo posso fare? Purtroppo io con Siemens sono un po' indietro e cerco di recuperare...

[batta]

Con SinaSpeed e SinaPos i telegrammi sono fissi, ma puoi configurare telegrammi aggiuntivi.

Oppure, puoi leggere e scrivere altri parametri con SinaPara e SinaParaS.

[leleviola]

Ottima dritta batta, come sempre