Vai al contenuto
PLC Forum


Considerazione "personale" su costo ambienti di sviluppo


Marco Mondin

Messaggi consigliati

   Premetto che la mia è una considerazione del tutto personale.
I produttori di PLC di dividono in due gruppi, quelli che fanno pagare l'ambiente di sviluppo e quelli che non lo fanno pagare.
Premesso che il volume di fatturato delle licenze non è certamente comparabile con il volume di fatturato legato alla vendita di hardware, e che ovviamente per sviluppare un ambiente di sviluppo ben fatto ci sono decine di migliaia di ore uomo, il mio discorso non implica il regalarlo.

Tuttavia suppongo che chi non lo fa pagare, ridistribuisca i costi delle licenze sul suo hardware, e visto che in molti brand l'ambiente è legato all'hardware non mi sembra una brutta cosa.

In questa filosofia secondo me i pro possono essere:
- Più ricambio di sviluppatori, che se da un lato portano a più concorrenza, dall'altro portano a più scelta.

- Più possibilità di aggredire il mercato, e questo andrebbe a favore di alcuni big che perdono mercato più che per il costo dell'hardware per quello delle licenze.

- Una mostruosa semplificazione della vita per le tele assistenze con notevole vantaggio per tutti.
- Per gli intermediari come noi sarebbe molto più facile far digerire i costi ai committenti, che purtroppo nel rapporto costo hardware/software sono sempre sbilanciarti a comprendere un sovra prezzo hardware piuttosto che software. Tuttavia se vogliamo portarci a casa la pagnotta i costi si rigirano in buona parte sui committenti.

- Un sacco di persone che non usano i loro prodotti potrebbero usarli e se loro sono convinti di avere davvero un buon prodotto sarebbe solo un vantaggio.

Alla fine per fare un esempio di un big, credo che se SIEMENS spalmasse su hardware il costo delle licenze TIA, probabilmente farebbe aumentare i suoi prodotti di un 2-3% massimo.
Da una politica come questa ne trarrebbe vantaggio anche lei. Per esempio si risolverebbe in un colpo il problema pirateria! Le licenze spalmate su hardware non sarebbero scindibili.

Faccio questa considerazione partendo da un esempio di una realtà che sta crescendo a dismisura ed ha scelto tale strada.
Si tratta di Beckhoff, la quale ha smesso di far pagare l'ambiente di sviluppo Twincat Engineering, il quale può essere installato su quanti PC si vuole senza costi, mentre si paga il runtiume (Ed è corretto).
Un tempo lo facevano pagare e, nonostante stiano crescendo a doppia cifra ogni anno, hanno smesso. Per altro appena uscito funzionava solo in abbinamento a Visual Studio non Community, quindi ci voleva almeno la licenza VS di Microsoft, oggi invece basta Visual Studio shell, che è un tool gratuito Microsoft.

Tutte queste considerazioni, nascono da riflessioni sui discorsi delle licenze usate di questi giorni.
 

Link al commento
Condividi su altri siti


C'è anche un'altra fascia, quella di licenze si a pagamento, ma a costo ragionevole e aggiornamenti gratuiti (in questo campo ricadono ad esempio Omron e Mitsubishi).

In pratica, hai la licenza, e la paghi una tantum, poi finché il software (suite complete e non solo per PLC) è vivo viene sempre aggiornato in automatico e compreso nel prezzo. La licenza viene vista come una specie di registrazione che ti attiva l'aggiornamento automatico. E anche il supporto è compreso.

Le tue considerazioni sono giustissime.

Link al commento
Condividi su altri siti

Purtroppo siemes ha sempreabusato della sua posizione dominante.

C'è un'autorità europea per la libera concorrenza e non si capisce perchè non intervenga, anzi no lo si capisce binissimo!

Link al commento
Condividi su altri siti

Premetto che sono d'accordo con voi, ma la posizione dominante di siemens la fatta il mercato, e il fatto di essere dominante nel mercato fa si che si può permettere di fa pagare le licenze di più perchè chi le acquista ha un mercato più vasto dove inserirsi.

Sulla pirateria, secondo me è accettata, e la parte di licenze che non venderebbero mai ai piccoli che iniziano e nei paesi dove le licenze non le comprano proprio, ma con quella si garantiscono il mercato dell'hardware.

Link al commento
Condividi su altri siti

Come si fa a non essere daccordo, diciamo che in un regime di libera concorrenza chi ha una posizione dominante potrebbe permettersi pure il lusso di non far pagare le licenze e invece... forse se non facessero pagare le licenze sarebbe ancora peggio, chissa, comunque con tutto quello che fanno pagare di licenze l'ambiente potrebbe essere migliore ma si sa chi insegue cerca di fare sempre meglio, basta saper scegliere

