Il Simbolico Poco Simbolico - S7 ci è i ci fa?

[TRUNC]

Sto riscrivendo in Siemens il software di un modello di macchina precedentemente fatto con Allen Bradley.

Sono partito con l'ottica di creare dapprima il simbolico importando la tabella delle variabili esportate da RS Logix, così il lavoro di scrittura del codice si è ridotto grossomodo alla mera copiatura, ne più ne meno.

E fin qui tutto bene.

Ora, dopo aver ripulito un po' il software da vari ammenicoli inutili, vorrei riorganizzare la memoria lavorando sul simbolico, ma incontro alcune difficoltà. In pratica, quando vado a modificare il simbolico (sto lavorando con la preferenza operando impostata su simbolo) e poi voglio, per esempio, interrogare lo stato di occupazione della memoria o avere la lista dei simboli non più utilizzati, devo prima aprire tutti i blocchi di programma e richiuderli salvando dove necessario !!!

Esiste per caso una procedura o un settaggio per far aggiornare le tabelle di occupazione senza fare questo passaggio?

Sto usando Step 7 v5.2, ma volendo posso passare alla 5.3, anche se sto aspettando di avere un po' di tempo libero per farlo.

Grazie.

[bigalex]

Non credo funzioni così.

Tieni presente che se fai delle modifiche alla tabella del simbolico poi devi salvarla e dopo ridai il comando di aggiornamento al cross reference.

Per l'occupazione dei merker, input , output etc. non c'è bisogno di avere la corrispondenza col simbolico .

Il problema è forse l'approccio procedurale sicuramente diverso da Allen Bradley .

bigalex

[Piero Azzoni]

" Il problema è forse l'approccio procedurale sicuramente diverso da Allen Bradley "

sante parole

per vario tempo si e' dicusso su questo forum sulle differenze tra i plc terrestri e siemens, poi l'argomento e' passato di moda

ma i problemi rimangono proprio tutti

( ma come sono polemico ... ma come sono polemico ... )

[Claudio Monti]

[TRUNC]

Tieni presente che se fai delle modifiche alla tabella del simbolico poi devi salvarla e dopo ridai il comando di aggiornamento al cross reference.

Esempio: Ho reindirizzato degli ingressi aventi come simbolo I:2.0/x (notazione Allen Bradley) da un'area di ingressi Ennn.n ad un'altra. Salvato il simbolico e richiuso. Risultato? Se andavo a interrogare i dati di riferimento per individuare quelli inutilizzati, con mia grande sorpresa mi ritrovavo tutti gli ingressi che avevo appena indirizzato come inutilizzati, e neanche con il comando File-Riorganizza si risolveva il problema, salvo, ripeto, aprire e richiudere tutti i blocchi di programma (almeno una trentina... ).

Ora ho provato anche con l'aggiornamento del cross-reference, ma niente da fare.

Forse sono io che sono abituato troppo bene, ma quando lavoro con il simbolico del GE, per esempio (Cimplicity ME), queste cose sono assolutamente trasparenti e ogni modifica si riflette automaticamente su tutto il progetto, senza bisogno di ulteriori passaggi.

[bigalex]

Ho proprio l'impressione che stai cercando di mutuare un approccio in un ambiente che ragiona diversamente.

Consiglio : Fai l'attribuzione di tutti gli elementi (merker,ingressi,uscite etc.), poi inizia la programmazione .

Se devi aggiungere degli elementi al programma poi occorre solo attribuirgli il relativo simbolico e tutto funziona.

Onestamente non mi è mai capitato di avere problemi del genere con Step7.

Ribadisco che se pensi in "allen-bradley" e non in "siemens" è facile incontrare ostacoli .

bigalex

[FabioS]

Non sono sicuro di aver capito esattamente il tuo problema.

Ma penso il tuo problema sia

(sto lavorando con la preferenza operando impostata su simbolo)

, se la caratteristica a cui ti riferisci e quella delle cartelle offline.

Se tu devi, da quanto ho capito, cambiare indirizzo assoluto mantenendo lo stesso nome simbolico ad un'operando, imposta la preferenza su valore assoluto e vedrai che tutto si aggiorna.

In linea di principio, io perlomeno faccio così, uso la preferenza assoluta.

[Supertony]

