LD vs ST debugging

[Giuseppe Maggio]

Salve a tutti, da un anno circa programmo per lavoro plc omron in linguaggio ladder, ho trovato tutti i programmi già scritti in questo linguaggio.
Conosco almeno in parte il linguaggio ST structured text e comunque non avrei problemi a programmare in questo linguaggio.

Nelle prossime settimane c'è la possibilità di programmare un nuovo tipo di plc, scrivere un programma da zero (in codesys) quindi sto proponendi di passare al ST, in modo particolare, capita di avere programmi in ladder molto ripetitivi, ad esempio un banale controllo livello con soglie di allarmi di N serbatoi.
In ST farei il tutto con un ciclo for e poche righe di codice, in ladder il tutto diventerebbe molto lungo e ripetitivo.

Il quesito che subito mi viene posto dai colleghi "ladderiani" e che in parte condivido è l'eventuale debug.
In ladder è possibile vedere cosa accade nel programma, nel caso in esempio, di ogni singolo serbatoio, che valore assumono le variabili etc..

In ST non riesco (riescono) ad immaginare la stessa cosa, soprattutto in presenza di un ciclo FOR, dovrei in soldoni, bloccare l'impianto, modificare il programma, bloccare l'indice del ciclo "for" sul serbatoio di interesse, procedere al debug e dopo rimettere tutto per come era in origine
Anche l'uso dei breakpoints (per quel poco che li conosco) non mi aiuterebbe molto.

C'è da dire (riflessione maturata durante la scrittura di questo messaggio) che in un programma scritto in ST, per questo tipo di impianto, forse non avrebbe senso focalizzarsi sul ciclo FOR per un problema che affligge un singolo serbatoio, ma sarebbe più utile analizzare le singole variabili/valori di quel serbatoio. Discorso diverso se il problema affliggesse tutti i serbatoi, in quel caso mi focalizzerei sul ciclo for.

Per programmi diversi, più complessi ? è solo questione di abitudine?


Pareri? Consigli?


Grazie
 

[leleviola]

Perchè in ladder il FOR ....NEXT non credi che ci sia? Io lo uso anche li normalmente dovrebbe esserci su ogni Plc che rispetti le norme di programmazione, non sono questi i motivi che portano a uare il Ladder o ST, io li uso entrambi e li combino a necessità, fondamentalmente ST lo uso per calcoli complessi Ladder lo uso per il controllo di processo, vero è che il ladder è di più immediato debug

[drn5]

è solo questione di abitudine. Il debug si può affrontare in modi diversi. 

Se sviluppi in Ladder, ma scrivi coi piedi, il debug diventa faticoso anche li.

Una volta per il basic si usava il termine "spaghetti code" perchè si vedevano porcate indicibili e i puristi del C davano contro a chi usava il basic.

Oggi molti che usano scl guardano d'allto in basso chi usa il ladder.

Si può scrivere del codice mischiando porzioni di codice in linguaggi diversi, lo si fa nel mondo PLC e non solo in quello.

L'importante è mettersi sempre in gioco per non restare indietro.

[Giuseppe Maggio]

1 ora fa, leleviola ha scritto:

Perchè in ladder il FOR ....NEXT non credi che ci sia? Io lo uso anche li normalmente dovrebbe esserci su ogni Plc che rispetti le norme di programmazione, non sono questi i motivi che portano a uare il Ladder o ST, io li uso entrambi e li combino a necessità, fondamentalmente ST lo uso per calcoli complessi Ladder lo uso per il controllo di processo, vero è che il ladder è di più immediato debug

personalmente la vedo come una forzatura il FOR nel ladder, mai (per quello che ho potuto vedere) visto usare; sicuramene in ST è più immediato.
Riguardo al debug grazie del parere.
Vedrò di combinare entrambi i linguaggi.

[Giuseppe Maggio]

40 minuti fa, Yiogo ha scritto:

io programmo plc da tanti anni, ovviamente in LD, occasionalmente in IL

poi avevo avuto il problema che il vendor che usavo aveva plc troppo "grandi" per cui ho dovuto affiancare un secondo vendor, questo mi ha fatto conoscere codesys

è stato un processo irreversibile, mi sono trovato subito bene con ST, forse perchè conoscendo bene nel passato il basic non ho avuto problemi

ora in LD scrivo pochissimo, potrei perfino farne totalmente a meno

ho riscritto in ST anche routine che avevo già funzionanti e testate in LD perchè sull'efficenza non c'è nemmeno il minimo paragone, sopratutto se strutturi veramente bene il programma e le funzioni chiamate

 

consiglio chi non è proprio giovanissimo di non perdere gran tempo in LD salvo particolari eccezion di PRG particolarmente solo logici

 

