Vivissimi ringraziamenti

[ETR]

Salve a tutti, con il titolo sarcastico, volevo cominciare una piccola discussione che ruota un po' attorno al solito discorso della proprietà intellettuale ed un po' all'aspetto della "riconoscenza". 

 

Sarò forse ancora un po' ingenuo o all'antica nel considerare che dopo 23 anni di lavoro mi si venga riconosciuto un discreto apporto nel portare una società (il cliente) da quadri con relè e regolatori Adamello Ero Electronic, a DCS B&R.

 

Dovendo chiarire alcuni aspetti non più tollerabili ormai, è cominciata una discussione interminabile via mail (per fortuna, dico io, almeno certe cose rimangono scritte). Deciso a togliermi anche qualche sassolino dalla scarpa, la conclusione di un lungo discorso che ovviamente tralascio, è stata : "non hai creato la logica di lavoro degli impianti xxx". Si consideri un lavoro eseguito SEMPRE senza specifica tecnica scritta, solo qualche vago accenno verbale, frasi incomplete, mezze verità mal celate. 

 

Il non "creare", ha sempre comportato però anche la gestione completa di tutta la frase progettuale dell'automazione con IMPOSIZIONE anche di scelte di funzionamento del processo, per evitare che la colpa di mancanze ormai note e mai metabolizzate dal cliente (classico copia e incolla), generassero problemi, anche quelli ormai noti.

 

Nello sviluppo della discussione ovviamente anche l'aspetto della proprietà intellettuale è stato toccato, ma non ottenendo nessun riscontro da alcune battute, ho preferito passare oltre, in attesa di nuove mirabolanti affermazioni.

 

Licenze di utilizzo, proprietà di librerie sviluppate ad hoc negli anni, la stessa impaginazione HMI, standardizzata e modulare ora qualcuno pensa che dovrebbero essere passate, senza colpo ferire per il solo fatto di aver pagato.

 

Non voglio aprire un dibattito su un aspetto che è stato dettagliato sin dagli albori dell'automazione, ma riscontare ancora oggi una "ignoranza" in merito, è qualcosa che mi lascia comunque stupito.

 

Ogni impianto ha la dichiarazione di licenza d'uso del ns software e non della proprietà e fornisco sempre solo il compilato entro la garanzia, per poi mettere a disposizione il sorgente che però ha solo il 20% del codice visibile in strutturato, dato che la logica è contenuta nelle librerie. Ovviamente qualora il contratto non preveda sin da subito la vendita completa del sorgente completamente aperto, cosa che allora ha un altro perso economico e solitamente è seguita da uno sviluppo non indifferente dell'applicazione.

 

Saluti a tutti, Ennio

 

[dott.cicala]

Che ti posso dire Ennio? Ben venuto!

 

Anche se sei del mestiere da 23 anni....

 

Hai descritto la situazione in cui la maggior parte di noi si trova abitualmente:

 

Salti mortali per portare a termine un progetto senza specifiche e senza idee.

 

Non ci si abitua mai.

 

Io cerco di fare del mio meglio per la mia soddisfazione...per il resto ho perso ogni speranza. 

 

Molte volte sarebbe meglio guardare in faccia il committente e pensare se si merita un lavoro ben fatto o un lavoro appena sufficiente a soddisfare la richiesta e

quindi dedicarsi con più impegno solo dove c'è il riconoscimento del merito....che può essere anche solo un grazie, una pacca sulla spalla o al limite un caffè.

[Nicola Carlotto]

Un professionista serio esegue  sempre al meglio il compito di cui si fa carico , la sua firma e' la sua professionalita'. Il resto deve essere sempre specificato

prima dell'iniziodei lavori... ma quante volte siamo costretti ad accettare dei lavori senza specifiche iniziali solo perche' dobbiamo mangiare a fine mese ?

Un mio vecchio cliente , andato in posti migliori, mi diceva che l'esperienza e' un sacco pieno di fregature ( in dialetto veneto inc..) , chi ha un sacco pieno

capisce al volo la situazione solo dopo 2 chiacchiere col cliente e si comporta di conseguenza .

Licenza d'uso del software, uso della siae ,  uso di un avvocato per iniziare una causa quando e' necessario.. , opzioni valevoli solo se non si e' in necessita'

di mangiare a fine mese , vedi sopra.

Comunque sia il nostro lavoro e' comunque uno tra i migliori ...

Ciao

Nicola

[Livio Orsini]

Quote

