Il linguaggio Visual Basic di Microsoft
 

Rallentamento enorme da flusso COM RS232

ApipApip 19 Mar 2015 20:16
Ciao

magari mi potete consigliare con qualche riga di codice....

Prelevo dati dalla COM-RS232, questi sono un flusso continuo di singoli dati
separati da ";" provenienti da uno specifico *****ware.

Ho da principiante provato alcuni modi e questo sotto è quello che rallenta
meno...

Ma come apro la COM, se sposto l'applicazione o se la "chiudo la finestra nella
barra" e poi la riapro, devo magari clicckare tre o quattro o più volte prima
che si apra di nuovo la finestra.
Insomma un rallentamento notevole dell'app... premesso il mio I7-4770K...

---cut---
Private Sub *****Port1_DataReceived(sender As Object, e As
IO.Ports.*****DataReceivedEventArgs) Handles *****Port1.DataReceived

inputData = *****Port1.ReadExisting

' provati anche *****Port1.ReadExisting o *****Port1.ReadLine

Application.DoEvents()
Me.Invoke(New EventHandler(AddressOf rxCOMdati))
Application.DoEvents()
End Sub
---cut---
Ho provato anche a mettere qualche doevents... malgrado migliora un pochetto è
sempre rallentato..., servono a poco...
Anche ad usare simil questo...

'per leggere linea per linea ad ogni ;
Dim Termine*****e As String = ";"
*****Port1.NewLine = Termine*****e
inputData = *****Port1.ReadLine + ";" + vbCrLf

funziona sempre bene ma stesso rallentamento a spostare o chiudere/aprire la
finestra.

Nella "rxCOMdati"

Public Sub rxCOMdati() ' scrive la ricezione della COM
s = inputData
inputData = ""

poi lavoro "S" in un paio di split.... ma anche mettendo subito un exit sub...
dopo il inputdata ="" e un S="" stessa cosa...

Qualche consiglio su come sfruttare al meglio il continuo flusso dati in
entrata?

GRAZIE 1000!
ApipApip 27 Mar 2015 21:29
ri-ciao....
niente da fare, ho provato un po' di tutto in questi 10 giorni ma niente...

questo codice che legge la *****e

---cut---
Private Sub *****Port1_DataReceived(sender As Object, e As
IO.Ports.*****DataReceivedEventArgs) Handles *****Port1.DataReceived

inputData = *****Port1.ReadExisting

' provati anche *****Port1.ReadExisting o *****Port1.ReadLine

Application.DoEvents()
Me.Invoke(New EventHandler(AddressOf rxCOMdati))
Application.DoEvents()
End Sub
---cut---

mi crea un rallentamento all'apertura della COM nell'app (solo per quell'app)
solo quando apro la com anche senza la presenza di dati in arrivo, con
l'interfaccia RS232 spenta!! e senza dati...

Spero qualcuno riesca ad aiutarmi... non riesco a capire come fare... :-)
ciao e GRAZIE
Anto
Franz_aRTiglio 29 Mar 2015 21:40
ApipApip ha spiegato il 19/03/2015 :

> poi lavoro "S" in un paio di split.... ma anche mettendo subito un exit
> sub... dopo il inputdata ="" e un S="" stessa cosa...
> Qualche consiglio su come sfruttare al meglio il continuo flusso dati in
> entrata?

Son stato zitto fin'ora perchè non esperto del mondo .net, ma da semi
esperto in vb6 e porte com, credo di aver capito il tuo problema,
quindi
ti dò la mia opinione nello specifico:

Usando l'evento OnComm (in vb6 scatta ad ogni dato ricevuto dalla porta
com), il programma si "ancora" alla porta com, che avendo una velocità
(molto) limitata costringe la routine ad attendere il completamento
della ricezione dei dati; considerando che l'unico modo di capire che
il flusso dati è terminato e' il fatto che nessun dato stia arrivando
prima di un timeout.

Ora, il metodo OnComm e' una scelta intelligente quando

