Vai al contenuto
PLC Forum


Dalla specifica di progetto a "esposizione discorsiva - step by step - flow chart" allo schema logico e Ladder diagram


Paolo30

Messaggi consigliati

Un saluto a tutti sono un neo iscritto e mi chiamo Paolo.

Circa un paio di anni fa ho seguito un corso base di PLC su marca Siemens ed Omron.

Dopo aver svolto il corso mi sono esercitato per conto mio a casa utilizzando i vari software Tia Portal - Cx programmer - Sysmac studio e altro.

Ho eseguito numerosi esercizi verificandoli nei vari ambienti dedicati alla simulazione.

Mi sono accorto però che manca il tassello fondamentale di tutta l'attività ....vale a dire la parte progettuale.

In effetti durante il corso non abbiamo affrontato il progetto a partire dalla specifica.

 

A questo punto chiedevo aiuto e consiglio a voi..........

In particolare la domanda precisa è questa:

Io ho un problema di automazione ed ho delle specifiche di progetto.

Dopo aver effettuato lo studio preliminare descrivo il problema step by step  oppure con un diagramma di flusso come se devessi affrontare il problema con linguaggio di alto livello C o altri.

Il problema per me è passare ad esempio dal diagramma di flusso o step by step al LADDER DIAGRAM o allo schema logico.

 

Il LADDER DIAGRAM è un linguaggio di basso livello stile elettrotecnico o elettricista ma che per me è più difficile da affrontare anche rispetto al testo strutturato.

Quindi come faccio io a partire dalle specifiche progettuali a disegnare lo schema logico del sistema di automazione ?

Come faccio a tradurre il problema di automazione in schema logico e ottenere il ladder diagram?

Mi piacerebbe avere da voi più esperti un modus operandi oppure materiale didattico in pdf.

Ho risfogliato anche i corsi affrontati ma in effetti non viene affrontato il problema della progettazione a livello didattico ci sono tantissimi esempi ma non c'è di fatto nel corso una parte relativa al " come devo fare a progettare " come va fatto lo schema logico e come vanno fatti i vari segmenti di ladder.

 

grazie

 

Paolo

 

 

 

 

 

 

Link al commento
Condividi su altri siti


14 ore fa, Paolo30 ha scritto:

Il LADDER DIAGRAM è un linguaggio di basso livello stile elettrotecnico o elettricista ma che per me è più difficile da affrontare anche rispetto al testo strutturato.

Io non amo particolarmente il ladder ma, per la logica booleana, è il linguaggio più immediato ed intuitivo che esiste.
Prova a ragionare considerando il ladder non come contatti in serie e parallelo, ma come AND e OR.

Link al commento
Condividi su altri siti

Scusami batta considerare il ladder come AND e OR è un po' più dura, il linguaggio ladder come dice anche l'autore del post è giustamente una derivazione abbastanza diretta dagli schemi elettrici, una continuità circuitale che fa derivare tale metodologia direttamente da una formazione elettrotecnica e elettromeccanica, semmai se proprio non vuoi usare il ladder forse ti è più congeniale l'FBD, non tutti i PLC lo implementano ma puoi usare al limite quello per le tue schematizzazioni, se poi il PLC che usi non lo implementa sei costretto farne una conversione che poi non è affatto complicata

Modificato: da leleviola
Link al commento
Condividi su altri siti

1 ora fa, leleviola ha scritto:

Scusami batta considerare il ladder come AND e OR è un po' più dura

Personalmente, anche quando scrivo rami in ladder, non vedo il ramo come uno schema elettrico, ma ragiono poprio pensando alle varie condizioni combinate in AND e in OR: se ho "Condizione_1" e ho "Condizione_2" oppure ho "Condizione_3", allora eseguo questa operazione.
Trovo invece l'FBD di una scomodità totale.
Ovviamente, sono solo considerazioni personali.

Link al commento
Condividi su altri siti

4 ore fa, leleviola ha scritto:

il linguaggio ladder come dice anche l'autore del post è giustamente una derivazione abbastanza diretta dagli schemi elettrici,

 

Il "ladder diagram" fu parte integrante delle specifiche della gara indetta da General Motors per la costruzione di PLC(Programmable Logic Control). Questi dispositivi dovevano essere programmati con un linguaggio grafico che rieccheggiasse il più possibile gli schemi elettrici a relè. Doveva servire a sostituire gli armadi di relè con dispositivi più compatti e, soprattutto, più facilmente modificabili.