Link al commento
Condividi su altri siti

Anche altri costruttori di hardware tipo Rockwell Automation facevano pagare le licenze, non sono aggiornato ad oggi ma una volta era così. 
A mio avviso il costo della manutenzione della postazione di lavoro in confronto al fatturato è abbastanza modesto, come un elettricista rinnova i cacciaviti spuntati o cambia il tester anche chi sviluppa software mette in conto questi costi di struttura, che sono di gran lunga inferiori al commercialista, balzelli vari ecc.

La posizione di forza di Siemens è dovuta ad una lungimirante politica espansiva a partire dagli anni 80, ad oggi interi settori produttivi (quello del bianco per esempio) sono legati a doppio filo a Siemens, quindi se devi fornire a specifica, poco importa se devi pure pagare la licenza, NON hai scelta!

2 ore fa, Marco Mondin ha scritto:

probabilmente farebbe aumentare i suoi prodotti di un 2-3% massimo

Già sono più cari.... Tenendo conto che gli sconti che applicano sono parecchio differenti se sei un utente finale, un OEM oppure un fornitore di OEM, se ti approvvigioni direttamente o tramite rivenditore. 

 

27 minuti fa, acquaman ha scritto:

Sulla pirateria, secondo me è accettata, e la parte di licenze che non venderebbero mai ai piccoli che iniziano e nei paesi dove le licenze non le comprano proprio

Ci sono interi stabilimenti in giro per il mondo dove una licenza non esiste proprio, e se interviene un "solution provider" se ne guarda bene di rifiutarsi di intervenire se non vede le licenze, e quando consegno la documentazione pretendendo una firma sulla bolla di accompagnamento mi ridono in faccia.

 


 

 

Link al commento
Condividi su altri siti

31 minuti fa, acquaman ha scritto:

la posizione dominante di siemens la fatta il mercato