Grazie, anche io ho un "infarinatura" di basic e C e il ST mi sembra il modo più naturale di programmare un controllore, che sia esso un plc o un microcontrollore
Spero di trovarmi bene con Codesys.
Penso affiancherò parti in ST con parti in LD, almeno in una prima fase 
Grazie

[Giuseppe Maggio]

1 ora fa, drn5 ha scritto:

è solo questione di abitudine. Il debug si può affrontare in modi diversi. 

Se sviluppi in Ladder, ma scrivi coi piedi, il debug diventa faticoso anche li.

Una volta per il basic si usava il termine "spaghetti code" perchè si vedevano porcate indicibili e i puristi del C davano contro a chi usava il basic.

Oggi molti che usano scl guardano d'allto in basso chi usa il ladder.

Si può scrivere del codice mischiando porzioni di codice in linguaggi diversi, lo si fa nel mondo PLC e non solo in quello.

L'importante è mettersi sempre in gioco per non restare indietro.

L'importante è mettersi sempre in gioco per non restare indietro.
Si, un codice si può scrivere male o bene in qualsiasi linguaggio, vedrò di affiancare ST ad alcune parti in LD.
L'idea di programmare solo in LD la sento già stretta, più si sale di livello di "complessità", più il ladder diventa stretto e quasi una forzatura.
Nel mondo TwinCat, ad esempio andando nel campo della visione, il LD non è più considerato, si va principalmente di ST. 
Grazie
 

[Ctec]

Spesso viene chiesto dai clienti (grossi) che hanno manutenzione interna che almeno la struttura principale del programma sia in ladder, proprio perché è più intuitiva.

Ma nulla vieta di usare parti e FB scritte come ti pare, per esempio in ST. Anzi, dato che molti non lo capiscono, ti mette anche un po' al riparo da copiature e/o modifiche non desiderate.

Un sistema carino ed efficiente, se il sistema lo consente, è quello di integrare nel ladded delle parti in ST, anche all'interno dello stesso rung. Per esempio, operazioni matematiche che in ladder sarebbero lunghe e cervellotiche.

PS: occhio ai cicli FOR-NEXT: allungano il tempo di ciclo, e pertanto si rischia di avere comportamenti non sempre deterministici in alcune condizioni, a seconda se i cicli sono in numero diverso o addirittura non attivi.

[leleviola]

8 ore fa, Giuseppe Maggio ha scritto:

Grazie, anche io ho un "infarinatura" di basic e C e il ST mi sembra il modo più naturale di programmare un controllore, che sia esso un plc o un microcontrollore

ma senti un PLC sarà che vengo dal mondo elettrotecnico ma io il PLC lo vedo più come una logica combinatoria e quindi il linguaggio e l'uso che se ne fa è più legato per me al ladder, poi ovviamente c'è anche la parte sequenziale  della logica, come dice @Ctec e come ti avevo accennato per me lo strutturato è più utile nell'uso combinato con il Ladder perchè ti facilita la lettura del codice magari nell'ausilio di calcoli matematici complessi che in Ladder sarebbero di non facile lettura. Io non ho provato a convertire in ST logica che preferisco vedere in Ladder, non vedo attualmente dove stia la convenienza anche perchè ho molta dimestichezza manuale ormai nella scrittura in Ladder con la tastiera del PC e comunque la scrittura di una medesima logica sia in Ladder che in ST non vedo dove stia la convenienza a scriverla in ST dal punto di vista della velocità di scrittura e quindi di velocità di programmazione. La convenienza sta nella velocità di debug? Bah non credo, difficile essere più schematico e immediato di uno schema a Ladder. Quello dove trovo più utile una programmazione in ST è nella programmazione delle unità robotiche, li si che è una programmazione in ST molto potente dove la programmazione è fondamentalmente diversa e a passi singoli o dove la programmazione del robot può essere predittiva cioè l'interprete del robot può eseguire in anticipo istruzioni relative a un posizionamento

[Ctec]

21 minuti fa, Yiogo ha scritto:

al contrario se di copia uno stupido ti fa solo un favore perchè ti devono richiamare in ginocchio per ripparare i suoi danni

No, io non faccio solo software, ma costruisco macchine, e la filosofia è non essere chiamati, poiché siamo piccoli e l'assistenza è più un problema che una fonte di introito.

Ovviamente non volevo dire che gli altri sono ignoranti (i programmatori), ma i manutentori che vogliono fare modifiche da soli si, eccome. In 30 anni di carriera potrei farti una casistica completa.

Comunque, beato te che hai la possibilità di imporre la tua volontà. Io dipendo dalla parte commerciale/amministrativa dell'azienda, e spesso dobbiamo "piegarci" alle richieste dei clienti (grossi), non ci possiamo permettere di scegliere i lavori, al momento almeno...