Laprogrammazione avveniva tramite tastiera su cui erano impressi i simboli di contatto in serie, contatto in parallelo, cotatto aperto, contatto chiuso, e via elencando.

Il progettista compilava i fogli con le sequenze a contatti, come fosse una usuale logica a relè; in seguito un operatore programmava una PROM, premendo gli opportuni tasti, per riprodurre la sequenza.

Il primopasso verso una procedura più snella e veloce si ebbe quando alcune aziende produttrici di logiche programmabili, usarono mini computer, della classe PDP8 prima, PDP11 poi, con un softare che emulava su di un terminale le riche di contatti in serie e parallale, similmenta a quanto si fa oggi con un PC, ma questo era adatto solo a grandi sistemi.

Personalmente ricordo che, alla fine degli anni '70, quando lavoravo in E Marelli, si usava un mini Westinghose che, con questo tipo di Sw, permetteva di effettuare l'automazione di un laminatoio.

Tutto questo perchè il sistema era volto a facilitare ilcompito degli elettricisti di manutenzione.

Oggi, dove praticamente tutti gli operatori in questo settore hanno competenze di programmazione, l'uso del linguaggio a contatti ha praticamente poco senso.

Personalmente, quando programmavo PLC, ho usato il "ladder diagram" solo quando non avevo alternativa. Con Siemes usavo AWL e, se il cliente lo richiedeva, facevo fare la traduzione al software siemens.

Se costretto, per mancanzadi alternative, all'uso del ladder (su alcuni vecchi PLC c'era solo questo), dovevo sempre tradurmi, mentalmente, gli AND ed OR in contatto serie e contatto parallelo.

Ovviamente questo dipende dal retroterra culturale della persona che elabora ilprogramma.

Link al commento
Condividi su altri siti

  • 3 weeks later...

Il problema principale consiste nel tradurre una specifica di progetto nello schema logico da cui si ottiene la frase logica.

Ovviamente concordo nel dire che un contatto in serie corrisponde an un AND nel linguaggio strutturato e un OR corrisponde ad un parallelo.

Ma per me la difficoltà sta a monte:

cioè partire dalla specifica progettuale ( ad esempio voglio costruire un sistema di automazione che gestisce elettronicamente un parcheggio di un grosso supermercato con fotocellule e sensori vari per aprire chiudere sbarre e un contatore .......etc )

a partire dalla specifica devo produrre gli schemi logici da cui ottengo le frasi logiche e a quel punto traduco in LADDER.

 

Cioè a me interessa in questo momento tradurre il progetto in uno schema logico e tradurlo direttamente in LADDER senza usare alcun linguaggio di alto livello.

A me interessa imparare come buttare giù gli schemi logici da cui poi posso ottenere le frasi logiche per tradurle poi in LADDER

( una volta fatto questo il LADDER lo posso tradurre in un linguaggio di livello più altro usando gli AND OR IF THEN .....etc).

Il tassello che mi manca è questo cioè disegnare direttamente gli schemi logici( schema elettrico).

Esiste un metodo per tradurli direttamente in LADDER?

Ad esempio per i linguaggi di livello più alto si può usare il diagramma di flusso che poi traduco in C o linguaggi analoghi.

Ringrazio cortesemente a chi può illuminarmi per il problema posto sul LADDER....

 

Paolo 

 

 

 

 

Link al commento
Condividi su altri siti

44 minuti fa, Paolo30 ha scritto:

A me interessa imparare come buttare giù gli schemi logici da cui poi posso ottenere le frasi logiche per tradurle poi in LADDER

( una volta fatto questo il LADDER lo posso tradurre in un linguaggio di livello più altro usando gli AND OR IF THEN .....etc).

 

Scusa ma a me sembra un ragionamento ... un po' contorto.

 

44 minuti fa, Paolo30 ha scritto:

Esiste un metodo per tradurli direttamente in LADDER?

 

E da almeno mezzo secolo che mi occupo di programmazione ma non mi sembra di aver mai sentito parlare di traduttori automatici di specifiche in ladder diagram.

44 minuti fa, Paolo30 ha scritto:

Cioè a me interessa in questo momento tradurre il progetto in uno schema logico e tradurlo direttamente in LADDER senza usare alcun linguaggio di alto livello.

 

Questa è la base della programamzione.

Proprio per questo motivo nelle software house di una certa dimensione ci sono almeno 2 figure professionali: l'analist ed il programmatore.