Licenze di utilizzo, proprietà di librerie sviluppate ad hoc negli anni, la stessa impaginazione HMI, standardizzata e modulare ora qualcuno pensa che dovrebbero essere passate, senza colpo ferire per il solo fatto di aver pagato.

 

E', effettivamente, un problema dibattuto da decenni.

 

La norma ed il buon senso dovrebbero supportare il principio che se un cliente paga per svilupare un progetto quel prgetto è suo, ma solo quel progetto.

Il problema reale è (quasi) mai un edificio prgettato da uno studio di ingenieria venga poi replicato dal costruttore in n esemplari, mentre è normale che una macchina venga progettata e costruita in numerosi esemplari.

 

un progetto meccanico consiste in un certo numero di disegni ed i realtivi calcoli di dimensionamento; il cliente paga, lo studio di progettazione consegna il risultato del progetto ed il cliente ne fa quello che vuole, salvo differenti accordi scritti e facenti parte integrale della commissione.

 

Con il software sin da subito, essendo un qualche cosa di immateriale, ci sono state delle diatribe tra produttore ed acquirente.

 

Le grandi società come MScontrattualmente non vendono il prodotto software ma solo la licenza d'uso su di una sola macchina.

Anche altre software hause hanno un simile approccio con i loro prodotti; esempio per la rpima licenza, valida per una macchina, paghi x, per le successive paghi y, con y << x, sino ad un certo numero, dopo di che il software è liberamente replicabile.

Questo lo puoi fare se puoi usare protezioni Hw e/o Sw che ne impediscano la duplicazione.

 

Nell'automazione industriale c'è stato sin dagli albori, specialmente in Italia, un peccato originale. Alcune aziende piuttosto stupidamente, non hanno fatturato il software come fornitura indipendente. Lo hanno incluso nelle spese generali di progettazione, oppure come ricarico sul costo Hw. Dato che il Sw "non si vede", se nemmeno lo si fattura esplicitamente i clienti poi si sono disabituati a considerarlo come voce nell'elenco materiali.

 

Da questo è nata la convenzione che:

1. Il Sw è gratuito.
2. Il Sw è replicabile ad libitum
3. Il Sw è comunque in garanzia per sempre
4. Eventuali modifiche al Sw, dovute a modifiche funzionali della macchina, devono essere comunque eseguite in forma gratuita.

 

Io ho sempre sostenuto, anche con i miei commerciali, che nella composizione della fornitura ci fosse una voce esplicita, con relativo costo, per il prodotto Sw. Inoltre nell'accettazione dell'ordine, salvo patti diversi ed esplicitamente dichiarati, la proprietà del Sw rimaneva del produttore ed il cliente godeva della sola licenza d'uso.

Anche qualora il cliente chiedeva ed otteneva di avere la proprietà esclusiva del Sw sviluppato per quella commessa, la proprietà era comunque limitata al solo Sw applicativo, mentre tutte le librerie di base rimanevano di proprietà esclusiva dello sviluppatore, salvo accordi differenti ed espliciti

 

Questo perchè sviluppare software è un lavoro intellettuale e la proprietà intellettuale si paga, come un editore che compra una fotografia paga cifre differenti se ha il diritto di pubblicarla su un solo libro-rivista-giornale o se acquista i diritti esclusivi di riproduzione.

 

Tutto questo bisgna discuterlo in sede di negoziazione e, soprattutto, metterlo per iscritto perchè, come si sa ma spesso si dementica, scripta manent et verba volant ( un mio collega aggiungeva: "...e strunz galegiant", ma questa è un'altra storia).

[luigi69]

Ciao  ETR, benvenuto , o meglio dire, mal comune e mezzo gaudio nel nostro mondo  ( 28 anni lavorativi, 22 in proprio )

 

Concordo con cicala e con Nicola, con la sola precisazione, non è il migliore, era....

 

Azzeccata anche la precisazione di Livio  :

 

Quote

1. Il Sw è gratuito.
2. Il Sw è replicabile ad libitum
3. Il Sw è comunque in garanzia per sempre
4. Eventuali modifiche al Sw, dovute a modifiche funzionali della macchina, devono essere comunque eseguite in forma gratuita.

 

se possibile aggiungo al vostro elenco le peggiori situazioni che si creano nella gestione di una commessa o di un intervento :

 

• mi prevede li un po di pid,,due analogiche....tanto lei sa.....  ( li dove ?   io so cosa )
• per il funzionamento , l'operatore...plic plic...preme  e poi gira il selettore su automatico e funziona !  ( chi lo spiega al cliente che i comandi manuali sono una cosa, il ciclo auto un'altra ?)
• Telefonata  :  li la cosa...non funziona...le donne....hanno toccato, ..non registro più il micro.......   a  è lei sig.  X , buon giorno  , mi dica il problema     Sopra, sopra, non funziona, la macchina che ha fatto lei , non ci sono più le mezze stagioni , si stava meglio quando si stava peggio , non ci sono più i giovani di una volta, i comunisti al governo.....  Ci sono problemi su qualche macchina al piano sopra del capannone ?  Si si...la macchina zz che mi ha fatto lei......Io di macchine al piano sopra ne ho fatte sette, quale non funziona ?

