Evviva SCL! Che ne dite?

[barby]

Circa due anni fa ho iniziato ad usarlo, mi piace talmente che ora tutti i miei software sono sviluppati esclusivamente in SCL.

L'online non è intuitivo come il kop lo ammetto, ma posso fare copia-incolla tra TIA e Sysmac Studio ed è imbattibile combinato con gli array e le strutture.

Sequenze anche parecchio complesse possono essere gestite con il Select case e IF/END IF. Insomma sono innamorato 

 

 

 

[sorecaro]

Ciao, una domanda. Oltre la guida di Siemens  hai qualche libro/manuale da consigliarmi per avvicinarmi a questo linguaggio?

[walterword]

lo uso dal 2001 e ne ho sempre parlato bene.

Ti consiglio di non usarlo tutto , nel senso che per le logiche di campo , macchina , gestione modalità , passi automatici è meglio usare ladder che è piu veloce da scrivere , manutenere e soprattutto in fase di messa in servizio ed assistenza è immediato e ben equipaggiato .

Poi fai come vuoi , ma ricorda che sul posto ci saranno manutentori di estrazione elettromeccanica  

[walterword]

non serve nessuna guida ,ti basta la guida online , un simulatore e un po di pazienza a poi ti diverti un po.

I tipi di dati e le funzioni sono quelle , non è un linguaggio ad oggetti , non programmi su piattaforma pc , usi variaibli del plc per cui in 2 gg sai gia tutto ; 

[ifachsoftware]

Confermo quello che dice Walter : ogni linguaggio ha un suo perchè e ambiti applicativi specifici , altrimenti ne avrebbero fatto uno solo .......

SCL è validissimo per gestire formule e lavorare con array 

LADDER lo userei per tutta la gestione dei boolean in quanto che molto piu' leggibile di altre soluzioni

AWL lo userei solo dove non ne posso fare a meno (necessità assoluta di gestire le temporizzazioni)

SFC in tutti i processi sequenziali

FBD per i processi di controllo e regolazione

[barby]

esatto non servono guide per SCL, diciamo che nel mio caso sono stato avvantaggiato perchè smanettavo già da tempo con VBA per Autocad.

E' vero dovrei diversificare il codice e usare anche il ladder. E' solamente una mania personale, non mi piace il fritto misto! e poi sono del parere che se un manutentore deve entrare nel programma per capire come mai la macchina è ferma vuol dire che il programma stesso ha un problema (di diagnostica in questo caso).

[walterword]

il programmatore svolge attività diverse dal cuoco . Quello che piace a te o a noi è spesso fuori luogo .

Il servizio che si fornisce deve soddisfare requisiti tecnici ed essere di uso comune , documentato , ben strutturato , estensibile , chiaro ,ben manutenibile , modularmente organizzato .Se lavori a certi livelli devi sottostare a strutture ed architetture già prestabilite , aprire, cucire , chiudere . Progettare un software è paragonato alla progettazione di uno stabile , diversamente a certi livelli è quasi garantito il fallimento se non si rispettano certe regole .

Coding is art  

[dott.cicala]

Quote

Ti consiglio di non usarlo tutto , nel senso che per le logiche di campo , macchina , gestione modalità , passi automatici è meglio usare ladder che è piu veloce da scrivere , manutenere e soprattutto in fase di messa in servizio ed assistenza è immediato e ben equipaggiato .

Questa è da incorniciare.

Riuscissi a farlo capire ai miei colleghi  che si ostinano a fare tutto  in testo strutturato.....e poi perdono giorni  e giorni a capire perché una valvola non si eccita

[batta]

Quote

non mi piace il fritto misto!

Non si tratta di fritto misto.

Avere a disposizione più linguaggi e decidere di usarne uno solo assomiglia un po' all'autocastrazione

 

[walterword]

attualmente sto lavorando solo ed esclusivamente in awl , d'altronde la complessa comunicazione con il livello 2 e i vari server e client che devo far girare nei plc della rete sono notevoli e ladder non permette molte cose , come per esempio assegnare 4 caratteri ad un DINT oppure fare certi calcoli .

Nei blocchi di output o manuale etc comunque mantengo una struttura "semplice " del awl in modo tale che si possa visualizzare anche in ladder , dove possibile 

In awl sei molto piu veloce quando hao salti , assegnazioni , logiche etc tutto in un blocco o segmento .

