Jump to content
PLC Forum

fiorezzz

Linguaggio SCL come vi trovate ?

Recommended Posts

fiorezzz

Buongiorno a tutti

Stavo provando a fare un po di SCL traducendo dei blocchi in AWL / KOP in SCL principalmente istruzioni di assegnazione stato uscita ovvero
uscita:= MerkerA and MerkerB and not MerkerC    ecc.ecc 

 

Abbastanza comoda la scrittura ma poi in debug non mi sembra poi cosi tanto comodo/immediato 

 

Poi se i nomi delle variabili sono piuttosto lunghe sui monitor dei portatili  potrebbe essere un pò un problema  obbligando a spezzettare le righe di codice

nei casi un po complessi  

 

Voi come vi trovate  ?

 

 

 

 

Link to post
Share on other sites

Marco Mondin

Ci sono parecchie discussioni, anche accese sull'argomento.
Tuttavia la traduzione diretta in SCL(ST) di AWL e LADDER non è una buona idea per il debug, il quale diventa molto più arduo!
In testo strutturato meglio cambiare paradigma di sviluppo.
Lo stile combinatorio si fa anche in SCL, ma meglio lo stile sequenziale, magari con macchine a stati.
Per il combinatorio puro è più leggibile il LADDER.


Nello stile sequenziale:
In ogni sequenza ci sono una manciata di righe, semplici o commentate bene.
Per il debug è necessario usare i break point con tutto ciò che ne può conseguire.
Se progettato bene il debug è più semplice.
Se progettato male è da suicidio debuggare e i dead lock sono dietro l'angolo.

Se fatto bene con le CPU più piccole ci si fa il mondo in quanto ad ogni ciclo gira una manciata di righe di codice e non tutto o buona parte dell'applicativo come in combinatorio, magari anche con qualche sequenza qua e la.

Ci sono pro e contro, dipende da tante cose, e ciò che può essere migliore per uno può non esserlo per altri.
In germania a causa di softwaristi che fanno disastri con il sequenziale, in molte realtà obbligano all'uso del combinatorio.
In casi estremi, nell'automotive proibiscono anche l'uso dei SET e RESET! Questo perché a fronte di tutti i pro che ci possono essere, fare disastri è molto più semplice, soprattutto improvvisando codice con poca progettazione a monte.

Come dicono tutti in giro non esiste il linguaggio migliore in assoluto, ma quello che veste meglio sulle proprie abitudini di sviluppo e sullo stile di progettazione scelto.

Edited by Marco Mondin
Link to post
Share on other sites
batta
27 minuti fa, fiorezzz ha scritto:

Abbastanza comoda la scrittura ma poi in debug non mi sembra poi cosi tanto comodo/immediato 

Concordo.

Infatti io non condivido la filosofia di chi scrive tutto in strutturato. Il testo strutturato è ottimo per altri compiti, non per quello dell'esempio.
Proprio per questo trovo molto utile la possibilità che offre il TIA di creare blocchi misti, con segmenti in ladder, segmenti in strutturato e, volendo, segmenti in awl.

Link to post
Share on other sites
Marco Mondin
33 minuti fa, batta ha scritto:

Concordo.

Infatti io non condivido la filosofia di chi scrive tutto in strutturato. Il testo strutturato è ottimo per altri compiti, non per quello dell'esempio.
Proprio per questo trovo molto utile la possibilità che offre il TIA di creare blocchi misti, con segmenti in ladder, segmenti in strutturato e, volendo, segmenti in awl.


   Tuttavia una grossa realtà del packaging a noi impone tutto in ST, tant'è che su B&R abbiamo dovuto riscrivere buona parte del codice che avevamo pronto in C in ST.
Siamo riusciti a farci abbuonare giusto una libreria dimostrando che sarebbe stato un suicidio riscriverla.
Alla fine, anche se purtroppo dai miei toni (Rileggendo cosa ho scritto penserei anche io così) sembra che io sia un malato di ST posso condividere i vari punti di vista.
Quello che mi irrita un po' è quando mi obbligano a fare tutto con un solo linguaggio. Che poi io tenda a mischiare più ST, C, C++, Javascript mischiando il processo tra PC e PLC non mi piace guardare il mondo con il paraocchi! Se ho una libreria di calcolo sviluppata in C++ non capisco perché debbano obbligarmi a riscriverla in ST facendo esplodere il codice nonché rendendolo illeggibile.

