Tempi Sviluppo Scada Vs Visualbasic

[Ricky.Fantin]

Ciao,

a qualcuno potrebbe sembrare il solito confronto tra SCADA e VB, invece stavolta non è il solito confronto morale se è meglio l'uno o l'altro...

Vorrei essere più concreto e parlare di ore di sviluppo.

La butto lì:

Secondo voi è giusto considerare che con uno SCADA si risparmia il 50% del tempo di sviluppo rispetto a VB?

L'applicazione tipo che faccio è quella di una stazione di collaudo a fine linea, quindi:

- movimentazioni di pallet con riconoscimento a codice a barre o altro

- connessioni automatiche (elettriche e/o idrauliche a seconda se si tratta di alternatori o pompe)

- acquisizione dati analogici, di solito una decina di valori e memorizzazione in database.

Di solito in vb6 ci vogliono circa 300 ore, va considerato il fatto che attualmente vb6 viene usato limitandosi ai form e ai moduli.Gli unici oggetti "prefatti" sono oggettini per fare i sinottici.

Ho fatto una valutazione con CITECT 6.01 dove una licenza costa 1900€...

Praticamente per risparmiare qualcosa rispetto a VB dovrei impiegare 72 ore in meno, per pagarmi almeno la licenza runtime.

Che dite è un paragone che regge?

Grazie Ricky

[irpick]

Secondo voi è giusto considerare che con uno SCADA si risparmia il 50% del tempo di sviluppo rispetto a VB?

direi che il risparmio è molto maggiore , il vantaggio di Vb è notevole se faccio un software per N macchine,

per singole unità il confronto è improponibile.

Ciao, Irpick

[Hellis]

Utilizzare uno SCADA al posto di un linguaggio, mettendo sul tavolo i benefici che citi, 6 anni fa costituiva il 'cavallo di battaglia' dei nostri 'ex' fornitori. Poi quando tutto ha iniziato ad andare stretto etc etc, sono stati messi inesorabilmente alla porta, e siamo migrati a soluzioni scritte in vb6.

[ifachsoftware]

Fossi in te spenderei alcune ore una volta sola per farti dei bei moduli riusabili e poi il risparmio sara' enorme.

Considera che l'unico vantaggio di uno scada commerciale rispetto a VB e' l'avere le librerie di comunicazione gia' fatte per il resto VB li batte tutti alla grande.

Considera che per gli impianti che faccio io in genere non mi ci vogliono piu' di 24 ore per fare il programma completo per una linea di discreta complessita'.

Gli scada hanno inoltre l'enorme svantaggio che sono uno diverso dall'altro quindi non si venga a dire che uno scada e' uno standard e che poi uno della manutenzione sa metterci sopra le mani poiche' se uno sa usare lo scada X e si ritrova lo scada Y avra' da studiare quasi come per imparare VB per poterci mettere sopra le mani.

Inoltre con VB puoi fare TUTTO quello che ti pare mentre con SCADA commerciali non e' sempre cosi'.

Considera che per le librerie di comunicazioni ci sono ditte che ti vendono DLL a prezzi modici (anche senza royalties) che quindi ti evitano lo scoglio a volte insormontabile di dover conoscere un protocollo di difficile implementazione o peggio ancora sconosciuto.

Ciao

[Ricky.Fantin]

In sintesi mi sembra di aver capito che:

-se usi uno scada rischi di buttarti in un mare pieno di squali, visto che un sacco di gente sviluppa con scada significa che c'è altrettanta concorrenza

-sapendo già programmare è meglio proseguire e specializzarsi su quella strada magari iniziando a vedere la programmazione di ocx e passando da vb6 a vb.net

Quindi diciamo che per un impianto di piccole dimensioni è preferibile VB.

Però se ho un impianto medio-grande le prestazioni di VB sono inferiori rispetto ad uno SCADA, oppure è così perchè non è usato nel migliore dei modi?

Voi come lo usate per aumentarne le prestazioni? usate OPC server? DLL? di che ditta?