Quella vicino alla porta   ce ne sono 4 vicino alla porta    Li , li dove lavorano le donne.....  ce ne sono 2 dove lavorano le donne   quella li , quella li, non funziona       mi scusi sig. X, delle due che abbiano detto , quale non funziona ?   quella quella , si è rotto il PLC , si è rotto , lo dicevo io che con tutta questa elettronica, aaaaa quando le macchine erano solo meccaniche, si che funzionava meglio la roba.....  ( dopo intervento scopro che era effettivamente una regolazione meccanica del micro )

• non faccia tanto il prezioso con il suo PC portatile , è roba vecchia , oramai tutto smartphone  e i-pad, cosa crede, oramai in rete si trova di tutto , se voglio il suo software lo trovo e lo scarico quando voglio.........cosi mi costa meno....

 

Poi purtroppo adesso fa caldo , e se ci sono dei fondi o delle situazioni tristi , con il caldo si amplificano....

 

 

 

[leleviola]

non faccia tanto il prezioso con il suo PC portatile , è roba vecchia , oramai tutto smartphone  e i-pad, cosa crede, oramai in rete si trova di tutto , se voglio il suo software lo trovo e lo scarico quando voglio.........cosi mi costa meno....

 

Poi purtroppo adesso fa caldo , e se ci sono dei fondi o delle situazioni tristi , con il caldo si amplificano....

 

 

a queste dichiarazioni in cui non si riconosce la proprietà intellettuale della realizzazione del software da parte di chi lo realizza basta predisporre una "bomba", il software si blocca e non è più accessibile,le password sui software ci sono apposta. Se ne riattiva la funzionalità quando se ne riconosce da parte del cliente la proprietà intellettuale da parte di chi lo ha realizzato. A mali estremi estremi rimedi, non capita spesso ma quando se ne ha sentore della situazione è l'unico rimedio, nel mio caso ha sempre funzionato 

[pagliardo]

Una volta in un software sviluppato da un altro ho trovato un passaggio dove c'era un contatore che dopo un tot di pezzi dava un " allarme" ma non era vero. E bloccava la macchina. C'era una procedura per resettarlo che se non la leggevi dal software non avresti mai potuto farla.

Probabilmente era una specie di ripicca nell'eventualita che ci fossero stati dei problemi di pagamento.

Il fatto è che non si dovrebbe arrivare a questo, io sono sempre stato contrario persino alle pw. Ma ultimamente, dopo copie spudorate di macchinari e relativo software, dopo mancati pagamenti.....sto cambiando un po il modo di vedere i clienti. Finché va tutto bene, bene. Ma poi se ci sono problemi, se arriva uno che ti copia la macchina, per carità tutto legale nessun brevetto, allora il tuo lavoro non vale più. 

Bisogna tutelarsi prima. 

Anche aziende clienti da anni, possono trovare uno che ti copia un software e fa il lavoro al prezzo più basso del tuo.

[STEU]

Comunque bloccare le macchine con trucchi software è illegale in Europa, potresti prendere una denuncia per aver bloccato la produzione.

In america invece  puoi bloccare le macchine a causa dei mancati pagamenti, tanto è vero i CNC della Mitsubishi, ma penso anche altri CNC, hanno un'opzione che blocca il controllo numerico se non introduci delle password , queste password chiaramente devono essere date dal costruttore della macchina se il cliente ha pagato tutte le rate.

[leleviola]

Hai detto bene nell'ultima affermazione:

"se il cliente ha pagato tutte le rate"

solo per quello ed è solo per quello che si arriva a tutto ciò,

non certo per bloccare la produzione,

la stessa Mitsubishi prevede la password per bloccare la connessione ai propri PLC se si vuole esercitare i propri diritti di proprietà intellettuale e non ne vedo motivo per non poterlo fare finchè la proprietà dei diritti non è stata completamente renumerata