Questo sotto altri punti di vista può essere vero anche nel confronto con un LADDER.

Per esempio questo piccolo pezzo di codice in C++, scritto in ST diventa un suicidio! Fare un prodotto tra quaternioni non è certo semplice come la sesta riga di questo esempio! In una manciata di righe correggo un errore di posizionamento di una telecamera per aggiustare un tracking ottico su un robot cartesiano a polso sferico.

    if (setFirstTansform) {
        m_rotationTuning = QQuaternion::fromEulerAngles(pitch.last(), yaw.last(), roll.last()).inverted();
        m_translationTuning = QVector3D(xOrig - x.last(), yOrig - y.last(), zOrig - z.last());
    }
    QQuaternion rotation = QQuaternion::fromEulerAngles(pitch.last(), yaw.last(), roll.last());
    rotation = m_rotationTuning * rotation;
    pitch.last() = rotation.toEulerAngles().x();
    yaw.last() = rotation.toEulerAngles().y();
    roll.last() = rotation.toEulerAngles().z();
    x.last() = x.last() + m_translationTuning.x();
    y.last() = y.last() + m_translationTuning.y();
    z.last() = z.last() + m_translationTuning.z() + m_zOffset;

 

Edited by Marco Mondin
Aggiunta esempio
Link to post
Share on other sites
Adr1

la programmazione deve essere fatta con lo scopo di ottenere il risultato migliore, con un compromesso bilanciato tra efficenza di stesura, di collaudo e di ricerca del guasto sul campo. 

Alle volte può essere più semplice scrivere in linguaggio strutturato, alle volte no.  In collaudo e ricerca guasti è quasi sempre più immediato leggere il ladder. Sopratutto per quei manutentori che non conoscono le basi del linguaggio strutturato ma che magari devono potersi arrangiare senza avere un programmatore che li supporta.

 

Da abolire totalmente e dare alle fiamme secondo me, e spero che un giorno si arrivi a questo, è la lista istruzioni (awl di siemens). A mio parere completamente inutile, difficile, macchinoso, poco leggibile e sostituibile senza rimpianti.

 

Link to post
Share on other sites
Marco Mondin
29 minuti fa, Adr1 ha scritto:

la programmazione deve essere fatta con lo scopo di ottenere il risultato migliore, con un compromesso bilanciato tra efficenza di stesura, di collaudo e di ricerca del guasto sul campo. 

...

C'è comunque da dire che se la diagnostica è ben fatta, con sinottici che rappresentino tutta la sensoristica, messaggistica adeguata (In un software di palletizzazione per esempio noi abbiamo 478 messaggi tra Allarmi, Stop e Warnings ed abbiamo un logger per i messaggi che arrivano dalle apparecchiature di campo dove i messaggi non si possono nemmeno contare) non dovrebbe essere necessario guardare il sorgenti per trovare un guasto. Per fare un esempio noi siamo anche riusciti a dire ad un operatore in Polonia che un cavo di un motore del gripper era rotto dalla semplice lettura dello storico messaggi al telefono.
D'altro canto è anche vero che si deve trovare il cliente disposto a spendere per la diagnostica, che se fatta bene può portare via veramente tante ore di sviluppo.
In questi casi dover aprire il sorgente in caso di guasto lo reputo un po' un fallimento personale.

Edited by Marco Mondin
Link to post
Share on other sites
leleviola
49 minuti fa, Adr1 ha scritto:

Da abolire totalmente e dare alle fiamme secondo me, e spero che un giorno si arrivi a questo, è la lista istruzioni (awl di siemens). A mio parere completamente inutile, difficile, macchinoso, poco leggibile e sostituibile senza rimpianti.

 