Mica del tutto vero. Il mercato è stato fortemente falsato dalle imposizioni di capitolato di alcuni grossi clienti (uno per tutti FIAT in Italia e la completa chiusura all'estero in Germania) di parecchi anni fa che hanno imposto a costruttori di macchine la "scelta" obbligata. Il mercato non è stato affatto libero, ma fortemente influenzato. E vorrei vedere bene le clausole che hanno determinato tale imposizione.

Il mercato (chiamiamolo così) ora risente di tali (sconsiderate) decisioni che non hanno fatto vincere il migliore, ma solo il più potente.

Link al commento
Condividi su altri siti

47 minuti fa, Ctec ha scritto:

Il mercato (chiamiamolo così) ora risente di tali (sconsiderate) decisioni che non hanno fatto vincere il migliore, ma solo il più potente.

quoto e come spesso accade

Link al commento
Condividi su altri siti

Grossi gruppi è normale che standardizzano i fornitori, una fiat non potrebbe avere 100 marche diverse in uno stabilimento, ed ovviamente scelgono partener grandi in grado di supportarli.

 

Link al commento
Condividi su altri siti

24 minuti fa, acquaman ha scritto:

Grossi gruppi è normale che standardizzano i fornitori, una fiat non potrebbe avere 100 marche diverse in uno stabilimento, ed ovviamente scelgono partener grandi in grado di supportarli.

 

Vero quello che dici per quello che può essere una grande azienda perchè conosco anche aziende dove ci sono state imposizioni al contrario ma le imposizioni politche generali invece sono quelle che in passato non hanno aiutato

Link al commento
Condividi su altri siti

1 ora fa, acquaman ha scritto:

Grossi gruppi è normale che standardizzano i fornitori, una fiat non potrebbe avere 100 marche diverse in uno stabilimento, ed ovviamente scelgono partener grandi in grado di supportarli.

 

Devo dire che dal mio punto di vista soggettivo, ho visto un po' di tutto.

Parlando di grosse aziende produttrici di macchine seriali (Settore in cui lavoriamo di più):
- Realtà multinazionali che si vincolano ai big giustificandosi con i motivi che hai giustamente esposto.
- Realtà multinazionali che usano prodotti di piccolissimi produttori, a volte addirittura embedded, avendo da loro una assistenza che sovente i big non possono permettersi.

Parlando di piccole aziende produttrici di macchine (Settore al secondo posto nei nostri lavori):

- Realtà piccole che usano prodotti dei big, sovente nell'illusione di avere un prodotto qualitativamente migliore.
- Realtà piccole che usano prodotti di piccoli produttori, ottenendo un minimo più di considerazione per l'assistenza rispetto a quella ottenuta dai big, ma assumendosi rischi maggiori, in quanto il mercato dei piccoli è una giungla e discernere tra prodotti qualitativamente validi e rottami tenuti assieme con il nastro adesivo è difficile.

Ci sono pro e contro in entrambe le filosofie e sinceramente non saprei quale sia la migliore.

Da un lato i piccoli produttori sono un rischio, tuttavia a livello di ambiente di sviluppo negli ultimi anni stanno convergendo un po' tutti su CODESYS (tant'è che come diffusione a livello mondiale solo legata all'ambiente di sviluppo ha raggiunto SIEMENS, anche se nel market share è inesistente a causa del fatturato ridicolo producendo solo software) e questo rende relativamente facile, se non si dipende da librerie del singolo produttore, cambiare velocemente bandiera.
I big sono garanzia di affidabilità, ma navigando un po' nelle loro posizioni di dominio offrono sovente soluzioni a prezzi veramente stratosferici e sono un po' lenti a seguire il progresso in quanto essendo enormi hanno un volano che è molto difficile rallentare per cambiare direzioni intraprese in modo sbagliato.

 

2 ore fa, pigroplc ha scritto:

Anche altri costruttori di hardware tipo Rockwell Automation facevano pagare le licenze, non sono aggiornato ad oggi ma una volta era così. 

Rockwell negli USA è un po' la SIEMENS in Europa...

Modificato: da Marco Mondin
Link al commento
Condividi su altri siti

4 ore fa, acquaman ha scritto:

ma la posizione dominante di siemens la fatta il mercato,

 

Tutte le posizioni dominanti le fa il mercato. Può dipendere da una superiorità tecnologica, da un prezzo particolarmente competitivo, da un'ottima strategia commerciale o, più spesso, da una combinazione di alcuni questi fattori. Questo vale per tutti i prodotti.

Però chi si trova in queste condiziononi non può e non deve abusarne.

Le autorità che vigilano sulla corretta concorrenza ci sono apposta per evitare questi abusi.

In passato, tanto per fare un esempio, l'Autorità USA ha colpito MS, Applee qualche altro colosso; attualmente sta "puntando" Google.

Se e quando si vuole si può regolare il mercato.

In USA Siemens non ha una posizione dominante; infatti le politiche dei prezzi siemens in USA sono allineate a quelli della concorrenza.

In Europa, invece, ha il dominio assoluto anche perchè offre il paccetto completo: dal sensore all'azionamento al si stema di controllo. In Europa Siemens abusa di questa condizione.

 

 

 

Link al commento
Condividi su altri siti

Ciao a tutti, per quanto vedo e leggo da mo, tutti abbiamo una discreta esperienza (a parte Livio che ne ha molta di più) sull'andamento del mercato. Quindi tutti noi conosciamo, perché le abbiam provate, le più svariate tecniche commerciali di competitor di Siemens per prendersi fette di mercato.

 

Anche la stessa Siemens ha fatto la stessa cosa (tutto il mondo è paese) per settori dove il management imponeva un aumento della penetrazione (io parlo per esempio del processo), utilizzando, come si è detto, la prima arma a disposizione per un produttore di hardware.

 

Come accennato da Marco, con il tempo, avremo una standardizzazione degli ambienti di sviluppo ed una personalizzazione delle librerie e su quello probabilmente si sposteranno gli introiti. D'altronde, la diffusione dell'opensource cozza drasticamente con le posizioni dominanti dei big del ns settore.

 

Ambiente di sviluppo dominante contro ambiente si sviluppo condiviso (come si diceva TIA contro Codesys per esempio)

BUS di comunicazione con royalties contro bus di comunicazione condiviso (Profi... contro consorzi di bus aperti)

Da qui poi partono considerazioni che Marco conosce molto meglio, tra compilatori, librerie ecc...

 

Poter scegliere arbitrariamente l'abbinamento hardware e software, penso che sia il sogno di molti, che ha dei risvolti come qualsisasi altra scelta.

 

L'affidabilità costa e in alcuni settori non possiamo permetterci di sperimentarla sull'utilizzatore.

I numeri su cui spalmare la ns applicazione a volte non arrivano menneno oltre la singola unità, per cui necessitiamo di qualcosa pronto,funzionale e sicuro.

 

Quello che attualmente stride è l'imposizione di Euro e di Gb che servono per apparati come il 1200, quando devono svolgere funzioni decisamente non complesse (e sono la gran parte del mercato), solo perché Siemens. A confronto, per tali applicazioni, un Fatek, accettando tutte le pecche del suo software, le svolge benissimo ad un costo irrisorio. 

Un esempio simile lo potremmo fare anche con gli HMI Weintek, dove addirittura il divario tecnico HW e SW è molto ridotto e la giustificazione all'uso della casa teutonica, si riduce al brand (sto citando la fetta di mercato standard, dal 4" al 10/12").

 

(la citazione delle due case asiatiche è data dal fatto che le ho utilizzate e quindi ne parlo per conoscienza. Come già detto, sono stati fatti altri esempi su cui il divario Euro/Gb incide)

 

Buona serata, Ennio

 

Link al commento
Condividi su altri siti

Per come la vedo io, anche chi fa pagare le licenze del sw di sviluppo, spalma il costo di sviluppo poi sui singoli articoli hw. Si fanno pagare due volte.

Perchè non dovrebbero? E' il mercato bellezza!

Proprio perchè dominano se lo possono permettere e lo fanno, il giorno in cui dovessero perdere fette considerevoli di mercato faranno un figurone ad abbassare il costo delle licenze.

 

1 ora fa, Livio Orsini ha scritto:

Però chi si trova in queste condiziononi non può e non deve abusarne

E perchè dovrebbero? sono delle società, esistono per fare profitto! Finchè il mercato tira lo faranno a piene mani. Tanto chi controlla poi è comandato dalle lobby.

 

Guardate cosa fanno gli altri in settori diversi. Nel mercato online o nel welfare giusto per parlare di due settori che in questo periodo invece che scendere salgono.

 

O nella telefonia dove chi comanda si fa pagare il modem e chi vuole rosicchiare mercato ve lo regala..

 

Link al commento
Condividi su altri siti

11 minuti fa, ETR ha scritto:

...
D'altronde, la diffusione dell'opensource cozza drasticamente con le posizioni dominanti dei big del ns settore.

 

Nel mondo informatico anche chi era totalmente contro sta cambiando il suo punto di vista, andando verso una via di mezzo.
Oggi in un Kernel Linux, per esempio abbiamo codice scritto da microsoft ed approvato dai mainteiners. Microsoft stessa si è realizzata la propria distribuzione Linux su cui girano molti server Azure.
Amazon si è creata la sua distribuzione per il suo cloud e non solo, partendo da un progetto aperto come ARM si è anche realizzata le sue CPU per i suoi server.
Google usa Linux per Android e ne trae enormi profitti, contribuisce al codice del Kernel.
Intel scrive direttamente codice e moduli per il Kernel.

Un tempo il Kernel linux era il frutto della tesi di Linus con l'aiuto di una manciata di fanatici (Che per me hanno una visione troppo estremista dall'altro lato e con cui Linus ha litigato più volte in quanto più centrato) oggi nel kernel c'è codice di BOSH, Intel, MS, AMD, Google, Amzon, ABB etc etc etc. 
Opensource non è sinonimo di gratis o di copyleft! Ma di collaborazione in diversi settori. Poi ovvio che i veri segreti è meglio tenerli closed finché se ne può trarre vantaggio, ma ci vanno le vie di mezzo. 

 