...prova, dopo una modifica sostanziale al simbolico, a posizionare il mouse sulla cartella Blocchi, pulsante destro, "verifica coerenza blocchi", e poi selezionare il pulsante "compila tutto".... è la stessa cosa di aprire tutti i blocchi e salvarli, più o meno. Comunque, il fatto di spostare aree di memoria tramite il simbolico e la preferenza sul simbolo, per me non è corretta... in quel caso, a mio avviso, è meglio lasciare la preferenza all'indirizzo, e fare un bel RICABLAGGIO, cosa che aggiorna anche la cross reference!

Io, in passato, oltre a questo sistema ne ho usato anche un altro: ho generato la sorgente di tutti i blocchi dando la preferenza al simbolo, poi ho scambiato un po' tutto a mio piacimento sulla tabella dei simboli (e anche dentro ad alcune DB strutturate in modo coerente), poi ho ricompilato la sorgente di cui sopra... e tutto è andato a posto da solo, in quanto il compilatore ha associato ogni simbolo scritto nella sorgente con l'indirizzo presente in quel momento nella tabella dei simboli. E' un passaggio un po' delicato, ma con un po' di pratica permette di scrivere interi programmi a tavolino senza preoccuparsi del cablaggio di ingressi e uscite, per poi sistemare tutto in un solo passaggio alla fine...

[JumpMan]

Il ricablaggio è una bella cosa, ti permette anche di reindirizzare in pochi secondi un'intera scheda da 32E/A (Se per esempio si sposta una scheda da 32 ingressi dal 1° al 2° slot basta scrivere ED0 - ED4 e poi spuntare "considera ........"), però ,secondo me ,potevano anche aggiungere una spunta tipo: "ricabla anche simbolico", allora sì che sarebbe veramente comodo!

Così com'è ora si deve prima "ricablare" il codice e poi si devono riportare le stesse modifiche anche sugli indirizzi del simbolico...........

Forse è per questo che TRUNC lascia la preferenza sul simbolo e "ricabla" semplicemente ridigitando l'indirizzo sulla tabella simboli.

Solo che a volte si crea qualche casino perchè è necessario intervenire manualmente...

pulsante destro, "verifica coerenza blocchi", e poi selezionare il pulsante "compila tutto".... è la stessa cosa di aprire tutti i blocchi e salvarli, più o meno.

Questa non la sapevo, anch'io aprivo tutti i blocchi e salvavo, ma poi ho abbandonato la "preferenza simbolo"........preferisco fare il ricablaggio + la correzione dei simboli che avere errori di compilazione...