pensa te a me l'hanno chiesto un mese fa un'azienda che mi aveva contattato per un'offerta di lavoro e che richiedeva esplicitamente l'uso di tale linguaggio per mantenere la compatibilità con vecchi software, non è ora di passare ad altro, tipo SCL o ST? Bah! non so che dire, è come se volessi programmare il mio PLC con la tastiera di una volta dei vecchissimi PLC anni 80-90 con le istruzioni AND, OR, MCR, etc.etc. ormai non me le ricordo più. Mi pare un po' tutto desueto, è vero si fanno cose che non si fanno in KOP o FUP ma è ora di passare ad altro. Alla mia risposta di no, mi hanno risposto ma un programmatore deve saper programmare anche questo, al che ho detto, Va beh! Ok

Link to post
Share on other sites
pigroplc
15 ore fa, fiorezzz ha scritto:

Abbastanza comoda la scrittura ma poi in debug non mi sembra poi cosi tanto comodo/immediato 

io mi rendo la vita più semplice semplicemente cambiando riga quindi
da:
uscita:= MerkerA and MerkerB and not MerkerC    ecc.ecc 

a:

uscita:= MerkerA and 
             MerkerB and
             not MerkerC
  and 
             ecc.ecc 

in questo modo quando metti in visualizzazione di test non ti esplode la condizione logica spostando il resto verso il basso.

Inoltre utilizzando le regioni viene molto comodo da sezionare i blocchi 

 

Link to post
Share on other sites
fiorezzz
49 minuti fa, pigroplc ha scritto:

io mi rendo la vita più semplice semplicemente cambiando riga quindi
da:
uscita:= MerkerA and MerkerB and not MerkerC    ecc.ecc 

a:

uscita:= MerkerA and 
             MerkerB and
             not MerkerC
  and 
             ecc.ecc 

in questo modo quando metti in visualizzazione di test non ti esplode la condizione logica spostando il resto verso il basso.

Inoltre utilizzando le regioni viene molto comodo da sezionare i blocchi 

 

 

Va bene ma scritto cosi mi sembra un simil  AWL  and/U  and not/UN   ecc   

Concordo un pò con tutti  ma che AWL vada abolito  mi sembra un pò tanto azzardato 

 

 

Link to post
Share on other sites
Marco Mondin

Invece in ST sarei più propenso a scrivere:

IF merkerA AND merkerB AND NOT merkerC THEN
   uscita := TRUE;
   (* uscitaAttivata := TRUE *)
ELSE
   uscita := FALSE;
   (* uscitaDisattivata := TRUE *)
END_IF

Nel caso di debug, potrebbe risultare ostico monitorare il tutto se i merker causano attivazioni molto rapide.
Decommentando le righe commentate e mettendo su un watch uscitaAttivate ed uscitaDisattivata, in modo da poterli resettare manualmente controllo se è passato di lì. Posso ottenere una informazione fondamentale in debug.
Usando l'IF, posso anche usare eventuali break point!!! Fondamentali in alcune parti in ST.

Può anche capitare che invece di booleane per controllare il passaggio in debug usi dei contatori:

IF merkerA AND merkerB AND NOT merkerC THEN
   uscita := TRUE;
   attivazioni := attivazioni + 1; (* Riga che rimuovo dopo il debug *)
ELSE
   uscita := FALSE;
   disattivazioni := disattivazioni + 1; (* Riga che rimuovo dopo il debug *)
END_IF


L'uso degli IF permette in caso di necessità la più veloce implementazione di condizioni annidiate in caso di modifica.
Per esempio se volessi avere la commutazione solo con merkerA attivo:

IF merkerA THEN
   IF merkerB AND NOT merkerC THEN
      uscita := TRUE;
   ELSE
      uscita := FALSE;
   END_IF;
END_IF;


Nell'esempio ho usato delle variabili di appoggio per il debug, una soluzione pratica e veloce, nella realtà noi usiamo un logger ed abbiamo una function che ci permette di fare uscire sul logger quello che vogliamo.
Questo è uno spaccato di codice che fa vedere l'uso del logger:
 