Quote

Ambiente di sviluppo dominante contro ambiente si sviluppo condiviso (come si diceva TIA contro Codesys per esempio)

BUS di comunicazione con royalties contro bus di comunicazione condiviso (Profi... contro consorzi di bus aperti)

Da qui poi partono considerazioni che Marco conosce molto meglio, tra compilatori, librerie ecc...

Almeno sui BUS ci stanno provando.
Basti vedere le due implementazioni Opensource di ethercat, IgH e SOEM. Una delle due è pure LGPL in user space permettendo di linkarla dinamicamente a software closed.

Link al commento
Condividi su altri siti

9 ore fa, Marco Mondin ha scritto:

Alla fine per fare un esempio di un big, credo che se SIEMENS spalmasse su hardware il costo delle licenze TIA, probabilmente farebbe aumentare i suoi prodotti di un 2-3% massimo.

Sono perfettamente d'accordo: spalmare sull'hardware il costo delle licenze software sarebbe un vantaggio per tutti.
Purtroppo Siemens (e non solo Siemens), credo facciano un altro ragionamento: chi te lo fa fare di acquistare un altro PLC dopo che hai speso migliaia di euro per le licenze Siemens?

Link al commento
Condividi su altri siti

Fino ad alcuni anni fa ero in contatto con un tecnico Siemens che tra le altre cose mi spiego' che Siemens, ma penso anche la maggior parte delle altre, e' una costellazione di grandi e piccole realta', ognuna indipendente dalle altre ed ognuna con la necessita' di fare quadrare i propri bilanci, pena la dismissione e la sostituzione con altre realta' piu' remunerative.

In poche parole Siemens SW avrebbe poco o nulla a che vedere con Siemens HW con la casa madre probabilmente poco propensa a ripianare a lungo bilanci in rosso.