io uso Sintesi ma non mi sentirei di usarle per impianti grossi.

Ciao

[MrC]

Ciao Ricky

la discussione è interessante, ma bisogna fare una distinzione:

Se tu programmi in Vb creando delle classi, lavorando in modo da riuscire a riutilizzare il software che scrivi, arrivi a tempi di sviluppo confrontabili con quelli di uno scada.

Ad esempio dovresti riuscire a standardizzare la gestione degli allarmi, dei log, dei grafici.

Se invece ogni volta riparti da zero o quasi, i tempi si allungano inevitabilmente.

[ifachsoftware]

Voi come lo usate per aumentarne le prestazioni? usate OPC server? DLL? di che ditta?

Considera che le prestazioni dipendono esclusivamente da 3 soli fattori :

- il mezzo di comunicazione

- la quantita' di dati da trasferire

- la frequenza con cui vengono aggiornati

E uno scada non differisce in nulla da un programma dedicato se non per due fattori

1) Se scrivi male il protocollo lo scada sara' piu' veloce mentre se lo scrivi bene sarete pari

2) Con uno scada il driver e' quello mentre se ti fai te la comunicazione magari in certe situazioni puoi fare dei giochetti particolari per guadagnare tempo che con uno scada non potresti mai fare.

Ciao

[Ricky.Fantin]

Considera che dove lavoro attualmente non c'è mai stato nessuno che abbia imparato bene l'utilizzo di VB, tutti i progetti installati dai clienti (perfettamente funzionanti) non hanno classi ma solo form e moduli.

Forse è anche x questo che le prestazioni non sono ottimali.

es: Per animare i sinottici usiamo i timer di vb, sai bene che imposti anche 50-100ms di intervallo però se il pc non ci sta dietro non li rispetta quei tempi. Lo stesso vale per la temporizzazione dei driver...

Ciao

[lucios]

Forse è anche x questo che le prestazioni non sono ottimali

Escluderei che scegliere una filosofia di programmazione rispetto ad un'altra influenzi significativamente le prestazioni del software. Programmando rigorosamente ad oggetti (con classi e quant'altro) si hanno grandi vantaggi di struttura e di riutilizzo del codice, ma si creano inevitabilmente degli eseguibili più lunghi, quindi (teorici) rallentamenti dell'esecuzione.

In ogni caso gli algoritmi da sviluppare per un applicativo SCADA non sono certo tanto complessi da creare problemi di velocità (soprattutto con i moderni processori).

Ciao

[Livio Orsini]

Escluderei che scegliere una filosofia di programmazione rispetto ad un'altra influenzi significativamente le prestazioni del software.

Io non sarei così drastico. VB è un linguaggio interpretato, anche se ha parecchi vantaggi rispetto al vecchio QBasic, non è compilato come, ad esmpio, il "C". E' pur vero che dalla seconda esecuzione, dopo ogni restart del PC, i tempi di escuzione diminuiscono di molto perchè l'eseguibile va in RAM (se ce n'è a sufficienza). Però anche con macchine potenti se, ad esempio, deve eseguire algoritmi di sort su tabelle, i tempi non sono certo ottimizzati. Rimangono poi le difficoltà nel far eseguire più task in contemporanea, è possibile ma si sprecano risorse (anche un po' a causa di win).

Poi dipende con quale SCADA lo si compara; alcuni sono ben ottimizzati perchè ottimamente studiati e progettati; altri sono ciofeche immonde.

I vantaggi principali di uno SCADA commerciale sono che svilupppi l'applicazione in breve tempo, hai librerie e driver consolidati e testati.