.......
    IF seq = 10 THEN
        IF mainCnc.isValid() THEN
            IF (oldSeq <> seq) THEN
                Gateway.messagesMng.advDebug('Initializing MainCN (X, Z)...');
            END_IF
            retValCN0 := mainCnc.cmdInit(FALSE, TRUE);
        ELSE
            retValCN0 := AdvMethDone;                
        END_IF
        IF unit1Cnc.isValid() THEN
            IF (oldSeq <> seq) THEN
                Gateway.messagesMng.advDebug('Initializing Unit1 CN...');  
            END_IF
            retValCN1 := unit1Cnc.cmdInit(FALSE, TRUE);
        ELSE
            retValCN1 := AdvMethDone;                
        END_IF
......
......
    IF seq = 30 THEN
        IF status = statusRequest THEN
            IF status = MachineStatus.NO_INIT THEN
                Gateway.messagesMng.advDebug('Error initializing MainMachine!');
                retVal := AdvMethError;
                cmdInit := retVal;
            ELSE
                Gateway.messagesMng.advDebug('MainMachine initialized!');
                retVal := AdvMethDone;
                cmdInit := retVal;
            END_IF
.......

Tutto ciò che passa in "Gateway.messagesMng.advDebug('.......');" esce su un logger in HMI.

Il risultato è il seguente:

Tornio1.png.63d25ff0768267943ffda08c15f387c9.png

Edited by Marco Mondin
Link to post
Share on other sites
batta
1 ora fa, Marco Mondin ha scritto:

Invece in ST sarei più propenso a scrivere:


IF merkerA AND merkerB AND NOT merkerC THEN
   uscita := TRUE;
   (* uscitaAttivata := TRUE *)
ELSE
   uscita := FALSE;
   (* uscitaDisattivata := TRUE *)
END_IF

Nel caso di debug, potrebbe risultare ostico monitorare il tutto se i merker causano attivazioni molto rapide.

Come ho già scritto più volte, il ladder non è certo il mio linguaggio preferito, ma non mi puoi dire che questo risulta più facile da debuggare rispetto all'analogo programma (flags di debug e/o contatori compresi) scritto in ladder. Al massimo, su una cosa così semplice, ti concedo la parità ;-)

 

Poi, anche su come scrivere in strutturato, è una questione di gusti. Per esempio, tra le due scritture qui sotto, personalmente preferisco la seconda.

// Modo 1
IF merkerB AND NOT merkerC THEN
	uscita := TRUE;
ELSE
	uscita := FALSE;
END_IF;

// Modo 2
uscita := merkerB AND NOT merkerC;

 

Link to post
Share on other sites
batta
14 ore fa, Adr1 ha scritto:

Da abolire totalmente e dare alle fiamme secondo me, e spero che un giorno si arrivi a questo, è la lista istruzioni (awl di siemens). A mio parere completamente inutile, difficile, macchinoso, poco leggibile e sostituibile senza rimpianti.

Invece a me dispiace che AWL stia per essere messo in disparte. Mi impongo di non usarlo ma, per alcuni compiti, presenta ancora dei vantaggi. Faccio un esempio banale, e non certo esaustivo, solo per rendere l'idea:

// Reset di due variabili booleane e set di una terza
// In strutturato:
IF #condizione THEN
	#boolVar_1 := #boolVar_2 := FALSE;
	#boolVar_3 := TRUE;
END_IF;

// In AWL:
A #condizione
R #boolVar_1
R #boolVar_2
S #boolVar_3

Sinceramente, non ci trovo proprio nulla di difficile, macchinoso e poco leggibile nelle righe in AWL.

Poi, se scrivi un segmento, magari di una certa complessità, in ladder, e lo traduci in AWL, allora certo che ne risulta qualcosa di illeggibile, ma solo perché stai usando AWL nel modo sbagliato. Ma ti ritroveresti con qualcosa di illeggibile anche se tu volessi convertire passo passo da ladder a strutturato.
 

Link to post
Share on other sites
Marco Mondin
7 minuti fa, batta ha scritto:

Poi, anche su come scrivere in strutturato, è una questione di gusti. Per esempio, tra le due scritture qui sotto, personalmente preferisco la seconda.

 

Concordo pienamente... Questione di gusti ed abitudini 😉
Alla fine le cose importanti sono fare le cose bene, che funzionano bene ed in modo metodico e pulito (Qualunque sia il metodo), avere il cliente e/o i collaboratori soddisfatto/i ed avere il giusto appagamento economico che ci permetta di vivere questo fantastico lavoro nel modo più sereno possibile (E farci salassare dal socio occulto "Scusa il sarcasmo").  