[Livio Orsini]

Ci sono dei mezzi un poco più sofisticati come rallentare la produzione senza bloccarla.

 

Poi ci sono dei metodi anti duplicazione. Non garantiscono l'inviolabilità assoluta, ma proteggono dalle copiature eseguite dai "tirafili" che sono le più freqeunti e dannose.

Se il committente fa copiare la macchina da un'azienda che ha le capacità di superare certi blocchi c'è poco da fare, però il committente non risparma niente o quasi.

Se il committente fa copiare la macchina da quadristi tirafili risparmia molto, ma poi la macchina non riescono a farla funzionare, ed è questo lo scopo delle protezioni anticopia.

[dott.cicala]

Scorrettezza per scorrettezza, blocchiamo le macchine.

Così se il cliente e piccolo e/o sprovveduto magari ci paga o a maggior ragione non lo farà e chiamerà altri.

Se invece il cliente non è poi così sprovveduto, chiamerà altri, i quali prima o poi riusciranno a dimostrare che il blocco è doloso e ci troveremo in tribunale ad affrontare una lunga causa penale con buona probabilità di perderla, non incassare il dovuto, dover risarcire il cliente per i danni provocati dal blocco, oltre a doversi far carico di tutte le spese legali....e non finisce qui. La causa lascerà un indelebile marchio sulla vostra reputazione.

Geniale 

[pagliardo]

Infatti bloccare una macchina con questi stratagemmi secondo me non risolve niente. Anzi, peggiora le cose. È solo una ripicca fine a se stessa. Tanto se arrivi al punto di usare questi metodi il cliente lo hai già perso, e anche gli eventuali crediti.

[Livio Orsini]

Quote

Scorrettezza per scorrettezza, blocchiamo le macchine.

 

Non c'è bisogno di bloccare le macchine.

Ci sono mezzi un po' più sofisticati che obbligano il cliente a richiedere l'assistenza.

 

Poi non bisogna confondere i sistemi anticopia, perfettamente legali, con il brutale blocco della macchina.

[batta]

Per fortuna, le protezioni attuali sono decisamente migliorate.
In casa Siemens, per esempio, già nel "vecchio" Step7 5.x c'è la possibilità di installare dal DVD il programma "S7 Block Privacy", che non è il banale "Know How Protect".

S7 Block Privacy permette di proteggere FC ed FB criptando i blocchi. La chiave credo sia a 256 bit. La password, per essere accettata, deve essere di almeno 12 caratteri.

Nel TIA è già prevista la protezione mediante criptazione.

Non so cosa facciano gli altri, ma penso abbiano adottato misure simili.

 

Proteggere il software in modo "sicuro" quindi ora è possibile.

[ETR]

Ciao a tutti e grazie delle svariate risposte.

 

Sono appena rientrato dalla Turchia ed ho avuto qualche problema con il sito mentre ero la e ho tirato il fiato anche qualche giorno, per cui rispondo solo ora.

 

Riallacciandomi brevemente alle mie vicissitudini personali, posso solo aggiungere che purtroppo il peggior interlocutore è colui che non vuole ascoltare, per cui, non aggiungo altre nuove chicche del cliente che continua impunemente a inanellare altre affermazioni che, colpa mia, ogni tanto ho ancora ribattuto, ma che avrei dovuto lasciar perdere da almeno una paio di settimane.

 

Per tutto il resto, non ho mai sinceramente adottato una politica di protezione con password, convinto anche da altri colleghi, che comunque la conoscenza del processo e la corretta applicazione del codice erano più importanti del codice in se stesso. Inoltre le conseguenze legislative di eventuali blocchi, mi ha sempre distolto a priori.

 

Nello specifico settore del processo nel quale si sviluppa la mia vicenda, parliamo di una logica abbastanza blanda, che necessità più della conoscenza dell'applicazione dei blocchi e delle librerie che della loro scrittura corretta. Passato ormai da anni alla strutturato, vorrei completare il passaggio definitivo al C di tutto il codice ,anche solo per dare del filo da torcere ai copioni di ladder oppure ai clienti (il mio in primis), convinti che la "stampa del programma" (cito le testuali parole), permetta a chiunque la padronanza del funzionamento del sistema.

 

Per quanto riguarda lo sblocco delle protezioni, non nego, che comunque una discreta conoscenza sia necessaria, anche solo per conoscere metodi alternativi a quelli ufficiali, che comunque entro un certo tempo, verranno bucati. Seguendo gli omonimi siti del ns, russo o rumeno, si può tranquillamente leggere di come si prodighino all'estero i consigli per rendere qualsiasi cosa "free" , dai software proprietari alle protezioni e che quindi si ritorni al discorso di Livio, su metodi differenti e più complessi o astuti per proteggersi.

 

