Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Sondaggio: VB.NET in automazione industriale.

Gradirei sapere se utilizzate VB.Net nel settore dell'automazione
industriale, ad es. per acquisizione dati, avanzamento produzione,
supervisione impianti, ecc. Sarebbe anche utile un vostro commento sull'uso
dell'ambiente di sviluppo e sulla stabilità del framework in tale ambito.
Grazie a tutti!

Un attimo prima di skippare tutto mi sono accorto che  Rogis ha scritto:
Giusto domani ho una riunione per vedere se convertire un sw di quel tipo da
vb6 a vb.net...
ti farò sapere col tempo...
-- 
Alex
"La differenza tra un genio ed un idiota è che il genio ha i suoi
limiti" (Anonimo)
Posted from X-Privat Free NNTP server - 
www.x-privat.org

Io lo uso anche in tali ambienti, e il fatto di poter creare windows
services, poter gestire (seriamente) comunicazioni TCP-IP, avere il
multithreading e' un bel vantaggio.
Aggiungi a questo la possibilita di installare il PC facendo XCopy e scopri
che puoi mandare le patch via email a farle installare al responsabile di
produzione senza problemi di "Error 429..."
Ovviamente ho solamente 'sfiorato da lontano' le possibilita' di .NET...
Svantaggi: Non funziona su Win95 e richiede macchine recenti (PIII in su...)
-- 
Corrado Cavalli [Microsoft .NET MVP-MCP]
UGIdotNET - 
http://www.ugidotnet.org
Weblog: 
http://www.ugidotnet.org/710.blog


Il fatto che abbia una discreta velocità è sicuramente un bene.
Io personalmente non lo utilizzo per diversi motivi:
- Ho tanta roba in VB6, e mi rompe buttarla
- I PC industriali sono *molto* indietro rispetto ai desktop, come
processori e Ram. A meno che per 'industriale' non si intenda un pc office
inglobato in un case metallico, se ci riferiamo ai PC industriali veri
(quelli che passano i test termici, per intenderci), un PIII 800 è già una
signora macchina.
- Una certa gioventù dell'ambiente. Un software in ambito industriale deve
essere immune da bug anche restando in piedi per anni senza mai spegnersi. E
nessuno sa se .Net dopo un anno di lavoro senza reboot va ancora. Lo scotto
del bug del gettickcount che ha una incertezza dopo 48 giorni l'abbiamo già
pagato.
- I sistemi NT hanno tutta una serie di sfighe legate alla autenticazione,
che rende problematica l'applicazione di determinate soluzioni. Per questo,
in ambito industriale si cerca di evitare NT, 2k e XP, almeno sulle macchine
distribuite. E siccome .Net non è vada a nozze con sistemi W95 e W98...
Però sono convinto che, appena avremo dati certi su possibili memory leak o
altre sfighe di lungo termine, anche noi batteremo quella strada.
Bye
Alberto

 pagato.
Quale bug? Da sempre si sa che dopo 49.7 giorni il valore va in 'wrap' (e
scritto anche in MSDN...)
"The elapsed time is stored as a DWORD value. Therefore, the time will wrap
around to zero if the system is run continuously for 49.7 days."


 Quale bug?
Emmadonna che pignoleria...
Lo so che è una cosa normale e documentata. Ma siccome nel post era
marginale, ho 'tirato via' nella esplicazione.
Se consideri però che tantissime cose, che si trovano già fatte, usano il
tickcount, e quindi dopo neanche 50 giorni vanno in pallino, siamo quasi a
livello di bug.
Ciao
Alberto

 Alberto
-- 
.A
UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org
Read my blog at: 
http://www.ugidotnet.org/4.blog

 non è marginale, perchè cambia tutto il senso del discorso
Come vuoi.
Si parlava d'altro. Ho pensato di fare un esempio di qualcosa che chiarisse
meglio il senso di uno dei punti citati.
E, come spesso avviene, una discussione interessante nella sua globalità
viene dirottata sul puntino sulle i.
Se non avessi fatto un esempio, sarebbe arrivato un altro a dire "che cavolo
dici? Fai un esempio!" e giù a discutere. Facendo l'esempio, ecco che arriva
quello che si impunta su quello.
E la discussione vera, che mi interessava veramente, è già finita.
Peccato.
Alberto