Le funzione fc ed fb che lavorano sui blocchi dati strutturati in modo complesso sono spesso gia fatti per cui dopo un'accurata analisi uso quelli li o modifico per quello che mi serve . Sposare un linguaggio e' da "acerbi" o incompetenti , senza offesa alcuna 

[Livio Orsini]

Quote

nel senso che per le logiche di campo , macchina , gestione modalità , passi automatici è meglio usare ladder che è piu veloce da scrivere , manutenere e soprattutto in fase di messa in servizio ed assistenza è immediato e ben equipaggiato

 

Concordo pienamente.

 

Quote

non mi piace il fritto misto!

 

Non è questione di fritto misto, ma di pragmatismo: si usa lo strumento più adatto secondo bisogno.

Anche nella programmazione di micro elaboratori, dove oramai si pragramma quasi sempre in C/C++, se e quando occorre, si inseriscono funzioni/macro in ASM o anche semplicemente alcune righe specialistiche in assembler.

E' questione di ottimizzazione; con il linguaggio ad alto livello si ottimizza il tempo di sviluppo e manutenzione, con l'assembler si ottimizza il tempo di esecuzione.

[walterword]

il boot di un qualsiasi sistema operativo è sempre ed esclusivamente in assembly nativo della macchina su cui gira . Qua non si scappa 

[Novis]

Il 25/5/2016 alle 23:17 , barby ha scritto:

Circa due anni fa ho iniziato ad usarlo, mi piace talmente che ora tutti i miei software sono sviluppati esclusivamente in SCL.

......

 

 

Finalmente una persona che utilizza solo SCL.

[batta]

8 ore fa, Novis ha scritto:

Finalmente una persona che utilizza solo SCL.

Chi usa un solo linguaggio lo fa solo perché non è capace di usare gli altri.

 

3 ore fa, Yiogo ha scritto:

ai tempi che furono c'era solo IL-logic (quello che solo Siemens chiama AWL), fortunatamente è definitivamente tramontato

Ad essere pignoli, l'AWL di Siemens è diverso da IL.
A me, sinceramente, un po' dispiace che sia stato messo in disparte. Per alcuni compiti, ha ancora i suoi punti a favore.
 

Pienamente d'accordo sull'utilizzo di più linguaggi. Non riesco proprio a capire perché dovrei usare un solo linguaggio, quando ho la possibilità, in base al compito da svolgere, di utilizzare quello più adatto allo scopo.

[Colonial54]

Tipico degli ingegnerucoli sfornati dalle universita' odierne;

Imparano qualcosa e non vedono altro, restii a qualsiasi evoluzione;

Credo che oggi l'unico esame realmente necessario per laurearsi sia l'arroganza.

Giusto per la cronaca, ad uno di questi "personaggi" che aveva "scritto" un guazzabuglio di istruzioni in scl, (che in una discussione su quanto avevano scritto, neppure lui si raccapezzava piu') ho fatto bloccare i pagamenti finche' non avesse riscritto tutto in maniera cristiana: e' sparito, mai piu' visto ne sentito, probabilmente campera' alle spalle dei genitori.
 

[Operational Amplifier]

Buongiorno a tutti,

 

13 ore fa, batta ha scritto:

Chi usa un solo linguaggio lo fa solo perché non è capace di usare gli altri.

 

Personalmente prima di effettuare la scelta aziendale di utilizzare prettamente il linguaggio strutturato di linguaggi ne ho provati (sicuramente tutti quelli dello standard IEC 61131), secondo me il linguaggio strutturato offre una portabilità da prodotto a prodotto che altri linguaggi non offrono, naturalmente per scrivere prettamente in linguaggio strutturato devono esserci delle regole chiare e definite per non incappare nella confusione.

Di recente ho trovato una parte di programma sviluppata da un collaboratore, era tutta piena di IF annidati in altri IF con set e reset delle variabili in più punti in circa 150 righe di codice, scritto in questo modo sono d'accordo che non è debuggabile, se vengono definite delle REGION con relativi commenti e le variabili vengono gestite in un punto definito a noi sembra utile ed è per questo che lo abbiamo sposato.

 

Di recente sto lavorando con prodotti Beckhoff, arrivando dal mondo Siemens ed avendo i blocchi scritti in SCL sono riuscito a recuperarli effettuando dei semplici trova e sostituisci.

 

Premetto che questa è una mia impressione, quando i miei collaboratori mi parlano di altri linguaggi rispetto le loro scelte.

[Livio Orsini]

6 minuti fa, Operational Amplifier ha scritto:

secondo me il linguaggio strutturato offre una portabilità da prodotto a prodotto che altri linguaggi non offrono,

 

Verisimo, ed è l'unico modo per poter cambiare tipo "macchina" senza riscrivere tutto.

Le regole di buona programmazione si devono applicare comunque, indipendentemente dal linguaggio usato, anche se alcuni linguaggi sono più stringenti di altri verso queste regole.

[acquaman]

Sono impressionato, io dopo più di vent'anni di programmazione di macchine ed impianti (perchè come già detto in altri post, noi programmiamo macchine ed impianti non plc, il plc è solo l'attuatore) con i plc con i nuovi plc ed il nuovo ambiente, ho cominciato ad usare linguaggi che prima non usavo (GRAPH ed SCL) ed a tralasciarne altri (AWL), quindi come già accaduto in passato ho modificato il mio stile di programmazione ed è probabilmente cambierà ancora nel corso della mia carriera.