Link to post
Share on other sites
batta
4 minuti fa, Marco Mondin ha scritto:

Alla fine le cose importanti sono fare le cose bene, che funzionano bene ed in modo metodico e pulito........

Su questo è impossibile non essere completamente d'accordo 👍

Link to post
Share on other sites
ETR

Sarà che mi sono sempre trovato bene con il Pascal a scuola, per cui liberarmi dell'AWL e passare all'ST è stato semplice e conciliante per poter applicare funzioni più evolute (tant'è che la cosa inversa in più occasioni non mi è riuscita, anche con l'aiuto di gente che di AWL ne masticava assai). Lo sviluppo di codice per robot ABB, quaternioni a parte, è stata anch'esso molto più facile avendo adottato ST come standard.

 

Cercando di migliorare anche la programmazione in C, che purtroppo zoppica, mi piacerebbe vedere un miglioramento del debug di ST (io parlo per B&R) che non vorrei dire una cavolata, aver colto alcuni mesi fa in twincat. Adesso non ricordo perfettamente, ma su un codice non di ns produzione, ho trovato alcuni strumenti utili.

 

Buona giornata, Ennio

 

 

 

 

Link to post
Share on other sites
Marco Mondin
39 minuti fa, ETR ha scritto:

Sarà che mi sono sempre trovato bene con il Pascal a scuola, per cui liberarmi dell'AWL e passare all'ST è stato semplice e conciliante per poter applicare funzioni più evolute (tant'è che la cosa inversa in più occasioni non mi è riuscita, anche con l'aiuto di gente che di AWL ne masticava assai). Lo sviluppo di codice per robot ABB, quaternioni a parte, è stata anch'esso molto più facile avendo adottato ST come standard.

Effettivamente il passaggio inverso, più ci si spinge verso i paradigmi più moderni dell'informatica più tende a diventare non solo difficile, ma in alcuni casi impossibile.

B&R supporta ST, ma non completo e pone alcuni paletti decisamente irritanti, tuttavia ad oggi che io sappia (ma io non so certo tutto, anzi) gli unici a implementare completamente la IEC61131-3 sono i derivati CODESYS e CODESYS stesso, TwinCat è un derivato CODESYS di beckhoff, il quale come tanti produttori che derivano da CODESYS aggiungono loro librerie. Tuttavia i linguaggi e le librerie base sono identiche. Tant'è che sviluppando in CODESYS puro non di rado leggo alcune cose nei manuali Beckhoff che in alcuni casi sono fatti meglio.
B&R di contro implementa il C (di cui purtroppo ha snaturato la stdlib per porre seri paletti ed obbligare a comperare licenze per alcune funzioni come l'accesso ad alcuni filesystem, ma dal punto commerciale ci può stare), ma soprattutto il C++ (Purtroppo non con il C++11 e C++17, ed io mi ci sono viziato un po' sento la mancanza delle lambda function etc...), e grazie a quest'ultimo permette anche esso una programmazione pura OOP come CODESYS con ST. Tuttavia molti committenti non accettano C e C++ se non per compiti molti particolari e comunque storcendo il naso.

ABB mi pare che nei PLC non B&R usi CODESYS, non so se è così anche nella robotica.

Edited by Marco Mondin
Link to post
Share on other sites
Adr1

perchè non accettanno il c alcuni committenti?

 

 

Link to post
Share on other sites
Marco Mondin
19 minuti fa, Adr1 ha scritto:

perchè non accettanno il c alcuni committenti?

Perché hanno tutto il personale preparato per altro (ST, LADDER etc...)
Non mettono mai le mani sul progetto, ma se io domani dovessi schiattare dicono che necessitano di un teorico paracadute!
Anche se poi convengono anche loro che progetti molto grossi sono difficili da prendere in mano, in quanto non basta la conoscenza del linguaggio, ma si dovrebbe conoscere progetto, stile di progettazione, paradigmi seguiti etc...
Tuttavia l'unico committente che ce lo impone ha effettivamente del personale ben preparato in ST con conoscenza di OMAC e OOP, dei quali hanno anche stilato una dispensa interna per allineare tutti i loro softwaristi.

 