L'analista analizza il problenma di automazione (ma potrebbe anche essere un problema di un algoritmo di calcolo, tanto per fare un eesempio), lo suddivide in blocchi semplici e genera una specifica dettagliata o un diagramma di flusso.

Da queste specifiche o diagramma di flusso, un programmatore genera la codifica in un linguaggio adatto all'elaboratore in uso.

IL PLC non  altro che un eleboratore che, tra i vari jobs eseguiti in bacground, ne ha uno che esegue il programma generato dall'utilizzatore.

 

Prendendo come base di partenza il tuo esempio di un parcheggio di un grande magazzino (lavoro abbastanza elementare) si inizza con l'analizzare quali e quante risorse di I/O necessitano.

Vediamo un esempio minimo.

  • cancello di ingresso
  • rivelatore di veicolo presente al cancello di entrata
  • rivelatore di veicola transitato in entrata
  • cancello di uscita
  • rivelatore di veicolo presente al cancello di uscita
  • rivelatore di veicola transitato in uscita
  • contatore auotomezzi in ingresso
  • contatore automezzi in uscita
  • Segnalazione posteggio libero o occupato.

Un altro dato di progetto sarà anche il numero di posti disponibili.

 

Con queste informazioni si dtermina immediatamente il numero di ingressi e uscita necessari ed il loro tipo.

Si stabiliscono le funzioni necessarie come conteggio dei veicoli in ingresso, conteggio dei veicoli in uscita, comadare l'apertura del cancello di ingresso, comadare l'apertura del cancello di uscita, gestire la segnalazione libero/occupato, gestione della logica di autorizzazione all'apertura del cancello di entrata.

Fatta questa anlisi sarà pronto o il diagramma di flusso dettagliato o una specifica dettagliata.

Da questo documento si dovranno ricavare i blocchi delle istruzioni per ogni singola funzione.

 

Facciamo un esempio di un blocco elementare: gestione del cancello di entrata.

 

  • Il traduttore di prenza veicolo in ingresso segnala veicolo in attesa? Se no esco dalla funzione, se si passo al apsso successivo.
  • Il numero dei veicoli entrati ,meno il numero dei veicoli usciti, è miniore del numero massimo di posti totali del parcheggio? Se no esco, se si passo al passo successivo.
  • Apro il cancello, attendo che il rivelatore di passaggio veicolo abbia segnalato l'avvenuto passaggio, chiudo il cancelloed incremento il totalizzatore dei veicoli entrati.

A questo punto un programmatore junior deve essere in grado di codificare.

 

Ancora due annotazioni.

  1. Se analizzi attentamente la funzioncina sopra descritta ti accorgerai che manca ancora una cosa fondamentale.
  2. L'automazione di un parcheggio è un problema semplicissimo tanto che è uno degli esempi/esercizi canoanici per gli studenti di programmazione.

Considerazione finale.

Se dall'analisi dettagliata sopra esposta, non sei in grado di generare un programma in qualsivoglia linguaggio, significa che hai ancora molto da studiare.


Modificato: da Livio Orsini
Link al commento
Condividi su altri siti

Ciao,

la capacità di un buon programmatore PLC sta nel capire cosa si deve effettuare nel ciclo e poi tradurlo nel linguaggio più opportuno; normalmente, il ciclo vero e proprio si scrive in ladder o al limite in graph, mentre i dati si gestiscono con testo strutturato, sempre ammesso che si abbia un minimo di libertà di azione.

 

Sono anni ormai che non passo più dal diagramma di flusso per buttare giù un ciclo: come me lo spiegano (normalmente a voce), ho già in testa cosa devo fare e, cosa fondamentale, se ne sono in grado; a memoria avrò usato un diagramma di flusso solo un paio di volte: una perchè mi hanno costretto, lo voleva il cliente, ma l'ho scitto dopo che la macchina era già in funzione, ed una per dimostrare al progettista che non era possibile quello che mi chiedeva.

 

Poi, nel 90 per cento dei casi, il ciclo va ulteriormente modificato, perchè il progettista si è dimenticato di due cilindri che vanno in collisione o cose simili o anche peggiori.

 

Ci sono arrivato dopo 30 anni nell'ambiente e più di 15 come programmatore PLC.

