Linguaggio SCL come vi trovate ?

[Cesare Nicola]

Il 1/3/2020 alle 01:11 , DavidePizz ha scritto:

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

Uso spesso anch'io il CASE in SCL ma ti garantisco che lo si può agevolmente costruire in KOP, incrementando una variabile e facendo un confronto sul valore. Basta un po' di ordine e il gioco è fatto: un segmento = uno stato del "CASE". E' efficacissimo e semplice da debuggare come o più che in SCL. Hai anche il vantaggio che può essere letto da un manutentore o da chi non conosce SCL e sono tanti ahimè; a noi viene a volte richiesto di usare il più possibile KOP, per quel motivo.

Lo spazio occupato dal KOP è spesso fastidioso, questo è vero, è un suo grosso limite. E' anche vero che a volte, se hai un segmento lunghissimo, forse avresti dovuto organizzare meglio il tuo software.

Il 1/3/2020 alle 01:11 , DavidePizz ha scritto:

la differenza è solo visiva all’inizio

Su questo non sono d'accordo o meglio, non sono d'accordo sul "solo": se sei sul campo, già con tanti casini, fretta, ecc. la differenza visiva non è una cosa da poco. Un contatto verde è più visibile di un numero "1" o di un "TRUE" (magari anche perché sei a due metri dal PC e devi premere un pulsante e sei solo 🙂 ).

Modificato: 2 marzo 2020 da Cesare Nicola

[Cesare Nicola]

Il 29/2/2020 alle 10:41 , pigroplc ha scritto:

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

😁

[ifachsoftware]

Il 21/2/2020 alle 11:03 , batta ha scritto:

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.
 

Secondo me hai ragione per l'esempio postato.

I problemi si pongono quando si iniziano ad utilizzare i puntatori ecc ... che oltre ad essere legati alla piattaforma (qundi o si lavora solo in AWL con quel micro e si sanno a menadito , altrimenti se si salta da una piattaforma all'altra sono sempre fonti di perdite di tempi e scarsa leggibilità).

Il discorso della leggibilità del codice secondo me dovrebbe essere sempre messo al primo posto.

Poi subentra il discorso delle prestazioni che non dovrebbe mai andare a discapito della leggibilità.

Per fortuna al giorno d'oggi avendo anche di serie (con mamma Siemens) tutti i linguaggi , ed avendo cpu sempre piu' potenti rendono nel 99% dei casi sorpassato l'AWL