Link al commento
Condividi su altri siti

9 ore fa, leleviola ha scritto:

chissa, comunque con tutto quello che fanno pagare di licenze l'ambiente potrebbe essere migliore ma si sa chi insegue cerca di fare sempre meglio, basta saper scegliere

Pienamete d'accordo sul fatto che le licenze costino uno sproposito ma, in quanto alla qualità dell'ambiente di sviluppo, è un passo avanti alla concorrenza, codesys e non.

Link al commento
Condividi su altri siti

5 minuti fa, batta ha scritto:

Pienamete d'accordo sul fatto che le licenze costino uno sproposito ma, in quanto alla qualità dell'ambiente di sviluppo, è un passo avanti alla concorrenza, codesys e non.

si può darsi possa piacere a chi lo usa tutti i giorni e ha funzionalità notevoli ma è anche vero che è un mangia risorse

Link al commento
Condividi su altri siti

11 ore fa, leleviola ha scritto:

si può darsi possa piacere a chi lo usa tutti i giorni e ha funzionalità notevoli ma è anche vero che è un mangia risorse

non si può avere tutto.

Link al commento
Condividi su altri siti

14 ore fa, batta ha scritto:

Pienamete d'accordo sul fatto che le licenze costino uno sproposito ma, in quanto alla qualità dell'ambiente di sviluppo, è un passo avanti alla concorrenza, codesys e non.

Secondo me è molto soggettivo.


Dalle considerazioni che metto sotto io prediligo Codesys, ma ripeto è una questione soggettiva. A molta gente non pesano nemmeno le limitazioni imposte da alcuni ambienti, mentre a me pesano molto. A molta gente servono invece alcune funzionalità di alcuni ambienti, che magari io non uso mai.
Il mio socio dal canto suo preferisce B&R, di cui è anche stato dipendente in passato, mentre io per fare un esempio ci ho rimesso una tastiera a causa di un attacco di nervoso per colpa di una complicazione dell'ambiente di sviluppo su cui mi sono intestardito (Uso del mouse su HMI per ridimensionare un oggetto che non va d'accordo con la mia mano poco ferma e la mia vista).

Parlando dei due big forse più noti in Italia:
Non ho usato moltissimo il TIA, ma non lo trovo un cattivo prodotto, anzi è fatto molto bene per un uso molto intuitivo.
Non trovo nemmeno un cattivo prodotto il Sysmac Studio di cui tempo fa feci una riflessione propositiva, meno intuitivo, ma molto scattante.

Come PRO
Il TIA è molto intuitivo, senza nemmeno leggere un manuale si è produttivi per piccole cose in poche ore. Con l'ausilio dei manuali si può fare di tutto.
È forse l'ambiente con più pappa pronta di tutti, ed in alcuni casi in cui si ha molta fretta è una manna. Alcune cose sono fatte davvero bene, come esempio mi viene da pensare al sistema di autotuning dei PID termici, che permette di ridurre l'intervento umano alle ultime affinature permettendo di risparmiare enormi quantità di tempo, in quanto un PID termico è sempre tedioso da tarare per la sua natura molto lenta ed i tempi fisici di riscaldamento/raffreddamento che non possono essere accorciati.

Sysmac ha una migliore integrazione di ST, lievemente più conforme allo standard e si è appoggiata a Ethercat su cui stanno scommettendo la maggior parte dei produttori.
Ha un po' meno pappa pronta di SIEMENS, ma ne ha tanta comunque. Hanno abbandonato la gestione dei dati old school in funzione di una gestione new school, cosa molto furba!

Come contro
TIA è mostruosamente avaro di risorse, ed un ambiente di sviluppo poco scattante per alcuni sviluppatori è un incubo. Le licenze sono spropositatamente care, assolutamente non allineate a cosa offre. È lacunoso sull'object oriented, segue la sua strada separata dagli standard IEC. Ha una gestione dei dati con le DB che mascherano in modo veramente old school, una gestione dei dati che sotto in realtà è moderna e derivata dall'informatica pura. Nel 2020 dipendere da dati come M I(E) O(A) DB etc... è un po' masochistico, non parliamo della gestione degli OB che poteva avere un senso negli anni 90', ma oggi...!
Il difetto più grosso è la lingua! In informatica ormai per convenzione si da come standard assodato l'inglese (Se ne potrebbe discutere ore se è un bene o un male, ma in un mondo globalizzato anche qua uno standard è indispensabile e forse la lingua più usata è il male minore), perché è il più usato nel mondo e perché è brutto vedere applicativi arlecchino con le lingue. Fa molto disordine. Loro sono maniaci del tedesco!