Vedremo il proseguo, dato che gli ultimi seguaci del "copia e incolla, tanto è uguale", penso che andranno in pensione e quindi ci saranno sempre più nativi digitali con cui interfacciarsi all'interno delle aziende, anche se magari sanno i figli "dei copia e incolla" e quindi pur conoscendo l'argomento, pretenderanno e non riconosceranno.

 

Ciao a tutti, Ennio

[Livio Orsini]

A margine di questa discussione voglio segnalare questo corso, che si terrà a Milano il 20 Settembre, dal titolo: " Le Norme e i "Diritti del Software ". Il costo non è proprio banale: 450.00€, però forse per un'azienda potrebbe valerne la pena.

[barby]

Quote

 Passato ormai da anni alla strutturato, vorrei completare il passaggio definitivo al C di tutto il codice

 

ciao ETR,

solo una curiosità: che PLC usi che ti permette di programmare in C?

[ETR]

Ciao Barby, pur mantenendo codici Mitsubishi e Siemens attivi (per vari clienti), da anni lavoro su B&R.

 

Ciao, Ennio

[ETR]

Grazie Livio, interessantissimo ! L'unico problema è che è a ridosso da un rientro da una trasferta e come al solito potrei sforare. Comunque ne tengo nota, anzi mi permetto di ri pubblicarlo e quasi quasi lo invio anche la mio cliente. Non si sa mai che sulla via per Damasco, venga folgorato ... ma purtroppo è successo solo ad una persona !

 

Ciao, Ennio

[Livio Orsini]

Le uniche folgorazioni a cui credo son quelle degli imbecilli che si asciugano i capelli immersi nella vasca da bagno piena di acqua e schiuma.

 

B&R è una bella macchina, non sembra quasi nemmeno opera di crucchi. E' forse l'unica, tra i costruttori medio-grandi, a prevedere la programmazione in "C".

Purtroppo si cerca di fidelizzare i cliente non usando un linguaggio standard come il "C".

Io ho cominciato questa battaglia nello scorso secolo, nelle varie riunioni di comitati, forum, seminari, giornate di studio e chi più be ha più ne metta.

Ma ogni grosso produttore ha sviluppato il suo linguaggio strutturato in modo da bloccare le migrazioni da un PLC ad un altro.

 

IN USA circa 25 anni fa, l'associazione autometion.com aveva lanciato un progetto open source di un plc; le specifiche prevedevano tra l'altro anche il "C" come linguaggio di programmazione. Sollevò molto entusiasmo tra gli iscritti, si arrivò a produrre dei beta, ma poi morì per l'opposizione dei clienti, che proprio non ne vogliona sapere di dispositivi che non siano prodotti da grossi nomi, anche se sono prodotti vomitevoli.

 

Bisognerebbe riuscire ad essere sponsorizzati da un grosso acquirente, come succcesse con GM quando commissionò i primi PLC a Modicon.

[lucios]

Quote

Io ho cominciato questa battaglia nello scorso secolo

Si mi ricordo eravate tu, Marconi e Turing

Scusa Livio, sarà la calura estiva ma non ho resistito...

Mi sono permesso anche grazie alla stima che nutro nei tuoi confronti e al fatto che sono, in merito all'argomento, perfettamente d'accordo con te.

[ETR]

Ogni tanto ho letto qualche "batti becco" tra lusios e livio, ma essere in compagnia di Marconi e Turing, non è male, anzi ! Mancherebbe solamente Tesla al gruppetto !

 

Comunque, la scelta di B&R nasce da una sorta di tentativo di sollevarsi dalla mischia teutonica, che c'è da me ed in provincia, non tanto perché mi consideri "migliore", anzi, ce ne sono tantissimi a cui dovrei levare il cappello, giovani e meno giovani, ma l'idea di uniformarmi ad un unico e solo stile di lavoro e programmazione, senza apparente scelta, mi è sempre stata "stretta".

 

