Vai al contenuto
PLC Forum


Convenzioni per assegnare simboli


Cesare Nicola

Messaggi consigliati

Mi trovo, non è la prima volta, a realizzare un software per un cliente che gradisce che i simboli rispecchino la sigla presente sullo schema; cioè, se il pulsante di marcia pompa sullo schema si chiama PB12005, anche il suo simbolo dovrà essere PB12005 e poi nel commento al simbolo si mette la descrizione "pulsante marcia pompa".
Nei software in cui posso decidere autonomamente, invece, non faccio mai riferimento allo schema ma uso la descrizione direttamente nel simbolo, per esempio "PulsanteMarciaPompa" o "Pulsante_marcia_pompa" (magari abbreviando pulsante con PU); da quando lavoro per quel cliente ho rimesso in discussione se il mio sistema sia davvero il più indicato. In parte mi rispondo da solo, dicendo che è indicato perché maggiormente riciclabile (un "pulsante_marcia_pompa" lo si trova in tante macchine) e perché utilizzabile anche quando gli schemi sono malfatti, suscettibili di modifiche se non addirittura inesistenti (sì, mi capita di fare software senza avere gli schemi elettrici). 

Sono quindi curioso di sapere come fate di solito, se c'è un modo che mediamente prevale su un altro.
 

Link al commento
Condividi su altri siti


Solitamente, io faccio db standard che posso usare per tutti i programmi, modificando solo il commento in base al simbolo o alla descrizione, come in questo caso:

image.png.da3bf4c52fd797061a54e89afe4b36c4.png

 

Ovviamente, in base al programma aumento, oppure, diminuisco i tag relativi, mantenendo comunque un buon numero di scorte.

Così nel caso venga aggiunto qualche variabile nuova, mi occore solo modificare il commento, e nemmeno reinizializzare la DB per caricarla.

 

Ciao Luca

 

 

 

 

 

Link al commento
Condividi su altri siti

2 minuti fa, Luca_99 scrisse:

Solitamente, io faccio db standard che posso usare per tutti i programmi,

Non avevo specificato che mi riferivo solo a ingressi/uscite, chiedo scusa; ciò che fai tu, mi sembra di capire, non è per quello.

Link al commento
Condividi su altri siti

Per ingressi ed uscite, anche io preferisco usare tipo "pulsante_marcia_pompa", o termini simili, mentre il simbolo lo aggiungo nel commento, ma questo vale per me siccome facciamo macchine per la nostra azienda e non per esterni, quindi non abbiamo richieste specifiche sulle definizioni.

Link al commento
Condividi su altri siti

Si trovano usate entrambi le versioni.

I tedeschi usano il tag uguale allo schema di cablaggio, i francesi fanno un mix P01-start per indicare Pulsante su ingresso 0.1 con funzione start.

Io non ho standard dipende da quello che mi viene in mente al momento.

Link al commento
Condividi su altri siti

Elemento dello schema per input e output. Anche se utilizzo encoder profinet il db di interfaccia si chiamerà come l'elemento a schema.

Gli schemi di dove lavoro sono poi a sezioni. 

La continua ogni motore ha un Gxx.

I simboli all'interno del FC dei riferimenti sono tutti Gxx.ref1 etc etc.

Stessa cosa per inverter e altre cose

Link al commento
Condividi su altri siti

Io preferisco usare un nome che identifichi la funzione, e mettere il riferimento allo schema nel commento.
Quasi sempre però mi vengono passate liste I/O già compilate in automatico dal software di cad elettrico, con la sigla come simbolo, e non mi metto a cambiare a mano centinaia di simboli.
Questo implica che, ogni volta che devo accedere ad un ingresso o ad un'uscita, li devo cercare nella tabella dei simboli.
Per ridurre al minimo il disagio, suddivido gli I/O in varie tabelle, con riferimento alla parte di macchina.
C'è da dire poi che la mia abitudine è quella di usare gli I/O come parametri di funzioni, quindi l'accesso diretto agli I/O è ridotto al minimo.
Per quanto riguarda le altre variabili, l'utilizzo dei merker è ridotto all'osso: variabili di sistema e poco più. Uso molto le FB, e quasi tutte le variabili che mi servono (con un nome significativo, che spesso nemmeno serve il commento) sono in pancia alla stessa FB. Ne guadagna molto anche la portabilità. Parametri di setup, che tendo ad organizzare in strutture in DB dedicati (così riduco al minimo la necessità di reinizializzare un DB con valori di setup), li collego alla FB passando in un solo parametro tutta la struttura che mi serve.

Link al commento
Condividi su altri siti

il 5/9/2019 at 19:19 , batta scrisse:

Quasi sempre però mi vengono passate liste I/O già compilate in automatico dal software di cad elettrico, con la sigla come simbolo, e non mi metto a cambiare a mano centinaia di simboli.
Questo implica che, ogni volta che devo accedere ad un ingresso o ad un'uscita, li devo cercare nella tabella dei simboli.

Esatto, è più o meno quello che capita a me, con questo cliente: si deve cercare nello schema o nella tabella dei dei simboli e diventa un po' una scocciatura.

 

il 5/9/2019 at 19:19 , batta scrisse:

Per ridurre al minimo il disagio, suddivido gli I/O in varie tabelle, con riferimento alla parte di macchina.

Idem 🙂

 

il 5/9/2019 at 19:19 , batta scrisse:

Per quanto riguarda le altre variabili, l'utilizzo dei merker è ridotto all'osso: variabili di sistema e poco più. Uso molto le FB, e quasi tutte le variabili che mi servono (con un nome significativo, che spesso nemmeno serve il commento) sono in pancia alla stessa FB. Ne guadagna molto anche la portabilità.