- la quantità di dati in arrivo è conosciuta a priori (e.g. sempre e
solo X byte in entrata)
- non è prevedibile il tempo in cui tali dati arrivano (e.g. i dati non
arrivano da un sollecito ma sono l'iniziativa del trasmittente)
- l'ammontare dei dati in arrivo è piccola (10-15 byte)
- l'arrivo di dati deve sollecitare una tempestiva risposta

Se invece si ha una condizione di uso diversa, nella quale ad esempio
si vuole ricevere una quantità di dati importante è meglio operare come
segue:

-----> NON si usa nessun evento OnComm <----

Usando un timer, si controlla la quantità di dati presente nel buffer
di
ricezione; se questi dati raggiungono 2/3 del buffer si procede a
scaricarli/aggiungerli in una variabile; si svuota il buffer (che ha
capacità limitata) e si prosegue fino a quando i dati ricevuti non sono
soddisfacenti.

In questo modo non si richia che il programma rimanga ancorato
all'evento "storicevendodati".
ApipApip 30 Mar 2015 21:05
Ciao Franz_aRTiglio

Grazie mille per l'intervento...

> Son stato zitto fin'ora perchè non esperto del mondo .net, ma da semi
> esperto in vb6 e porte com, credo di aver capito il tuo problema,
> quindi
> ti dò la mia opinione nello specifico:

Ci mancherebbe dato che io sono na mazza da tempo, anche io proveniente da VB6
che per forza di cose ho dovuto abbandonare per l'uso di WIN7 e WIN8/8.1.
Mi trovo piuttosto bene nell'ambiente .net rispetto al VB6... coi problemi che
devo rifare tutto quello che prima funzionava tranquillamente sotto VB6 ma non
più sui nuovi OS.



> Se invece si ha una condizione di uso diversa, nella quale ad esempio
> si vuole ricevere una quantità di dati importante è meglio operare come
> segue:
>
> -----> NON si usa nessun evento OnComm <----
>
> Usando un timer, si controlla la quantità di dati presente nel buffer
> di
> ricezione; se questi dati raggiungono 2/3 del buffer si procede a
> scaricarli/aggiungerli in una variabile; si svuota il buffer (che ha
> capacità limitata) e si prosegue fino a quando i dati ricevuti non sono
> soddisfacenti.
>
> In questo modo non si richia che il programma rimanga ancorato
> all'evento "storicevendodati".

Il codice che ho riportato sopra è esattamente quello che uso... e incriminato
da rallentamenti all'APP e che evidentemente non so cambiare.

Anche con la SOLA porta COM aperta e senza ricevere nessun dato (*****ware
spento) se apro la COM ho lo stesso rallentamento... anche se non si ricevono
dati, è proprio l'evento che scatena il rallentamento tutto, solo l'app non il
PC, nell'aprirla, nel chiuderla, nello spostarla ecc...)

Come lo si potrebbe modificare? Purtroppo da solo non ci arrivo... ho seguito
qualche esempio trovato in rete ma per capire dovrei partire dal basso con un
esempio semplice da poi ampliare.

Grazie per i tuoi preziosi consigli, se poi aggiungi qualche altro consiglio
pratico, GRAZIE MILLE!
Franz_aRTiglio 30 Mar 2015 21:16
Scriveva ApipApip lunedì, 30/03/2015:

> Come lo si potrebbe modificare? Purtroppo da solo non ci arrivo... ho seguito
> qualche esempio trovato in rete ma per capire dovrei partire dal basso con un
> esempio semplice da poi ampliare.

Come ho già detto non sono pratico di .net ma visto che (sempre se non
ricordo male) i controlli sono sempre form-dipendenti, ti dico:

Se il controllo che gestisce la COM e'/dipende dal form principale è
possibile che questo sia la causa del rallentamento; prova a metterlo
in un form secondario ******* e verifica se questo "libera" il
principale;
se l'accrocchio funziona ti basterà creare un modulo/form dedicato
alla *****e e poi nasconderlo per aggirare il problema del
rallentamento...

Links
Giochi online
Dizionario sinonimi
Leggi e codici
Ricette
Testi
Webmatica
Hosting gratis
   
 

Il linguaggio Visual Basic di Microsoft | Tutti i gruppi | it.comp.lang.visual-basic | Notizie e discussioni visual basic | Visual basic Mobile | Servizio di consultazione news.