Puntatori E Variabili Locali

[mubeta]

un bel compilatore C per tutti

Portiamoci avanti. Diciamo, almeno C++.

[batta]

Sarebbe bello essere esperti di tutto, ma nel mondo reale bisogna sapersi arrangiare biggrin.gif

Per questo motivo da alcuni anni ho deciso di non dedicarmi più a marche varie.

Preferisco conoscere bene un prodotto, e quindi saperlo sfruttare al meglio, piuttosto che conoscere così così 5 prodotti diversi.

E dato che il tempo di apprendimento costa (così mi dicono), torniamo alla grande a quello che diceva Livio: un bel compilatore C per tutti thumb_yello.gif

A me starebbe bene. Fondamentale però che i vari obj si possano caricare al volo, senza interruzioni del ciclo.

E fondamentale anche che il sistema sia disposto ad accettare errori di programmazione.

Se con un plc digito per errore l'indirizzo di una variabile non esistente, mi viene segnalato l'errore ma posso scegliere se mandare in stop la cpu o continuare ugualmente.

Il C generalmente non digerisce bene gli errori. E non tutti possono essere rilevati in fase di compilazione.

Si deve poi considerare anche che, mentre con Siemens è semplicissimo creare funzioni con 20-30 parametri (che senza sforzo alcuno si dichiarano come parametri IN, OUT, IN/OUT), gestire in C una funzione con numero elevato di parametri non è così immediato e semplice. Anche la rappresentazione stessa non è altrettanto chiara.

Inoltre, anche se tutti i costruttori si adeguassero ad utilizzare lo stesso linguaggio (e il linguaggio strutturato è già un linguaggio standard, uguale per tutti), si devono sempre fare i conti con hardware diversi.

Prendere il programma di una marca e portarlo pari pari su un dispositivo di marca diversa sarebbe bello ma è un po' utopistico.

Ci sarà sempre bisogno di metterci un po' le mani.

Per dire, anche se programmo in strutturato, le variabili in Siemens sono organizzate in DB. Una variabile si chiama "NomeDB".NomeVariabile.

Se cambi plc, anche se mantieni lo stesso linguaggio, la sintassi per le variabili non può rimanere uguale.

Anche il modo di fare diagnostica è troppo diverso e non basta uniformare il linguaggio per renderlo compatibile.

Pensare che tutti i costruttori si possano mettere d'accordo per buttare nel cesso tutto il loro know how e costruire una macchina che macini lo stesso software, non è solo utopia ma rasenta la follia.

E' come se si dicesse ad italiani, francesi, tedeschi, inglesi, spagnoli, portoghesi, russi, romeni... che da domani devono dimenticarsi l'italiano, il francese, il tedesco, l'inglese, lo spagnolo, il portoghese, il russo, il rumeno... e tutti dovranno parlare un'unica lingua.

[batta]

Non dubito nemmeno io che chi sia esperto di AWL impieghi un tempo accettabile, ma credo che sia fuori dubbio che lo sforzo di scrivere in codice macchina piuttosto che in codice ad alto livello o addirittura tirare righe col mouse tra un blocchetto ed un altro sia più impegnativo e con maggiore possibilità di errore..

A mio avviso non è sempre così. Non si tratta di impiegare "un tempo accettabile", ma di impiegare "meno tempo".

Facciamo l'esempio classico di AWL e KOP.

A prima vista si dovrebbe impiegare meno tempo a buttare giù un segmento (anche con semplici istruzioni booleane) in KOP, piuttosto che in AWL.

Ebbene, non è così.

Io quasi sempre scrivo in AWL (magari mettendo le parentesi per la corretta conversione in KOP, più comodo per il debug) proprio perché così facendo risparmio tempo.

Per carità, in parte dipende anche dal fatto che l'editor del KOP di Siemens non è il massimo.

Da questo punto di vista, i Panasonic sono veramente un altro mondo.

Rimane però il fatto che, se si sa cosa scrivere, la semplice scrittura è più rapida di un continuo lavorio col mouse per andare a scegliere e collegare tra loro oggetti vari.

Sul fatto poi di usare blocchetti preconfezionati, ci sono i pro e i contro.

Può essere che sia più rapido unire vari blocchetti con un po' di righe tirate con il mouse.

Questo almeno fino a quando il blocchetto preconfezionato risponde alle esigenze del momento.

Quando a quel blocchetto si vorrebbe far fare qualcosa di appena diverso, sorgono i problemi.

E giù a fare giri incredibili per risolvere alla meno peggio.

Si deve poi considerare che, tanto per tornare all'esempio di gestione di una valvola, una volta costruita una funzione la si può riutilizzare.

Non mi metto mica a riscrivere tutto il codice ogni volta!!!

Mi sono costruito le mie funzioni, e le riutilizzo ogni volta che mi fa comodo.

Diventa come utilizzare il "blocchetto", ma col vantaggio che sono comunque funzioni aperte, quindi, se mi trovo a dover gestire per esigenze particolari una valvola in modo leggermente diverso, parto dalla mia funzione archiviata in libreria e apporto le poche modifiche necessarie.

[Livio Orsini]

Portiamoci avanti. Diciamo, almeno C++.

E perchè? Il "C" standard è più che sufficiente

l C generalmente non digerisce bene gli errori.

No, semmai è il programmatore che non domina bene le tecniche di debugging.

Pensare che tutti i costruttori si possano mettere d'accordo per buttare nel cesso tutto il loro know how ...