Però se hai da fare parecchie macchine, anche diverse tra loro, forse vale la pena di pensare allo sviluppo di un software personalizzato, magari utilizzando linguaggi *.NET (io penserei a C#.NET e C++.NET)

Modificato: 5 aprile 2006 da Livio Orsini

[lucios]

Mah, Livio, dalle mie esperienze posso dirti che se prendi un pc un pò "robusto" e non fai delle vaccate immani di progettazione non ci sono troppi problemi.

Poi non è vero che VB è interpretato (parlo di VB6)! L'eseguibile che ottieni dopo la compilazione non sarà ottimizzato e performante come quello ottenuto in Visual C++, ma, bechmark alla mano, non è niente male.

Io ho fatto applicazioni in cui andavo a maneggiare intensamente delle tabelle di database (Access) e i risultati sono stati buoni (che diamine, non stiamo mica parlando di real-time) .

Però se hai da fare parecchie macchine, anche diverse tra loro, forse vale la pena di pensare allo sviluppo di un software personalizzato, magari utilizzando linguaggi *.NET (io penserei a C#.NET e C++.NET)

Perfettamente daccordo, soprattutto se sono applicazioni che escono un pò dal seminato rischi di tribolare di più con uno SCADA che facendoti tutto in casa.

Ciao

[Livio Orsini]

Poi non è vero che VB è interpretato (parlo di VB6)! ...

Sorry, VB6 è interpretato, come sono interpretati anche VB.NET e C#.Net, anche se in modo differente.

La differenza fondamentale con i vecchi interpreti, tipo QBasic tanto per fare un esempio, è che non è interpretato riga a riga. Tu prova a lanciare un'applicazzione VB6 senza che nel sistema ospite sia presemte la VBrun!

Io ho usato un compilatore Basic di MS, si chiamava QuickBasic. Quello era veramente compilato e te ne accorgevi da come eseguiva i jobs. Sui vecchi 286 andava più veloce un'applicazione QuickBasic di una corrispondent VB4 su una macchina 486DX.

Io ho fatto applicazioni in cui andavo a maneggiare intensamente delle tabelle di database (Access) e i risultati sono stati buoni (che diamine, non stiamo mica parlando di real-time) .

Certamente VB e Access è uno dei matrimoni più riusciti.

I problemi che si possono incontrare usando VB6 per realizzare uno SCADA non sono certo, a mio giudizio, quelli di lentezza. Si possono incontrare problemi quando è necessario far girare in contemporanea più processi, ma organizzandosi bene si risolvono tranquillamente.

Però dovendo iniziare oggi non conviene usare VB6, che MS non supporterà più tra qualche mese, ma iniziare direttamente con C#

Modificato: 5 aprile 2006 da Livio Orsini

[Ricky.Fantin]

Si possono incontrare problemi quando è necessario far girare in contemporanea più processi, ma organizzandosi bene si risolvono tranquillamente.

cosa intendi per organizzandosi bene? se io ho due processi che devo eseguire parallelamente li devo mettere in 2 dll separate che vengono poi richiamate all'interno del progetto? (parlando sempre di vb6)

Però dovendo iniziare oggi non conviene usare VB6, che MS non supporterà più tra qualche mese, ma iniziare direttamente con C#

perchè escludi VB.net?

non è che il passaggio da VB6 a C# sia più traumatico rispetto al passaggio da VB6 a VB.net?

Ciao Ricky

[Livio Orsini]

Organizzarsi significa progettare bene e verificare a priori tutte le interazioni tra i task.

Io sceglierei C# per preferenza personale. C# e VB.NET non differiscono di molto tra loro. Il mitico Francesco Balena dichiarò di averli imparati in contemporanea

[lucios]

Non dimentichiamoci che, utilizzando VB.NET, è possibile avere progetti composti da file scritti in entrambi i linguaggi, inoltre è molto più semplice fare ed interagire con pagine ASP (ASP.NET) che sono tanto di moda oggi...

Ciao

[Savino]

Sorry, VB6 è interpretato, come sono interpretati anche VB.NET e C#.Net, anche se in modo differente.

La differenza fondamentale con i vecchi interpreti, tipo QBasic tanto per fare un esempio, è che non è interpretato riga a riga. Tu prova a lanciare un'applicazzione VB6 senza che nel sistema ospite sia presemte la VBrun!

Exactly !!

Java programs require the Java Virtual Machine runtime environment in order to run (see Java). 
The same for Visual Basic programs, which cannot be executed natively in the computer. They need the runtime module that converts the Visual Basic code into the machine language of the computer. In a Windows PC, the actual VB runtime module is named VBRUNxxx.DLL, where xxx is the version number (300, 400, 500, etc.).
Microsoft's .NET platform uses the Common Language Runtime (CLR) to compile .NET applications into machine language before executing them (see CLR). See runtime library and runtime version.

Dunque, e' vero che il.EXE ricavato da VB6 nonstante tutti i miglioramenti in merito in confronto con le altre vecchie versioni, ha bisogno tuttavia della VBRUNxxx.DLL, per potere girare.

Comunque, regolarmente la VBRUN300.DLLviene gia' fornita nei sitemi operativi XP per default e tutte quante sono liberamente scaricabili da diversi siti Web in ogni caso.

[lucios]

Ok, chiamiamola pure compilazione "leggera". Ma resta il fatto che se vuoi avere degli eseguibili più performanti di VB devi lavorare in C/C++/VC++/Visual Builder.

Con Delphi (altro ottimo prodotto) siamo alla pari, con Java, .NET, ecc. le prestazioni sono mediamente inferiori (sempre naturalmente che si riescano ad apprezzare .

In ogni caso per progettare un sistema di supervisione il problema, secondo me, non sussiste.

Ciao

[Livio Orsini]

In ogni caso per progettare un sistema di supervisione il problema, secondo me, non sussiste.

Hai perfettamente ragione! Per una supervisione i veri problemi sono altri, prima di tutto la corretta organizzazione del software.

[Savino]

Programmando rigorosamente ad oggetti (con classi e quant'altro) si hanno grandi vantaggi di struttura e di riutilizzo del codice, ma si creano inevitabilmente degli eseguibili più lunghi, quindi (teorici) rallentamenti dell'esecuzione

Qui non sono d'accordo.

i tempi di escuzione diminuiscono di molto perchè l'eseguibile va in RAM (se ce n'è a sufficienza).

Una API ben costruita dovrebbe in anzitutto(alla inizializzazione ) fare un test della RAM disponibile nel sistema per valutare se questo e' capace di supportare la sua performance.

....... la corretta organizzazione del software.

non solo... anche la padronanza del tool di programmazione,sistema operativo e hardware utilizzato.

.....degli eseguibili più performanti di VB devi lavorare in C/C++/VC++.......

Senza dubbio.

Con Delphi (altro ottimo prodotto)....

Windows O.S. e' anche una ottima piattaforma, nonostante non piace a tanti.

Secondo me le cause principali nei rallentamenti in una API sono la cattiva gestione nel maneggio delle risources grafiche nella RAM ( bisogna caricare, utilizarla e liberarla), e nella convivenza RUNTIME della applicazione con il sistema operativo, cioe' come l'API incorpora la sua propia coda di messaggi nella Main windows message pump queue.

Questo, lo puoi apprezzare solo con Visual C++ e non con VB oppure un SCADA system.

In WIN.. ce soltanto una maniera di scrivere bene le applicazioni, altrimenti non giri bene.

[Livio Orsini]

Windows O.S. e' anche una ottima piattaforma, nonostante non piace a tanti.

Non è che non piace, a parte la politica commercciale MS, ha un difetto fondamentale per un OS multitask: non protegge sia il codice che i dati. Per un'applicazione in ambiente Home od Office è un difetto relativo, mentre è fondamentale per un'applicazione in ambiente industriale.

In effetti quando hai un crash di Win e vai a vedre le info di debug trovi sempre che lo stack è andato per i fatti suoi, questo proprio perchè Win non protegge l'area dati come fanno tutti gli O.S. robusti: RTOS, QNX per esempio.

Modificato: 7 aprile 2006 da Livio Orsini