Ora capisco modificare piccole cose del processo, come nastri di trasporto etc, ma suvvia! Chi avrebbe mai voglia di smazzarsi un calcolatore dinamico di percorsi misti spline/bezier con calcolo della dinamica di percorso in 3 dimensioni scritto da un'altro?
 

È un po' come se io volessi vedere il codice del NCInterpolator di Codesys! Non si fa! Punto e basta!

Edited by Marco Mondin
Link to post
Share on other sites
Adr1
9 minuti fa, Marco Mondin ha scritto:

Chi avrebbe mai voglia di smazzarsi un calcolatore dinamico di percorsi misti spline/bezier con calcolo della dinamica di percorso in 3 dimensioni scritto da un'altro?
 

È un po' come se io volessi vedere il codice del NCInterpolator di Codesys! Non si fa! Punto e basta!

 

Non ho capito una sola parola ma il concetto è chiaro.

Link to post
Share on other sites
Cesare Nicola

Circa un paio di settimane fa, in Russia nella marmellata fino al collo per quello che sembrava un problemone, ho intravisto, per un istante, un contatto in KOP diventare verde quando non avrebbe dovuto: "controllate la fotocellula"! Problema risolto, tutti contenti e cena a base di vodka! In ST non sono sicuro che avrei colto al volo quello sfarfallio di fotocellula; in AWL non so, magari sì. Questo per dire che sequenze (relativamente) semplici, fatte in KOP sono molto semplici da debuggare. Detto da uno che fino a quattro anni fa, erroneamente, riteneva  KOP una cosa da mezze calzette.

@pigroplc Tu eri già a casa, questa te la sei persa. 😀 

Link to post
Share on other sites
pigroplc
19 ore fa, Cesare Nicola ha scritto:

@pigroplc Tu eri già a casa, questa te la sei persa. 😀 

 😃 😃 😃 😃 😃
eh sennò chi ti avrebbe sopportato tutta la cena, a disquisire sui contatti si e contatti no!!!

  😃 😃 😃 😃 😃

Link to post
Share on other sites
leleviola

il Ladder se ben fatto e strutturato come si deve da molto più aiuto per verificare e risolvere problematiche, questo è indubbio

Link to post
Share on other sites
pigroplc
1 ora fa, leleviola ha scritto:

il Ladder se ben fatto e strutturato come si deve da molto più aiuto per verificare e risolvere problematiche, questo è indubbio

Su questa affermazione potrei anche essere d'accordo, ma quando in ladder si comincia a fare delle operazioni matematiche con tutti quei box io mi ci raccapezzo veramente molto male. Mi vengono letteralmente i vermi.

SCL per sempre per me, almeno per le formule.

 

Link to post
Share on other sites
leleviola
1 ora fa, pigroplc ha scritto:

SCL per sempre per me, almeno per le formule.

 

infatti i software che ne permettono l'uso misto del ladder insieme allo strutturato sono la metodologia migliore,

io vengo dal vecchio assoluto dove il ladder la faceva da padrone ed ero abituato a fare i salti mortali per fare i calcoli con le normali istruzioni matermatiche fatte una dietro l'altra magari utilizzando un unico registro per fare più operazioni in sequenza, adesso mi sento riavere con ST o SCL ma so da cosa vengo e capisco cosa vuol dire, ho fatto pure calcoli trigonometrici con il ladder per derivare da un angolo una misura lineare.....

la tecnologia va avanti per fortuna

Link to post
Share on other sites
DavidePizz

Perdonatemi vorrei dire la mia...

a parte lo spazio in generale che occupa la scrittura in KOP... solo quella mi ha fatto passare la voglia di programmare tanto da passare al SCL. 
l’opzione CASE credo sia la cosa più bella che esista, soprattutto quando vengono commessi degli errori in scrittura o ci sono guasti. Basta leggere lo stato della variabile intera associata al case, e andare direttamente al punto segnalato. fine.

E sì, si può programmare tutto in scl, la differenza è solo visiva all’inizio, poi non potete più farne a meno.

 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...