Il 26/1/2020 alle 03:06 , Novis ha scritto:

Finalmente una persona che utilizza solo SCL

Evidentemente non ho capito un c...o, scusate il francesismo, perchè qui abbiamo un profeta che non so in base a quale esperienza ha già capito tutto ed è sceso tra di noi per illuminarci. 

[batta]

2 ore fa, acquaman ha scritto:

Evidentemente non ho capito un c...o, scusate il francesismo, perchè qui abbiamo un profeta che non so in base a quale esperienza ha già capito tutto ed è sceso tra di noi per illuminarci. 

👍

 

2 ore fa, acquaman ha scritto:

ho cominciato ad usare linguaggi che prima non usavo (GRAPH ed SCL) ed a tralasciarne altri (AWL), quindi come già accaduto in passato ho modificato il mio stile di programmazione ed è probabilmente cambierà ancora nel corso della mia carriera.

Condivido. Addirittura, anche senza cambiare marca di PLC, ma solo passando da Simatic Manager a TIA ho cambiato molto il mio modo di programmare.
Spesso l'utilizzo di un linguaggio non è dovuto solo alle caratteristiche intrinseche del linguaggio stesso, ma molto dipende anche dagli editor del sistema di sviluppo.
Per dire, con i 300 il linguaggio che usavo di più era AWL. Usavo anche il ladder (soprattutto se mi veniva imposto da chi mi commissionava il lavoro), ma molto meno di quanto faccio ora con il TIA, perché l'editor KOP del SimaticManager non era così comodo. Addirittura, se dovevo programmare in KOP, quasi sempre scrivevo in AWL, rispettando la sintassi per poter visualizzare il segmento anche in KOP.
Anche l'editor SCL del SimaticManager non era un granché, e anche il debug dei blocchi in SCL era tutto fuorché comodo.
L'editor SCL del TIA invece, è un editor di tutto rispetto, sicuramente il migliore tra quelli (non moltissimi, 5 o 6) che ho provato.
Poi, la possibilità di inserire segmenti in SCL all'interno di un blocco in KOP, è di una comodità unica.
E, con tutto quello che c'è a disposizione, c'è chi sceglie l'autocastrazione, e programma solo in SCL. Sinceramente, non condivido.
L'unico motivo può essere, come dice "Operational Amplifier", per la portabilità. Io non mi sento di sacrificare tutto solo in nome della portabilità.

[Livio Orsini]

13 ore fa, batta ha scritto:

E, con tutto quello che c'è a disposizione, c'è chi sceglie l'autocastrazione, e programma solo in SCL.

 

E una sorta di mentalità manichea che ti fa ritenere che tutto debba essere o bianco o nero, mentre solitimante si tratta di differenti gradazioni di grigio.

Un approccio pragmatico al problema, ti porta ad usare il metodo ed il linguaggio più conveniente per la soluzione dei quel problema.

 

La portabilità è da tenersi in grande considerazione, specie quando si usano macchine differenti. Se si è legati principalmente ad un solo tipo di macchina, la portabilità perde valore. Anche se, a mio giudizio, è un attributo da valutare sempre con molta attenzione.

[Operational Amplifier]

1 ora fa, Livio Orsini ha scritto:

E una sorta di mentalità manichea che ti fa ritenere che tutto debba essere o bianco o nero, mentre solitimante si tratta di differenti gradazioni di grigio.

 

