Newsgroup: it.comp.lang.c++
Titolo: 95 oppure NT?

L'argomento non e` proprio C/C++, ma quasi!
Devo sviluppare un software per pilotare alcune
schede per il controllo industriale.
Mi e` stato imposto di costruire degli oggetti
ActiveX, tramite Visual C++ 5.0.
Anche se la cosa e` fattibile, sento dire
che W95 non e` realtime. Cosa vuol dire?
Forse che in W95 non si puo` garantire la
costanza temporale degli istanti di
campionamento? Ovvero la costanza temporale
degli istanti in cui vado ad eseguire il 
programma utente? Questo vuol forse dire che
un inatteso processo in piu` (come per esempio
l'esecuzione di Word) puo` rallentare
la macchina quel tanto che basta da far perdere
il concetto di realtime?
Se si ad una o ad entrambe le domande, con
WNT cio` non succederebbe?
Perche`?
Se no, cosa potrebbe voler dire che W95 non
e` realtime, e perche` per il controllo industriale
non va molto bene su W95?
Spero di essere stato chiaro.
Lo so, non e` il mio forte!
Grazie anticipatamente.
-- 
Righetti Michele
University: Universita` degli studi di Padova (Italy)
E_mail address: 
so...@dei.unipd.it
--
Automatic posted from 
anna.dei.unipd.it
 [147.162.2.100]
via Mailgate Server - 
http://www.mailgate.org

non va molto bene su W95?
Questo dipende molto dal tipo di applicazione. Se per controllo industriale
intendi il comando di I/O digitali collegati ad organi meccanici, eviterei
l'utilizzo di Win32 optando per sistemi operativi "Monotask" (io ad esempio
utilizzo il buon vecchio Dos) o Multitasking real time (ad esempio RMOS
della Siemens). A questo proposito va considerato anche il fatto che spesso
i PC "industriali" hanno un hardware affidabile ma ben poco prestante
sicuramente insufficiente a fare girare Win32. Sempre a titolo di esempio io
utilizzo una cpu 386SX con 1MB di ram e 1,5MB di eprom_disk!!. Diversa è la
situazione in caso di controllo industriale inteso come supervisione nel
quale utilizzerai prevalentemente schede di comunicazione (es. multiseriali)
per colloquiare con i controllori di macchina ( es. PLC o CN). In questo
caso la famigliarità dell'interfaccia grafica Windows e le possibilità di
scambio dati COM e OLE con altri programmi (es. gestionali) può essere una
carta vincente. Occorrerà solo accertarsi che un crash del supervisore non
abbia effetti devastanti sull'impianto!
Ciao Andrea
_____________________________________
Email: sostituire "NOSPAM" con "flashnet"
Email: replace "NOSPAM" with "flashnet"