Io uso ancora parecchi merker ma sto lavorando per ridurli perché come fai tu (e non solo tu) è in effetti più che sensato. Sto anche provando, "cum grano salis" ad utilizzare accessi alle DB di istanza al di fuori del blocco che le utilizza; era una cosa che evitavo come la peste perché per me una variabile o è locale o è globale ma vedendo lavori fatti da un collega e da altri, sto diventando più possibilista. Con molta attenzione, ripeto, e non come abitudine, solo se la cosa apporta vantaggi reali.

Link al commento
Condividi su altri siti

2 ore fa, Cesare Nicola scrisse:

accessi alle DB di istanza al di fuori del blocco che le utilizza; era una cosa che evitavo come la peste perché per me una variabile o è locale o è globale

Ci sono i "puristi" che mai farebbero una cosa simile. Poi ci sono i pragmatici che, almeno fino ad un certo punto, guardano più la sostanza che la forma.

Cerco anch'io di evitare accessi esterni ai DB di istanza. Se possibile, i dati che devo scambiare col resto del mondo li dichiaro come parametri della funzione.
A volte però questi parametri sono così tanti che dichiararli uno ad uno diventa molto scomodo. Il richiamo stesso della funzione si presenterebbe come un blocco di dimensioni smisurate.
A questo punto, mi concedo qualche deroga, e accedo alle variabili del DB di istanza. Per rendere la cosa meno sporca, organizzo questi dati in una struttura all'interno della FB (e quindi del DB di istanza), oppure dichiaro tutta la struttura come I/O. Al richiamo della funzione, collego una struttura identica di un DB globale, e scambio i dati tramite il DB globale.
C'è da dire che anche i programmi sviluppati dagli stessi tecnici Siemens non disdegnano l'accesso ai DB di istanza. Forse ci facciamo troppi scrupoli. Del resto, non stiamo programmando in C.

Da tener presente poi che, dalla V15.1, i riferimenti incrociati ritrovano tutti gli accessi. Voglio dire, se posizioni il cursore del mouse su una variabile all'interno di una FB, nel cross reference vedi anche eventuali accessi fatti a quella variabile accedendo al DB di istanza. E, viceversa, se posizioni il cursore su una variabile del DB di istanza, vedi anche tutti gli accessi fatti nelle FB.

Link al commento
Condividi su altri siti

1 minuto fa, batta scrisse:

A volte però questi parametri sono così tanti che dichiararli uno ad uno diventa molto scomodo. Il richiamo stesso della funzione si presenterebbe come un blocco di dimensioni smisurate

Ecco, è proprio quello il motivo per cui sto, proprio in questo momento, per la prima volta utilizzando l'accesso al DB di istanza. 🙂

 

Link al commento
Condividi su altri siti

Io non sono cosi restio ad utilizzare le variabili d'istanza come variabili globali, si evita di avere più variabili per la stessa cosa che può creare confusione, addirittura sopratutto negli FB standard che creo per la mia libreria metto una pare della DB di istanza per l'HMI cosi richiamando l'FB mi trovi già tutto gestito compreso la parte HMI che spesso fa scopa con un FACEPLATE.

Categorico che la DB d'istanza DEVE ESSERE PERFETTAMENTE COMMENTATA in modo chiaro.

Link al commento
Condividi su altri siti

Personalmente dichiaro gli I/O come da schema , poi realizzo due Fc denominate FillInputs e FillOutputs dove mappo gli I/O fisici su delle strutture utilizzate sia nelle DB che per passare i dati nei vari FB / Fc che li richiedano (in genere li passo come  IN/OUT) tali strutture rappresentano per esempio la posizione di una macchina in un impianto e a loro volta sono suddivise in varie sottostrutture tipo IN e OUT dove mappo con dei nomi comprensibili senza prendere lo schema in mano i dati interessati.

Tale struttura mi permette di rimappare facilmente gli I/O per le varie funzionalità , magari adattandoli nella FillInputs negando eventuali segnali previsti come NO che magari arrivano da finecorsa NC.

 

Esempio strutture nella DB :

 

Cattura.PNG.cf8ea4f21898f80f9b365db98863a202.PNG

 

L'utilizzo di richiami a dati globali da FB lo faccio solo per FB dedicati (non riutilizzabili) di cui sfrutto la possibilità di mantenere dati Static all'interno della funzione e non a sparpagliarli in giro su dati globali.

I Merker che uso sono solo quelli di Sistema , per il resto li evito come la peste.

Esempio FillInput :

Cattura2.thumb.PNG.826b1d1ccffdfcb4afb6a904664a86ab.PNG

 

Tale metodo da' la flessibilità di rimappare i programmi in maniera veloce e di lavorare in blocchi funzione con dei nomi decenti.

 

Dei Merker uso solo quelli di sistema , per il resto li evito come la peste

 

Se usate le strutture , per i vari ingressi , potete facilmente riutilizzarle nei pannelli Siemens come parametri di ingresso nei FacePlate e risparmiare un sacco di tempo , standardizzando i vari programmi.

 

 

 

Modificato: da ifachsoftware
Link al commento
Condividi su altri siti

Il reindirizzare gli IO su delle DB l'ho già sentito non mi è mai capitato di vederlo e continuo a non capirne l'utilità, con il TIA e talmente veloce reindirizzare il simbolico che non capisco lo sbattone a rifarlo in SCL.

Link al commento
Condividi su altri siti

Crea un account o accedi per commentare

Devi essere un utente per poter lasciare un commento

Crea un account

Registrati per un nuovo account nella nostra comunità. è facile!

Registra un nuovo account

Accedi

Hai già un account? Accedi qui.

Accedi ora
×
×
  • Crea nuovo/a...