Newsgroup: it.comp.lang.delphi
Titolo: TurboAsync ho dei problemi. Lunghetto...

Partiamo dai dettagli iniiali D6Pro e AsincPro 4.06.
Sto scrivendo un software al quale alla medesima interfaccia Rs232, utilizza
solo tre fili Rx,Tx e Gnd, tramite una centrale che trasforma il protocollo
da Rs232 a Rs485 ed alimenta i dispositivi seriali., sono appunto collegati
fino a 24 dispositivi seriali ognuno con il suo indirizzo (es. 01, 02 ect.).
Il sw che sto scrivendo deve interrogare e comandare dei dispositivi e nel
caso questi non rispondano a dovere dopo n tentativi metterli in fuori
servizio ed eseguire le conseguenti operazioni.
Il problema ce l'ho con la porta seriale dove in un ciclo Repeat ...Until
invio la stringa di comando al dispositivo ma non riesco al termine di
ciascun invio a porre in "ascolto" il data pack o la porta seriale,  non a
livello Hw ma a quello sw, infatti dopo che la stringa di comando è stata
inviata le n volte, il parser analizza ben quattro stringhe di risposta.
Ovvero prima vengonoesauriti tutti i tentativi di tx e poi si leggo i dati
in arrivo sulla porta.
In pratica io devo inviare la stringa di comando, attendere un certo periodo
e se non ottengo risposta oppure ricevo un msg di errore ripetere il ciclo
di  trasmissione fino al numero di volte previsto.
Ho provato con delayTicks ma senza un apprezzabile risultato.
Spero in una anima o più anime pie nel NG che possano aiutarmi.
Grazie Carlo

 ripetere il ciclo di  trasmissione fino al numero di volte previsto.
Non riesco a capire nulla di quello che:
- vuoi fare
- stai facendo
- non riesci a fare
Non mi sembra che TurboAsync (chiamiamolo cosi'...) abbia dei problemi, l'ho
utilizzato piu' volte e ha sempre fatto il suo dovere. Cerca di spiegarti un
po' piu' chiaramente.


Io credo di averti capito.... ma solo perché è il mio lavoro da quasi due
anni... :-)
sulla 485 occorre (come hai detto tu) utilizzare un approccio master-slave
al problema, cioè tu interroghi e l'apparato chiamato in causa risponde, se
presente... poi si passa al successivo e così via....
all'inizio ho fatto alcuni esperimenti con i componenti turbopower tentando
di utilizzare il modo rs485, ma con scarsi risultati... infatti l'approccio
usato è quello ad eventi, perfetto sulla 232 ma inusabile su linea 485.
alla fine io ho optato per la soluzione a basso livello, basato sulle
primitive CreateFile, ReadFile e WriteFile in modalità sincrona, che
permettono un grande controllo, specie sui timeout... il tutto in una classe
di comunicazione multithread... ma non è necessario....
Spero di esserti stato (un pochino) di aiuto.
Maurizio

 ha scritto nel messaggio
news:kBnKb.233612$e6.92...@twister2.libero.it...


 quattro stringhe di risposta.
Non si chiama Asynch per nulla, ma devi anche processare gli eventi che
accadono.
Se postassi un po' di codice sarebbe meglio, comunque da quel che ho
capito usi un ciclo in cui mandi i messaggi e (non so come) attendi una
risposta. Normalmente non e' l'approccio piu' adatto da usare con gli
APRO; fino a tutte le sub release della 3, ad esempio, bisognava servire
gli eventi della seriale entro 3 secondi, altrimenti il dispatcher si
arrabbiava.
Per aspettare un evento dalla seriale dovresti attaccare al componente
ComPort almeno un TimerTrigger; immediatamente prima o dopo l'invio del
comando al dispositivo invochi
TheCom.SetTimerTrigger(FTimeoutHandle, FTimeoutTime, True);
che attiva un timer di FTimeoutTime ticks (1 tick = ~1/18 di secondo )
dove FTimeoutHandle e' stato tornato da
  if FTimeoutHandle = 0 then
    FTimeoutHandle := TheCom.AddTimerTrigger;