Sysmac ha dal canto suo un ottimo ST, ma lo limita con la paura che i softwaristi nel mondo dell'automazione possano fare pasticci. Tali limiti in un ambiente con tante potenzialità un po' di nervoso lo fanno venire. Per esempio non avere uno stupido MEMCPY e non poter avere un accesso ai puntatori IEC (POINTER TO) e reference IEC (REFERENCE TO) è molto tedioso, in quanto se uno è abituato ad usarle, le cose le fa comunque, ma magari scrive 50 linee di codice dove ne basterebbero 2.
Ha il contro del non poter monitorare i dati negli FB, e questo è un male, in quanto usare i dati solo di tipo globale è una cosa che crea notevole confusione. Ci si gira intorno usando i namespace, ma è un accrocchio brutto esteticamente.
Non permette di organizzare in cartelle un applicativo creando polpettoni in cui ci si orienta a fatica quando si fanno 80-100 FB.
Permette l'uso di breakpoint solo in simulazione, e con le macchine a stati ed i sequenziatori limita il debug.
Le variabili BOOL non sono BYTEs come nei moderni ambienti, ma BITs di words, che con la RAM regalata di oggi è un non senso, in quanto poi gli applicativi mangiano più CPU in quanto per ogni OR o AND su bit devono fare anche le maschere booleane e gli shift. Visto che un applicativo di automazione di AND e OR su bool ne fa molte più di un applicativo PC va da se che è uno spreco mostruoso di risorse.

Parlando dei due che a livello grezzo offrono le prestazioni più spinte:
Automation Studio di B&R è forse l'ambiente che da più pappa pronta di tutti, ed ha i prodotti che in assoluto hanno le prestazioni più spinte sul mercato.
Codesys è forse il più diffuso, mostruosamente conforme all'IEC.