Il nostro è un ambiente spietato, dove se ci vogliono 2 mesi per far girare un ciclo completo di una linea, sei fortunato se ti sono concesse 2 settimane; se perdi giorni per un diagramma di flusso, non riesci più a recuperarli.

 

Ha ragione Livio: l'unica soluzione è studiare, studiare, studiare e fare pratica, fare pratica, fare pratica; le conoscenze software non bastano, servono anche e, soprattutto, quelle per l'automazione; cos'è un cilindro pneumatico, cos'è un sensore, come funzionano abbinati, poi ci sono gli assi elettrici, i sensori ed i sistemi di visione, i marcatori e le stampanti, per non parlare poi di strumenti di misura e/o collaudo e via dicendo; non si può sganciare le due cose; non si può essere un buon programmatore PLC senza sapere come funzionano certi dispositivi nell'automazione.

 

Link al commento
Condividi su altri siti

Se il problema consiste nello studiare di più allora se  potete consigliarmi delle dispense pdf o dei libri o manuali in cui viene affrontata la programmazione dei PLC in LADDER ( e anche se viene spiegato come buttare giù lo schema elettrico da zero)?

Se scaricabili dalla rete ancora meglio.

 

saluti

 

Paolo

 

 

 

 

Link al commento
Condividi su altri siti

10 ore fa, Paolo30 ha scritto:

delle dispense pdf o dei libri o manuali

 

un tempo c'era un ottimo, secondo me, testo della Jackson che affrontava tutte le problematiche legate all'automazione di impianti tramite PLC. Non è che sia suffciente da solo ma, sempre a mio parere, è un'ottima guida. Se riesco arintracciare il sito dove è possibile scaricarlo ti mettoil link, perchè oggi è introvabile in librerira.

 

Poi ognuno ha la sua metodologia.

Io, ad esempio, dissento da Drugo. Il tempo dedicato all'analisi non è tempo perso,per me fa risparmiare molto tempo in fase di programamzione e di avviamento. Altri la pensano come me, mentre altri sono di parere simile a quello di Drugo.

Link al commento
Condividi su altri siti

14 ore fa, Paolo30 ha scritto:

Se il problema consiste nello studiare di più allora se  potete consigliarmi delle dispense pdf o dei libri o manuali in cui viene affrontata la programmazione dei PLC in LADDER ( e anche se viene spiegato come buttare giù lo schema elettrico da zero)?

 

Ti ripeto, ti serve prima imparare l'automazione ed i suoi componenti, in modo che saprai come gestirli; un programmatore PLC non può limitarsi a conoscere il software, anche se in maniera dettagliata; se poi non sa cos'è un asse elettrico, avrà sicuramente scritto il software tutto per bene, ma con il risultato che poi funziona male.

Per dispense e pdf non saprei cosa consigliarti; ai miei tempi ho imparato sul campo e documenti ne esistevano pochi; adesso, sicuramente la situazione è cambiata e qualcosa in più si trova sicuramente; prova a cercare.

 

4 ore fa, Livio Orsini ha scritto:

Poi ognuno ha la sua metodologia.

Io, ad esempio, dissento da Drugo. Il tempo dedicato all'analisi non è tempo perso,per me fa risparmiare molto tempo in fase di programamzione e di avviamento. Altri la pensano come me, mentre altri sono di parere simile a quello di Drugo.

 

Livio, non ho scritto che è tempo perso, ma che è tempo che non esiste; a me piacerebbe partecipare a riunioni sia con i progettisti meccanici che con quelli elettrici, ma non c'è ne il tempo, perchè sto ancora lavorando sulla commessa precedente; sarebbe bello e probabilmente mi risparmierebbe parecchie grane e modifiche successive, ma è così.

Ed è così non solo per l'azienda per cui lavoro adesso, ma chi più chi meno, per tutte le aziende che conosco.

 

L'abbiamo scritto diverse volte: i tempi di consegna si sono ridotti a dismisura, i clienti vogliono spendere poco e vogliono tutto e di più; qualcosa si riesce a standardizzare, ma, soprattutto per chi come me, a che fare con macchine tutte diverse una dall'altra, è una cosa difficile, se non addirittura impossibile.

In più tempo fa si aveva a che fare con un tecnico, adesso dall'altra parte c'è un commerciale, che non sente ragioni, che parla con un commerciale della tua azienda che non ti consulta, sempre per questioni di tempo.