(Mi sa che queste cose con la prima versione di S7 non esistevano, si lavorava con l'assoluto e basta).

E dire che con il 200 è tutto più semplice:

- se i blocchi sono visualizzati in simbolico:

......... è possibile cambiare gli indirizzi sulla tabella simboli

- se i blocchi sono visualizzati in assoluto:

......... è possibile cambiare i nomi simbolici sulla tabella simboli

Il tutto senza errori e ammennicoli vari...

Forse era troppo semplice !

[TRUNC]

...prova, dopo una modifica sostanziale al simbolico, a posizionare il mouse sulla cartella Blocchi, pulsante destro, "verifica coerenza blocchi", e poi selezionare il pulsante "compila tutto".... è la stessa cosa di aprire tutti i blocchi e salvarli, più o meno.

Mi sa che questa è proprio la risposta alla mia domanda . Grazie SuperTony (Manero?) Adesso ci provo subito.

Ad ogni modo....

Ribadisco che se pensi in "allen-bradley" e non in "siemens" è facile incontrare ostacoli

... non mi va di fare polemiche inutili, ma qui non si tratta di pensare in "allen bradley" piuttosto che in Siemens o in altri sistemi, ma di buon senso e di logica.

Forse è per questo che TRUNC lascia la preferenza sul simbolo e "ricabla" semplicemente ridigitando l'indirizzo sulla tabella simboli.

... infatti, l'idea era questa, e grosso modo funziona (perchè non dovrebbe, altrimenti a cosa servirebbe il simbolico?), salvo l'essere costretti, se si vuole che siano aggiornate anche le tabelle dei riferimenti incrociati (... ma che razza di pretese da un programma pressochè gratuito come S7, vero? Sono proprio incontentabile... ), al passaggio indicato da SuperTony o, nella peggiore delle ipotesi, all'apertura e chiusura di tutti i blocchi!!!

[TRUNC]

Confermo che il trucchetto della ricompilazione di Supertony, che torno a ringraziare, sembra funzionare: non è il massimo della velocità, ma è sempre meglio che aprire e richiudere tutti i blocchi

Volevo inoltre puntualizzare, Tony, che quando dici che...

... ho generato la sorgente di tutti i blocchi dando la preferenza al simbolo, poi ho scambiato un po' tutto a mio piacimento sulla tabella dei simboli (e anche dentro ad alcune DB strutturate in modo coerente), poi ho ricompilato la sorgente di cui sopra... e tutto è andato a posto da solo, in quanto il compilatore ha associato ogni simbolo scritto nella sorgente con l'indirizzo presente in quel momento nella tabella dei simboli. E' un passaggio un po' delicato, ma con un po' di pratica permette di scrivere interi programmi a tavolino senza preoccuparsi del cablaggio di ingressi e uscite, per poi sistemare tutto in un solo passaggio alla fine...

... in pratica descrivi esattamente ciò che sto facendo io, ad eccezione dell'aspetto della generazione dei sorgenti, che è superflua.

Questo è un modo di operare molto comodo, per i motivi che tu stesso hai descritto, e che con altri PLC io uso regolarmente (*), ma che, su Siemens, inspiegabilmente porta un po' di disagi. Ed è un peccato.

(*) pensa che con alcuni non è più neanche necessario indirizzare le variabili, eccetto naturalmente gli I/O; quando hai bisogno di un merker dichiari una variabile booleana e la usi senza farti problemi di dove va a finire in memoria. Molto vicino ai linguaggi ad alto livello, insomma.

[TMlm]

(*) pensa che con alcuni non è più neanche necessario indirizzare le variabili, eccetto naturalmente gli I/O; quando hai bisogno di un merker dichiari una variabile booleana e la usi senza farti problemi di dove va a finire in memoria. Molto vicino ai linguaggi ad alto livello, insomma.

io non condannerei del tutto il modo di gestire la memoria si S7, almeno finchè i plc in commercio non adottano dei server opc integrati o tecnologie equivalenti.

se infatti lasciamo completamente al compilatore (quasi un gioco di parole) la libertà di assegnare simboli alle locazioni di memoria, saremmo poi costretti in fase di costruzione di un progetto hmi a rivolgerci a scada o terminali operatori dello stesso produttore del plc.

come farebbe il produttore "pinco pallino" che costruisce interfacce macchine a garantire il collegamento alle variabili? anche se riuscisse a farlo con siemens, dovrebbe poi ripetersi con omron ecc.. ecc..

ciao..

[Federico Milan]

pensa che con alcuni non è più neanche necessario indirizzare le variabili, eccetto naturalmente gli I/O; quando hai bisogno di un merker dichiari una variabile booleana e la usi senza farti problemi di dove va a finire in memoria. Molto vicino ai linguaggi ad alto livello, insomma.

Bisogna distinguere tra comodità e usabilità, sicuramente usare linguaggi ad alto livello facilita la vita, ma si abbandona la realtà hardware ... nessuno (quasi) programma in assembly oramay i PC di casa, perchè visto la moltitudine di risorse e i SO moderni non ha più senso e si può astrarre l'hardware sottostante.

Il PLC attualmente è ancora una macchina limitata, e troppa astrazione pregiudicherebbe il suo utilizzo. Sicuramente un giorno molto vicino questo sarà possibile (attualmente alcuni PLC utilizzano moduli XML per la configurazione ... ), ma tuttora - io personalmente - non vedo l'utilità di questo, in quanto sicuramente la produzionesoftware non migliorerebbe in termini di leggibilità, facilità, manutenzione ...

Ovviamente il tutto deve essere organizzato secondo sani principi software e non con il vecchio "codice spaghetti" ...

come farebbe il produttore "pinco pallino" che costruisce interfacce macchine a garantire il collegamento alle variabili? anche se riuscisse a farlo con siemens, dovrebbe poi ripetersi con omron ecc.. ecc..

In parte concordo con TMIm, anche se comunque ci sono soluzioni alternative ...