Effettivamente ho un po la mentalità manichea e tendo a vedere o tutto bianco o tutto nero...😅

 

1 ora fa, Livio Orsini ha scritto:

La portabilità è da tenersi in grande considerazione, specie quando si usano macchine differenti. Se si è legati principalmente ad un solo tipo di macchina, la portabilità perde valore. Anche se, a mio giudizio, è un attributo da valutare sempre con molta attenzione.

 

Utilizzando prettamente linguaggio strutturato oltre alla portabilità posso usufruire del controllo di versione del codice

[acquaman]

5 ore fa, Operational Amplifier ha scritto:

Utilizzando prettamente linguaggio strutturato oltre alla portabilità posso usufruire del controllo di versione del codice

Il controllo di versione sono anni che lo uso su tutti i progetti completi, dalla versione 16 del TIA il versioning è integrato.

[acquaman]

7 ore fa, Livio Orsini ha scritto:

La portabilità è da tenersi in grande considerazione,

Sicuramente è da tenere in considerazione e può essere un valido motivo per utilizzare l'SCL per una parte di codice che potrei riutilizzare, anche per dei blocchi da mettere in libreria, ma la gran parte del codice di una macchina e customizzato per quella macchina, e quindi può essere sviluppato con i linguaggi che uno ritiene più consono a quella parte di programma.

[Marco Mondin]

Il 27/1/2020 alle 08:21 , Livio Orsini ha scritto:

 

Verisimo, ed è l'unico modo per poter cambiare tipo "macchina" senza riscrivere tutto.

 

Questo dal mio punto di vista lo fa stravincere su tutto!
Lavorando con prodotti eterogenei mi permette una riciclabilità inimmaginabile. Di contro per non fare schifezze abominevoli richiede un po' più di preparazione sui paradigmi e sulle tecniche di programmazione.

Se un programma è scritto bene in Ladder si legge bene, se scritto bene in ST e/o C/C++ non ci trovo differenze ed il debug mi porta via lo stesso tempo. Se scritto male in Ladder da qualche cinghiale comunque ci si raccapezza, se scritto male in ST etc... è da suicidio fare debug.

Per altro se gli applicativi diventano molto grossi (più di 50000 linee di codice) il ladder diventa troppo dispersivo e ci andrebbe lo spazio di una enciclopedia per contenerlo.
Per non parlare del tempo! Se in ST ci metto 1600-2000 ore uomo per un progetto medio grande non immagino nemmeno quanto ci metterei in LADDER, ma certamente il committente non lo accetterebbe mai!
C'è anche da dire che non lavoro mai su implementazioni di linee, ma si singole macchine in piccole serie, in questo caso il discorso manutentore elettromeccanico è privo di senso! Il software è e deve restare chiuso e nessun elettromeccanico deve toccarlo, altrimenti al primo update tutte le sue modifiche finirebbero nella spazzatura e il produttore di macchine si troverebbe probabilmente una macchina difficile se non impossibile da mantenere.  

Poi se sono obbligato uso anche il LADDER, ma devo essere obbligato. Tuttavia anche in LADDER con i prodotti codesys derivati ci infilo il concetto di classi e polimorfismo, ed alla fine anche con il LADDER l'elettromeccanico medio non può più metterci mano in quanto è piuttosto difficile fagli capire cosa siano polimorfismo ereditarietà ed interfacce implementabili.

Modificato: 28 gennaio 2020 da Marco Mondin

[acquaman]

Continuate a considerare il software come il prodotto finito, cambiate mentalità, il prodotto è la macchina, questa deve essere manutenuta, può essere modificata, implementata con muove produzioni, impianti che nascono con uno scopo possono essere nell'arco della vita riadattare e riutilizzate, se compro un impianto per fare vino e dopo 2 anni decido di fare birra devo essere libero e nelle condizioni di farlo.

Queste errate considerazioni portano poi il cliente finale a imporre dei paletti (tipo imporre il ladder) perchè si è trovato in difficoltà con software troppo complessi e magari ha avuti un fermo produzione per un software troppo complesso dove il manutentore non è riuscito a trovare un guasto.

 

32 minuti fa, Marco Mondin ha scritto:

Tuttavia anche in LADDER con i prodotti codesys derivati ci infilo il concetto di classi e polimorfismo

 Se in ladder infili quei concetti hai sbagliato ad usare il ladder per quella parte di programma dovevi usare l'SCL.