Il risultato è che il programmatore PLC si cucca tutte le disfunzioni, dalla progettazione meccanica, a quella elettrica, a quella dovuta a comunicazioni sballate, quelle di assemblaggio; alla fine dovrà fare nottate per cercare di risolvere tutti i problemi, cercando al contempo di accontentare al meglio il cliente, il quale, ovviamente, chiede modifiche a non finire.

Se si fosse eseguita un analisi con tutti le componenti tecniche a priori, probabilmente il 90 % dei problemi sarebbero stati visti e risolti prima, ma quando si parla di tempo e soldi, chissà perchè, si finisce sempre per ridurre a zero il tempo di quelle analisi che, invece, sono fondamentali.

Aggiungo anche che un tempo, quando il cliente chiedeva modifiche, si analizzavano, valutavano e si aveva il tempo per tradurle in pratica; adesso, invece, probabilmente per esigenze di mercato, si tende ad accorpare le modifiche durante le prove finali, complicando non poco il lavoro del programmatore PLC.

 

Come ho scritto poco fa, sbagliato o meno, questa è la realtà attaule della maggior parte delle aziende che conosco, chi più, chi meno.

 

Se sono finito OT, chiedo scusa.

Modificato: da drugo66
Link al commento
Condividi su altri siti

4 ore fa, drugo66 ha scritto:

Il risultato è che il programmatore PLC si cucca tutte le disfunzioni, dalla progettazione meccanica, a quella elettrica, a quella dovuta a comunicazioni sballate, quelle di assemblaggio; alla fine dovrà fare nottate per cercare di risolvere tutti i problemi, cercando al contempo di accontentare al meglio il cliente, il quale, ovviamente, chiede modifiche a non finire.

 

Purtroppo questo è sempre accaduto, anche quando si dovevano usare i microcalcolatori perchè il PLC era pressapoco una grossa scatola piena di relè. Solo che un tempo accadeva meno del 50% dei casi, oggi si sfiora il 100%. Sui tempi di consegna tutti mentono sapendo di mentire spudoratamente.

Ciò non toglie che, a mio parere, partire buttando giù del codice senza farsi un'analisi di massima e scriversi una traccia fa perdere più tempo.

 

Ma, ripeto, ognuno ha il suo metodo. Io non riesco a lavorare senza aver fatto un minimo di analisi e di progettazione.

 

4 ore fa, drugo66 ha scritto:

Se sono finito OT, chiedo scusa.

 

Non credo che sia OT; anche questo serve a chi chiede lumi su come iniziare a far questo lavoro

Link al commento
Condividi su altri siti

Concordo che l'esperienza è l'elemento più importante e conoscere quanto più possibile (ovviamente non si può essere tuttologi) gli aspetti esterni alla programmazione (tipologia delle macchine / linee / processi, meccanica, elettrico, pneumatica) consente di avere una visione d'insieme che aiuta in fase di progetto, durante le correzioni dei problemi e anche durante l'inseguimento delle modifiche richieste del cliente.

 

Riprendendo la domanda iniziale, personalmente se la logica è semplice vado di AND / OR (serie / parallelo) senza un metodo particolare.

Se la logica è un po' complessa (es. per certi cicli di lavoro) ho trovato spesso utile usare le "macchine a stati finiti".

In estrema sintesi e semplificando un po':

- definisci degli stati (es. "pronta" , "movimento 1", "attesa feedback 1" ...)

- definisci le condizioni per il passaggio da uno stato all'altro (usando una combinazione dei segnali di ingresso oppure timer ...)

- definisci ogni uscita in base allo stato in cui si trova il sistema (es. "uscita 1" attiva nello stato "movimento 1" oppure nello stato "attesa feedback 1")

 

Quindi ti crei un diagramma con rettangoli (o cerchi) e frecce che descrivono la tua logica. In genere riesci ad avere una buona visione del tuo problema (almeno per me è così) con questo tipo di rappresentazione.

Il passaggio al programma può diventare "quasi automatico" e può essere implementato in qualsiasi linguaggio di programmazione (anche in ladder, ma per questo tipo di funzioni preferisco un linguaggio tipo SCL).

Gli stati diventano bit (TRUE se sei nello stato) oppure valori di una variabile (es. 10="Pronta", 20="movimento 1" ... ). Personalmente preferisco la seconda soluzione.

 

Ho sintetizzato molto, spero comunuqe di aver dato uno spunto per un eventuale approfondimento.

Ciao, Andrea

 

 

 

Link al commento
Condividi su altri siti

  • 4 weeks later...

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...