da chiamare dopo l'apertura della porta. Ricorda che quando non serve
piu' e' bene disfarsene con
  if FTimeoutHandle <> 0 then begin
    TheCom.RemoveTrigger(FTimeoutHandle);
    FTimeoutHandle := 0;
  end;
Ora, dopo SetTimerTrigger il timer scattera' al termine dei ticks
impostati, a meno che sia resettato prima (con
SetTimerTrigger(FTimeoutHandle, 0, False)), cosa che farai quando hai
ricevuto risposta dal dispositivo.
Se scatta, viene chiamato l'handler dell'evento OnTriggerTimer, dal
quale potrai ad esempio incrementare il numero di mancate risposte del
dispositivo preventivamente interrogato e prendere altri provvedimenti
del caso.
Dato che sarebbe opportuno tenere gli handler degli eventi della ComPort
il piu' brevi possibile, personalmente sono solito postare (asincrono)
un messaggio in cui dico quale evento e' scattato; ad es:
procedure TdmComPort.TheComTriggerTimer(CP: TObject; TriggerHandle:
Word);
begin
  if TriggerHandle = FTimeoutHandle then begin
    if Debugging then
      TheCom.AddStringToLog('RE-ENABLING TRANSMISSION AFTER TIMEOUT');
    if FCommState = csWaitingAnswer then
      PostMessage(FWindowHandle, WM_PKT_EVT, WP_ANS_TOUT, 0);
  end
  else if TriggerHandle = FTimerHandle then begin
    if Debugging then
      TheCom.AddStringToLog('TIMER ELAPSED');
    PostMessage(FWindowHandle, WM_PKT_EVT, WP_TIMER, 0);
  end;
end;  // TheComTriggerTimer
Nella WndProc poi posso decidere se ritrasmettere il messaggio o
dichiarate il dispositivo fuori servizio.
In definitiva e' una macchina a stati che lavora in asincrono:
envt Click pulsante o scatto di un TTimer:
pronto? -> no: attendi prossimo evento attivazione o raise
 |
 +-> SendCommand; stato = attesa risposta;
 evnt Ricezione -> gestisci risposta; stato = pronto;
 evnt Timeout -> gestisci timeout; stato = pronto;
Vedi anche il sito di Paul Breneman per molti esempi, alcuni anche
piuttosto complessi
http://www.turbocontrol.com/APro.htm
Saluti
Paolo Arosio
-- 
"La dimostrazione dell'esistenza di specie intelligenti nell'universo
 e' che non ci vengono a trovare"

On Sun, 04 Jan 2004 18:46:27 GMT, libero news wrote:
Scusa la domanda che non c'entra nulla con la risposta al tuo messaggio. Che
tipo di schede multiporta (se le usi multiporta) seriale utilizzi? le 24
porte stanno tutte su di un pc? vengono viste come normali com dal sistema
operativo?
any help appreciated
ciao
-- 
Auguri a tutti di buon natale e felice anno nuovo
Fabrizio Mancini - <f[.]mancini[@]tin[.]it> 09/01/2004 9.14.02
Open Delphi Manual (
http://groups.yahoo.com/group/delphi_open_manual/
)

 ha scritto nel messaggio
news:1htdwsr5m02ff$.dlg@ostialido.it...


 ha scritto nel messaggio
news:btgrt8$6u8ll$1...@ID-30644.news.uni-berlin.de...


 Veramente un grande GRAZIE per la tua esauriente,  risposta, che ora
E' stato un piacere. Allora, visto che ci siamo, ti chiederei di evitare
di riportare tutto il messaggio cui rispondi: v. ad esempio
http://wiki.news.nic.it/QuotarBene