Ultimamente ho anche "sbirciato" Beckhoff, ma palesando la mia ignoranza, ho scoperto che tutto l'ambiente gira attorno a Windows e tutto l'appeal è finito in 2 secondi (anche perché l'aggiornamento della macchina virtuale per installare visual 2015 ha voluto qualcosa come 6 ore).

 

Per non farci mancare nulla, quindi il prossimo passo sarà C e poi vedremo se Phyton o altro, giusto per provare anche nuove piattaforme open. La disponibilità di codice open, comunque, penso  che imporrà qualche apertura alle case costruttrici col proseguo degli anni.

 

Giusto per fare un esempio si pensi alle librerie Libnodave per comunicare verso Siemens (ma ce ne sono anche per altre funzioni) oppure lo stesso Modbus TCP. Che senso ha pagare librerie ad hoc oppure ancora peggio, secondo me, hardware appositamente "segato" o dedicato, per dialogare con tutto il resto del mondo ?

 

La risposta è ovvia, monopolio, ma è tutta un altra questione che è stata dibattuta mille volte.

 

Comunque ripensandoci, livio, hai ragione, già altre volte il mio cliente si è beccato il 5 kV (quello per intenderci dell'innesco a 10 mA, innocuo, ma comunque capace di lasciare un indelebile ricordo) e non ha sortito effetti, per cui evito di perdere ulteriore tempo.

 

Ciao, Ennio

 

 

[amed]

Io parlo da persona che non ha voce in capitolo. Voglio però dire che penso che il ladder non sará mai sostituito da altri linguaggi di programmazione perchè permette agli addetti alla manutenzione di capire facilmente l'origine dei problemi. Il cliente finale tiene giustamente molto in considerazione le esigenze degli addetti alla manutenzione. Ciao a tutti. Siete sempre molto interessanti.

[lucios]

Quote

Voglio però dire che penso che il ladder non sará mai sostituito da altri linguaggi di programmazione perchè permette agli addetti alla manutenzione di capire facilmente l'origine dei problemi

Argomento anche questo gia dibattuto.

Io dico "dipende".

Se il progetto è semplice e non si va molto oltre la gestione di I/O posso essere d'accordo, ma se occorre inserire sequenze complesse, magari con trattamento di dati, anche il ladder diventa complesso da seguire (quando non impossibile da fare in ladder), il manutentore va nelle canne.

Ora, io non voglio parlare male dei manutentori ma i motivi di ciò sono:

- Il progettista ragiona con la sua testa (e a volte i ragionamenti sono mooolto contorti...).

- A volte il progettista per cavarsela utilizza trucchi o fa pezzi di PLC in linguaggi diversi (tipo con Siemens pezzi scritti in AWL o in SCL).

- Il manutentore, per quanto capace possa essere, non può entrare nella testa del progettista (io dico per fortuna perchè normalmente ha altro a cui pensare...).

 

Il risultato è che si chiama l'assistenza.

Quindi, come dice anche Livio, avere il tutto ben strutturato in un progetto in un linguaggio tipo C, magari supportato da strumenti di debug evoluti e da una diagnostica adeguata, forse alla fine sarebbe meglio per tutti.

 

Ciao

[Livio Orsini]

Quote

Si mi ricordo eravate tu, Marconi e Turing ...

 

Dire "lo scorso secolo" suscita idee di epoche remote, ma l'anno 1999 era ancora lo socrso secolo. E son passati solo 17 anni!

 

Quote

penso che il ladder non sará mai sostituito da altri linguaggi

 

Per prima cosa si potrebbe programmare in "C" e lasciare che èarallelamente ci siano altri linguaggi "nativi".

Io programmo in "C" alcuni micro di schede dedicate e, a volte, trovo la necessità per motivi di ottimizzazione delle prestazioni, di scrivere piccole parti in assembler. Le parti scritte in "C" sono "portabili" quasi senza modifiche su qualsiasi altro micro, purchè abbia un compilatore "C"; i piccoli sottoprogrammi in assembler rimangono dedicati a quel micro. Niente vieterebbe che fosse così anche per i PLC.

 

Secondariamente se i costruttori adeguassero i loro "ladder" allo standard IEEC e i comitati IEEC aggiornassero gli standard, il linguaggio ladder sarebbe indipendente dalla CPU e dalla marca.

Purtroppo tutti i grandi produttori dichiarano che il loro "ladder" risponde allo standard IEC poi, con una nota a piè di pagina scritta in caratteri microscopici come quelli usati dalle assicurazioni e dallle banche per le clausole vessatorie, ti precisano che si è conforme allo standard, però ne devi usare solo un sottoinsieme; ovviamente se programmi usando il solo sottoinsieme standard perdi metà delle potenzialità del linguaggio, quindi nessuno è così masochista da impiegare 3 volte il tempo necessario ed usa il set di istruzioni non IEEC.