Come PRO
Automation Studio è forse l'ambiente di sviluppo con più funzionalità in assoluto, anche se un po' buttate lì alla rinfusa e mai riorganizzate. Essendo monomarca come SIEMENS permette di estrapolare dai suoi prodotti prestazioni difficilmente raggiungibili da altri. Ha la possibilità di sviluppare in IEC puro, limitato al 61131-3 V2 (oggi abbiamo il V3 ma indicherò nei contro perché non c'è), ha la possibilità di scrivere codice C e C++, con forti limitazioni, ma molto comodo quando si devono trattare protocolli proprietari o sviluppare piccole librerie per alcuni funzioni particolari. C e C++ per alcune cose accorciano in modo drastico il codice. Caricando un compilato binario sul controllore il software è protetto e non può essere scaricato al contrario. I binari sono compilati con GCC e ottimizzati, ottenendo prestazioni elevatissime anche su hardware molto scarsi (Che comunque non regalano).

Codesys è l'IEC611131-3 v3  per eccellenza, supporta l'object oriented in IEC, permette di monitorare di tutto nei watch, entrando anche in oggetti di libreria interni. Oggi con il supporto forte a Ethercat (Dovuto anche al perverso rapporto che ha con Beckhoff) ha prestazioni strabilianti, Ci sono molte librerie di pappa pronta anche se meno dei tre citati sopra. Per chi arriva dall'informatica pura è l'ambiente in cui ci si riesce a muovere in modo più intuitivo. Molte cose sono posizionate come nella maggior parte degli ambienti di sviluppo PC moderni.
Anche lui carica sui controlli/runtime un binario proteggendo il codice. Esiste un forum ufficiale su cui si ottengono pronte risposte ad un sacco di quesiti ed in cui gli sviluppatori sono anche attenti per prendere spunto per nuove funzionalità. È gratuito come ambiente, è molto diffuso, ed ha un runtime DEMO che permette di testare realmente le cose per sessioni di 30 minuti con ethercat e 2 ore senza, il tutto senza comperare ancora licenze runtime.

Come contro

Automation Studio ha il peggior contro nel MAPP, in cui B&R sta investendo fortemente negli ultimi anni spostando troppe risorse su una cosa che odiano la maggior parte degli utilizzatori. Se uno usa B&R ha comunque delle capacità che rendono inutile il MAPP, tuttavia i commerciali obbligano quasi al suo utilizzo. L'ambiente di sviluppo è confuso, con molte cose che hanno nomi diversi da quelli a cui è abituato chi arriva dall'automazione e anche da chi arriva dall'informatica. A differenza di ambienti in cui chi è abituato ad altro ci entra intuitivamente è mostruosamente anti intuitivo. Il C e C++ ci sono, ma il debug è qualcosa di abominevole da fare per via di forti limitazioni. Hanno mischiato il concetto di reference a quello di puntatore creando non poca confusione, non è ne carne ne pesce, e per colpa di questo hanno un limite mostruoso nell'uso di puntatori o reference nelle strutture dati.
Sono rimasti troppo legati alla retrocompatibilità del sorgente, ponendosi mostruosi limiti nel miglioramento dell'ambiente. L'organizzazione dei dati in alcuni FB di sistema è molto confusa. Dipendono da Powerlink e per scelta aziendale non hanno mai fatto un master Ethercat, cosa che se da un lato li spinge sul gradino forse più alto del podio prestazionale per un PLC, dall'altro non essendo SIEMENS e non avendo la sua posizione di mercato che può imporre i suoi non standards, è una scelta discutibile.
L'ST non supporta l'object oriented, purtroppo per come lo hanno creato se mantengono la loro testa dura nella retrocompatibilità sorgenti non è fattibile. Questo comporta che anche se si può usare C++ sono necessari noiosissimi wrapper per usare gli oggetti da ST, che rendono il codice pesante, difficile da leggere e soggetto a bug da distrazione.
L'ambiente di sviluppo è piuttosto pesante (mai come TIA), il completamento automatico lacunoso, mancano molti hot keys che sono indispensabili a chi sviluppa usando poco il mouse. Le icone sono piccole e poco intuitive creando problemi a chi ha difetti visivi come me (Motivo per cui preferisco tastiera ed hokeys al mouse). MANCA IL REFACTORING!!! In un ambiente moderno è brutto. La gestione dei riferimenti incrociati è da maniaci. I Watch difficili e noiosi da gestire.

Codesys manca di un reforming automatico del codice (Ci sarebbe un plugin esterno a pagamento), il codice è salvato in un formato proprietario XML, e difficile farne un parsing con tool esterni (Per esempio framework per PC in cui commenti speciali generano codice automatico lato PC), cosa parzialmente compensata dall'importazione/esportazione PLCOpen XML, che se non altro è uno standard. Non è molto intuitiva la gestione delle librerie e richiede un po' di tempo per prenderci la mano.
Ha una integrazione per codice C, ma dedicata a chi compera l'SDK (Maker di prodotti codesys come i vari EXOR, Beckhoff, WAGO etc), e permette il link dinamico di librerie esterne, sarebbe utilissimo per tantissime cose, ma limitarlo agli SDK è un bel un paletto. L'object oriented permette alcune violazioni della privacy che sarebbe meglio evitare in quanto fonti di bugs insidiosi e nascosti. In parecchi runtime manca una integrazione di un master/device modbus TCP che oggi è comodissima. Ha dei difetti nella gestione della shared memory, una delle sue principali potenzialità, che si aggirano (anche facilmente), ma fanno desistere i più dal loro utilizzo dopo i primi test. È l'ambiente forse con meno pappa pronta, tuttavia per chi lo usa non è una vera limitazione, in quanto mette a disposizione strumenti molto potenti per crearsi le proprie librerie. Alcune cose non sono documentate o lo sono male, si impara ad usarle comunque per reverse engineering, molte sono cose mostruosamente potenti che alla fine quasi nessuno usa perché non sa che esistano. Per esempio l'interfaccia iTextStream permette di aggiungere sorgenti GCode per tutta la catena del suo CN dalle più svariate origini, tuttavia manca documentazione sul come implementare tale interfaccia e come usarla al posto delle tre classi di default offerte. Altro esempio, le VAR INST, molto comode, ma trovare al documentazione su cosa sono non è una passeggiata.
È limitato sulla cinematica della robotica antropomorfa (Rispetto a B&R).

Modificato: da Marco Mondin
Link al commento
Condividi su altri siti

Buona serata

 

ho letto le varie risposte, molto interessanti , soprattutto per uno come me che non fa il programmatore di professione,ma utilizza, oramai solo piu il Tia  ( e tengo rigorosamente scorporati i vecchi lavori in Step 7..ciò messo tanti anni a imparare...e adesso me lo cambiano ? 😃 )

 

se posso dare un mio parere, e chiedo scusa se mi è sfuggito e gia qualcuno ne aveva parlato , io sono pienamente concorde con i riferimenti alle posizioni forse di "abuso" del mercato da parte di siemens , ma dalla mia parte posso dire che  ho iniziato con loro , perchè avevo  ( ho ancora ) un paio di amici con i quali mi confrontavo...e questo..non è poca cosa...

Quindi , quando ancora esisteva la hot line gratuita , comunque avere dei consigli da altri era preziosissimo....

MA soprattutto , quando proponevi siemens , nessuno ti dava contro

Il mercato era preponderante ?  

ho fatto un lavoro con Telemecanique , anni fa, perchè il cliente francese voleva quello... mai piu !   Magari mi sto sbagliando io....era un software magico..ma non saperlo usare...e dovere mettere in funzione un impianto in francia..quando ancora non esisteva il roaming...un bagno di sangue...ripeto...ho iniziato ocn il piede sbagliato...quindi logico che mi sia andato di traverso....

Ho lavorato con MOOG , ecco , mettiamoci una pietra sopra....

 

Ma veniamo al cuore della discussione di Marco , il costo dell'ambiente di svilluppo....

Io , che sono una micro realtà...ho scelto Siemens perchè comunque, che costi o no, mi sono trovato bene negli anni  ( affiancandolo con hardware  VIPA )

Il costo.. beh.. o mia piaceva cosi o mi piaceva cosi...

 

Forse Marco , e mi viene anche in mente Batta , correggetemi , realizzando esclusivamente software, deve essere flessibile con molti marchi e moti prodotti , e trascinarsi dietro i relativi ambienti

 

Senza divagare sul PC , ma ultimamente , il costo dei PG è sceso , in proporzione 20 anni fa, quindi si..i costi ci sono , ma abbordabili ed ampiamente ammortizzabili , se si rimane sul teutonico  ( non conosco ambienti omron )

 

Un TIA, completo di PG , se si ammortizza in tre anni , costa meno del commercialista  ahahahahahaha

 

Ripeto, considerate il mio parere come un mini-micro sviluppatore

Link al commento
Condividi su altri siti

23 minuti fa, luigi69 ha scritto:

...

Forse Marco , e mi viene anche in mente Batta , correggetemi , realizzando esclusivamente software, deve essere flessibile con molti marchi e moti prodotti , e trascinarsi dietro i relativi ambienti

...

E qua centri il nocciolo del mio problema un po' egoistico.
Io ed il mio socio abbiamo una grossa fetta dei lavori in cui ci chiamano per collaborazioni "un po' particolari", molti applicativi non li sviluppiamo noi da zero, mettiamo solo nostre librerie e nostro codice per funzioni "un po' particolari" e lasciamo sovente il resto dell'applicativo ai softwaristi dei committenti.
Tali lavori incidono per un 40% del nostro fatturato, ma hanno il difetto di avere quasi ogni volta un prodotto diverso. Molte volte ci adattiamo a lavorare su macchine virtuali messe a disposizione, tuttavia, visto che abbiamo molte cose ormai standardizzate, se noi avessimo un po' tutti gli ambienti di sviluppo, si potrebbero preparare parecchie delle cose che usiamo ogni due per tre, un po' per tutti essendo poi più veloci in campo.
Aggiungiamo anche il fatto che usando gli ambienti dei committenti, dare assistenza sulle nostre parti di codice diventa complesso per entrambe le parti.
Noi lavoriamo al 100% di software e avere le licenze di tutti gli ambienti che troviamo non è più come pagare il commercialista, inizia ad incidere veramente tanto.
Da questo nascono le mie riflessioni.

 

Link al commento
Condividi su altri siti

27 minuti fa, Marco Mondin ha scritto:

e avere le licenze di tutti gli ambienti che troviamo non è più come pagare il commercialista,

Marco , capisco benissimo !

io ci ho rinunciato perchè sviluppando anche schemi  e quadristica, materialmente non sarei in grado di essere multi-purpose

e la mia testa  è in palla gia cosi, mi immagino migrare spesso da un ambiente ad un altro

Link al commento
Condividi su altri siti

ifachsoftware

Buon anno a tutti.

Ho letto i vari post che condivido per i seguenti punti : 

1) Sicuramente Siemens ha una posizione di monopolio

2) Il software costa parecchio 

 

Personalmente gradirei un software libero per programmare tutte le marche , realmente integrato tra PLC e sistemi HMI/Scada 

dove le differenze le fanno i pacchetti software propri o di software houses portabili da un ambiente all'altro.

Una delle necessità che vedo affacciarsi sempre di più è quella di aderire a dei pattern di sviluppo cosi' come avviene per il mondo PC (abbiamo di recente dovuto realizzare un software per una grossa casa automobilistica che richiedeva su Siemens dei pattern proprietari per gestire le varie logiche).

La gestione dei pattern dovrebbe a mio giudizio essere realizzata in open source per tutti per definire una volta per tutte uno standard di lavoro.

 

A favore di Tia Portal direi che la marcia in piu' che vedo è l'integrazione PLC - HMI oltre che alla facilità d'uso.

 

 

 

 

 

Link al commento
Condividi su altri siti

  • Livio Orsini locked this discussione
Ospite
Questa discussione è chiusa alle risposte.
×
×
  • Crea nuovo/a...