Non è necessario. I processori usati hanno già compilatori commerciali; necessitano solo di piccoli lavori di integrazione con il sistema.

Più di 20 anni addietro, quando alvoravo nell'azienda che distribuiva KM in Italia, ho fatto personalmente questa esperianza sul PLC piccolo (PS3) che era basato sullo 8051. Oltre alla normale programamzione in ladder e AWL era possibile scrivere blocchi in asm51, questo per applicazioni limite (in velocità).

Questo tipo di approccio, volendo, può essere fatto su tutti i PLC senza grandi impegni di risorse. L'unico ostacolo è la volontà.

Comunque è solo questione di tempo. Quello che non voglio fare spontaneamente i costruttori saranno costretti a farlo dallo sviluppo tecnologico.

[mubeta]

E perchè? Il "C" standard è più che sufficiente

Dipende, ti condivido per la logica; ma ormai anche l'automazione industriale è "Visuale", comunicazione. E perché non anche oggetti copia-incolla, ecc.

C++ perché si programma ad oggetti; C++ perché se l'informatica è migrata ad esso da ... (da quanto tempo ?), ce n'era la necessità e, senza voler andare a dilungarmi oltre, l'automazione non è da meno.

Mettiamola così: se oggi immagini il PLC e poi lo HMI, piuttosto che uno SCADA, come oggetti distinti e separati, forse, puoi immaginare il C come linguaggio sufficiente per il PLC.

Ma un simile passo, non necessariamente deve essere il proseguo dello stato attuale, l'automazione potrebbe divenire una piattaforma completamente integrata, ed ecco che CODESYS, che già esiste, dimostra questo fatto: programmazione ad oggetti. (Anche se non mi risulta, esita la possibilità dell'overload, offerto invece da C++, e grandissima invenzione, ad esempio).

Comunque, concedetemi ancora una ultima disertazione: va bene quasi tutto, purché si abbandoni il concetto dell'istanza. Possibile che i programmatori non sappiano gestire la memoria in modo opportuno? E' un pensiaro che mi ha sempre umiliato, depresso. (Ecco che qui allora il C torna a far ragionare le teste).

[walterword]

bravissima , concordo .

Oppure che tutti si adeguino al codesys .

Prendo il sw che gira su pinco e lo faccio girare su palla .

Brava flavia

ciao

walter

[Livio Orsini]

C++ perché si programma ad oggetti;

E' proprio questo che, a mio giudizio, ne sconsiglia l'uso per risolvere problemi di automazione. Per quanto ottimizzato il risultato finale sarà sempre costretto a compiere giri di pista inutili. Le problematiche dell'interfaccia uomo-macchina, ed i relativi tempi di risposta, son ben differenti da quelli strettamente legati all'automazione.

..purché si abbandoni il concetto dell'istanza....

Anch'io trovo questa metodologia quanto di più assurdo ed innaturale si possa fare nel campo della programmazione

[walterword]

nel caso in cui il C sia un linguaggio di programmazione per risolvere compiti di automazione e' chiaro che utilizzera delle librerie con definiti gli I/O in maniera vicina alla macchina o che dir si voglia l'hw.

Per questo scopo bastarebbe un bel configuratore hw che compila i file header con all'interno le variabili del campo.

Per quanto riguarda poi i merker o i db possono essere sostituiti tranquillamente con strutture dati , dati definiti dall'utente e quant'altro .

Per i timer bisognera svere a disposizione librerie sw , cosa abbastanza dispendiosa .

Comunque credo che la piattaforma hw non sia piu un comune microntrollore ma un bel fpga .

Con fpga altera avevo scritto l'hw di timer ed altre periferiche hw , integrate poi nel sistema con un microcontrollore a 32 bit , 50 Mhz di clock .

Dop aver scritto i device driver , tramite delle define accedevo ai timer hw ed altro .

Le logiche in C/C++ eclipse based e volendo su micro OS/2 real time OS oppure microKernel linux .

Ma credo che ormai i plc seri siano gia equipaggiati con tale tecnologie .

Di conseguenza vengono scritti dei cad -grafici per permetterne la programmazione a livello "elettrico" con ladder ect .

Ormai un sistema di automazione , quindi non solo basato plc , deve essere programmato in qualsiasi linguaggio .

Per i dcs la cosa e' diversa , anche se alcuni dichiaravano sistema dcs un sistema composto da 3 plc S7-400 con 5 HMI ABB + ponte radioattivo per la carta , il tutto programmato in CFC , odioso linguaggio a blocchetti con fili che collegano vari blocchetti che viene il mal di occhi dopo solo 10 minuti che lo si guarda .

Creare un sistema plc-pc based non e' poi cosi complicato .

Al posto di inserire un editor grafico si possono inserire degli script embedded in python e modificare runtime il tutto senza fermare nulla .

Io sto basando su questo oltre a quello che gia esiste comercialmente .

Secondo me , tra qualche anno , se non si avranno delle capacità o delle visioni informatiche saremo tutti quanti tagliati fuori o comunque sottoposti ad apprendere in maniera forzata ed innaturale le nuove tecnologie .

Quindi non aspetto che sia siemens o altri a propormi il futuro, che ormai e' gia presente .

Ciao

walter

p.s arrivera anche giorno che saranno finiti i soldi per davvero , ed il cliente finale se vorra lavorare dovra accettare la schedina pizza micro con a bordo un PCF877 con amplificatori operazionali e resistenze

E non siamo lontani , gli odierni sistemi attuali commerciali sono destinati a fallire entro breve termine