Perche`?
Neppure W/NT e` un sistema operativo real-time.
Fra i tantissimi sistemi NON-realtime, ci sono
naturalmente varie "sfumature", in termini di
"probabilita`" che il tempo di risposta ad un evento
"sfori" dal normale.  W/95 e` particolarmente
antipatico da questo punto di vista, per come
e` fatto il suo kernel, capacissimo di bloccare
la macchina -- di rado, ma per tempi lunghi --
per "fare pulizia" di allocazioni di memoria
virtuale, buffer di disco, eccetera.  W/NT, in
effetti, da questo punto di vista e` meno peggio;
queste inevitabili e indispensabili attivita`
di "manutenzione interna" ``tendono'' ad essere
eseguite un po' alla volta nel corso del tempo,
invece che tutte in una volta bloccandoti la
macchina "di rado" ma "per tempi lunghi".
Ma anche su NT, non c'e` quella garanzia assoluta
che un vero sistema real-time ti offre.  A seconda
di quale sia l'apparato che intendi controllare,
questo puo` essere un problema.  Se un "occasionale",
"modesto" ritardo nel tempo di risposta e` in fondo
accettabile (quindi, non c'e` la *vera* esigenza
del real-time), allora NT puo` andare bene (certo
meglio di 95!).  Se no, dovresti esaminare i veri
sistemi realtime (VxWorks, eccetera) -- ma non credo
che nessuno di essi supporti ActiveX oggi.
Alex
--
 ____    Alex Martelli, Bologna, Italia -- email: 
al...@magenta.com
 \SM/___                                 
http://magenta.com/~alex
  \/\bi/     You never know what is enough unless you know what
     \/          is more than enough.

che W95 non e` realtime. Cosa vuol dire?
come gia' ha scritto Alex, ne' win95 ne' NT sono realtime nel senso
stretto del termine. Cio' non toglie comunque che si possa usare NT
per il controllo industriale se i requistiti di realtime non sono
stringenti. 
Lascerei perdere win95, oltre ai motivi gia' elencati da Alex,
aggiungere che e' poco stabile e a causa dell'architettura ancora
parzialmente a 16bit ha grossi problemi di multithreading. Ad esempio
tutto lo USER (il modulo che gestisce l'interfaccia utente) e' ancora
a 16bit e quindi non-rientrante; ogni funzione e' protetta da un unico
mutex che impedisce l'esecuzione contemporanea delle funzioni da parte
di piu' programmi. Per cui anche utilizzando thread a priorita'
realtime a volte si possono avere ritardi anche consistenti,
dell'ordine dei secondi, delle decine di secondi o peggio...
Come win95 anche NT non offre alcuna garanzia di realtime pero' ha
funzionamento molto piu' fluido, eventuali ritardi nella risposta sono
decisamente piu' ridotti e limitati per lo piu' alle situazioni di
massimo carico della cpu.
Gianpaolo Bottin
- Live Long and Prosper -

...
:L'argomento non e` proprio C/C++, ma quasi!
:Devo sviluppare un software per pilotare alcune
:schede per il controllo industriale.
:Mi e` stato imposto di costruire degli oggetti
:ActiveX, tramite Visual C++ 5.0.
:Anche se la cosa e` fattibile, sento dire
:che W95 non e` realtime.
[snip]
Cerca nel sito
http://members.aol.com/rtproe/
dove puoi trovare un prodotto che permette di sviluppare applicazioni
real-time
sotto Win95 e WinNT.
Troverai anche alcune considerazioni sul diverso comportamento dei due S.O.
in condizioni "real-time".
Buona lettura.
Massimo

Altro sito per un kernel RT che sia compatibile con WinNT
http://www.pharlap.com/
(questo e' un kernel commerciale, mentre il precedente e' free).
Massimo

che nessuno di essi supporti ActiveX oggi.
Come ho detto ci sono estensioni real-time a Windows NT, ma non
_credo_ che abbiano un supporto real-time anche per ActiveX/COM [*]:
dopo tutto se il sistema non ha il completo controllo del COM sia dal
lato client che da quello server, un qualunque ritardo nel
marshalling, proxy stub, etc. non consentirebbe di prevedere il tempo
massimo richiesto da una chiamata ActiveX (questi problemi si
dovrebbero avere solo con server out-of-process o remoti - in server
in-process [DLL] una chiamata ad un metodo di interfaccia equivale non
è nulla di più di una normale chiamata di funzione).
[*] = questo non significa che non sia possibile, ad esempio,
costruire un sistema di controllo real-time ed esporne un'interfaccia
via ActiveX - non si può però costruire un sistema di campionamento e
far passare attraverso un'oggetto ActiveX (se out-of-process o remoto)
tutti i dati che si stanno campionando. [esperienza personale: ho
avuto molti problemi del genere riscrivendo in VC++/ActiveX un
prototipo di un sistema di riconoscimento vocale per parlato discreto
che avevo scritto qualche anno fa in Borland Pascal in DOS - morale:
non usare ActiveX out-of-process se la velocità è importante].
--
Roberto Lupi
Electronic Engineering Student - University of Ancona - Italy
Linux/NT System Administrator
Linux/Win32 Developer