Discussion :

[abdobergach]

bonjour
j'ai créé une fonction CBstatus() en VB.net et un timer qui fais l'appel à cette fonction chaque 10 ms
cette fonction permet de recupérer des donné sur un bus CAN ,donc s'il ya pas donné elle présente un erreur que je dois l’afficher une seul fois ,c'est pour cela j'ai mé une condition if pour afficher ce meessage une seul fois mais malheuresemnt ca marche pas tjr il me donne des fenêtre d'erreur suivant le timer
voila le code et merci pour une idée

Code Visual Basic :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
dim i as integer =0
 Private Sub Timer1_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Timer1.Tick
 
 
try 
CBstatus()
Catch ex As Exception
 
 if i=0 then
    msgbox(" pas de donné sur le bus CAN")
    i=1
end if
End Try
End Sub

[Pol63]

à tout hasard met i à 1 avant le msgbox, des fois qu'il soit bloquant (mais je ne pense pas)

sinon est-ce un timer trouvé dans la boite à outils ou un timer autre (et donc pas system.windows.forms.timer)

par contre en général pour des choses où l'état de connexion peut changer dans le temps je pense qu'il est préférable de l'afficher visuellement sur le form (rond vert/rouge par exemple ou encore label visible/invisible)

[Ehjoe]

bonjour
j'ai créé une fonction CBstatus() en VB.net et un timer qui fais l'appel à cette fonction chaque 10 ms
cette fonction permet de recupérer des donné sur un bus CAN ,donc s'il ya pas donné elle présente un erreur que je dois l’afficher une seul fois ,c'est pour cela j'ai mé une condition if pour afficher ce meessage une seul fois mais malheuresemnt ca marche pas tjr il me donne des fenêtre d'erreur suivant le timer
voila le code et merci pour une idée

Code Visual Basic :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
dim i as integer =0
 Private Sub Timer1_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Timer1.Tick
 try 
  CBstatus()
  Catch ex As Exception
   if i=0 then
     msgbox(" pas de donné sur le bus CAN")
     i=1
   end if
 End Try
End Sub

Bonjour,

A priori ça semble tourner rond ... question subsidiaire, le i ne serait pas modifié ailleurs ?

Peux-tu essayer d'englober le try par un if ou un select case (sur i) ?

Sinon, le timer à 10 ms, moi en vb6 j'avais testé, et en dessous de 50 ms ce n'est pas significatif, il n'a pas le temps de faire son travail (lire le code, empiler, passer au processeur, exécuter, puis le retour), plus l'état du processeur selon les tâches de fond de l'OS (qui tourne toutes seules comme des grandes), je doute qu'en 10 ms il fasse ça, donc... il y a peut être une sorte de bourrage qui se crée et sature la fonction, j'ai déjà vu ça, alors sans aller jusqu'à planter il prend du retard et débloque un peu ?

Moi je mettrais le timer à 50 ms et je le soulagerais avec devant le try un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

My.Application.DoEvents()

[Pol63]

Sinon, le timer à 10 ms, moi en vb6 j'avais testé, et en dessous de 50 ms ce n'est pas significatif, il n'a pas le temps de faire son travail (lire le code, empiler, passer au processeur, exécuter, puis le retour), plus l'état du processeur selon les tâches de fond de l'OS (qui tourne toutes seules comme des grandes), je doute qu'en 10 ms il fasse ça, donc... il y a peut être une sorte de bourrage qui se crée et sature la fonction, j'ai déjà vu ça, alors sans aller jusqu'à planter il prend du retard et débloque un peu ?

c'est vrai qu'il n'y aucune différence entre vb6 et vb.net et que les pcs n'ont pas évolué depuis 15 ans

[DonQuiche]

Aucun rapport avec VB6 et VB.Net ou l'évolution des machines.

Les timers de base de VB6 comme de DotNet, DateTime.Now, Thread.Sleep, les WaitEventHandle et leurs frangins non-managés, etc... reposent tous au moins indirectement sur des messages WM_TIMER, des messages Win32 traités avec une basse priorité. Tous les timers basés sur ce mécanisme ont une résolution grossière (15.6ms -> 64Hz).

Si on veut dépasser le problème, deux solutions :
* On peut améliorer la résolution de WM_TIMER avec timeBeginPeriod, jusqu'à 1ms je crois. Mais le thread peut néanmoins dormir quand le tic débarque, auquel cas il ne sera traité qu'au réveil, voir ci-dessous.
* On peut utiliser QueryPerformanceCounter via StopWatch (précision de l'ordre de la microseconde) pour obtenir des mesures temporelles précises avec un thread tournant en continu sans jamais dormir. Problème : même avec la plus haute priorité, je crois que Windows peut mettre un thread en pause jusqu'à plusieurs dizaines de millisecondes pour permettre le traitement des autres threads.
* Enfin, on peut aller lorgner vers les solutions temps réel : créer un thread système (PsCreateSystemThread) et l'associer à certaines interruptions système pour forcer Windows à réveiller le thread à chaque tic. On atteint là une résolution de l'ordre d'une centaine de microsecondes il me semble. Il existe des biblios (Real Time Module) pour simplifier ça et portables entre OS.

[Ehjoe]

Aucun rapport avec VB6 et VB.Net ou l'évolution des machines.

Les timers de base de VB6 comme de DotNet, DateTime.Now, etc... reposent tous au moins indirectement sur des messages WM_TIMER, des messages Win32 traités avec une basse priorité. Tous les timers basés sur ce mécanisme one une résolution grossière (15.6ms -> 64Hz).

Pour avoir des mesures temporelles précises il faut passer par QueryPerformanceCounter. C'est ce que fait Stopwatch, introduit dans la version 2.0 de dotnet. Cela dit, ici, je ne sais pas trop quoi faire, je ne sais pas s'il existe un timer capable de réveiller un thread avec de courts intervalles entre deux réveils..

EDIT : dernier paragraphe supprimé, j'ai écrit une bourde, afk google.

Bonsoir Donquich,

Sais-tu ce que fais ce code ? Il doit être lu, puis effectuer les tests, puis empiler les adresses, puis passer au processeur, exécuter l'ordre (qui pend aussi du temps), puis revenir, plus le temps où le processeur est occupé par des taches de fond, puis retourner le pointeur d'où il est parti en dépilant, tant est qu'il ne faille pas un accès disque (env 10 ms), et tu crois que ceci se fait en 10 ms ?

Ben moi je n'ai jamais rien eu de significatif en dessous de 50 ms, mais je dirais plutôt 100 à 200, car il n'y a pas que la mémoire là, il y a le code à lire, à exécuter, des accès disque parfois, ça prend tu temps tout ça !

Rien qu'un "IF" dans le code sur une séquence d'une minute, tu pourras voir la différence à l'oeil.

Aucun rapport avec VB6 et VB.Net ou l'évolution des machines.

Les timers de base de VB6 comme de DotNet, DateTime.Now, etc... reposent tous au moins indirectement sur des messages WM_TIMER, des messages Win32 traités avec une basse priorité. Tous les timers basés sur ce mécanisme one une résolution grossière (15.6ms -> 64Hz).

Pour avoir des mesures temporelles précises il faut passer par QueryPerformanceCounter. C'est ce que fait Stopwatch, introduit dans la version 2.0 de dotnet. Cela dit, ici, je ne sais pas trop quoi faire, je ne sais pas s'il existe un timer capable de réveiller un thread avec de courts intervalles entre deux réveils..

EDIT : dernier paragraphe supprimé, j'ai écrit une bourde, afk google.

Suite:

Tu peux déjà faire ça pour avoir une idée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
button1_click...
dim i as integer
dim t(2) as string
t(1001) = tempsMachien
for i = 1 to 1000
  t(i)=tempsMachine
next i
t(1001)=tempsMachine
 
' Puis tu fais 
msgbox ((t(1001) - t(0)) / 1000)
' et tu auras une idée à vide de la vitesse, mais à vide, si tu mets un peu 
' de code dans ta boucle c'est plus pareil.

Alors, tu trouves combien ?

[DonQuiche]

Bonsoir Ehjoe.

En fait, même si ton code d'exécutait instantanément, il pourrait quand même y avoir un problème avec Timer_Tick. C'est simplement que les tics sont programmés pour arriver toutes les 15,6 ms (même si tu as mis 10ms) et qu'il pourrait en fait s'écouler beaucoup plus de temps entre deux tics. Par exemple, si la machine est occupée, il pourrait se dérouler 50 ou 100ms. Ainsi, la séquence suivante poserait-elle un problème pour ton application (je considère que les tics arrivent toutes les 10ms même si c'est faux) ?
* 0ms : Timer1_Tick trouve desdonnées dans le bus -> traitement
* 10ms : aucune nouvelle donnée dans le bus mais le thread est endormi. -> pas d'erreur notifiée alors qu'il aurait fallu.
* 15ms : réception de données dans le bus.
* 35ms : le thread est réveillé et reçoit trois Timer1_Tick (10ms, 20ms, 30ms). Le premier découvre des données dans le bus -> traitement

Ensuite, si tu es certain que ton traitement prend plus de 10ms et que le cas normal et qu'il y ait des données à traiter, l'utilisation d'un timer n'est pas le choix le plus judicieux : sitôt un tic traité, tu vas recevoir tous les tics non-traités d'un coup. Au final, tu entasseras des tics en attente et je ne sais pas très bien sur quoi ça va déboucher (Windows croira t-il que l'application ne répond pas ?) Avec un traitement de 51ms et un thread mono-timer (windows forms par exemple), tu vas avoir la séquence suivante (je considère que les tics arrivent toutes les 10ms même si c'est faux).
* 0ms: Timer1_Tick commence
* 10ms: tic retardé, le thread est occupé, 1 tic en attente.
* 20ms: tic retardé, le thread est occupé, 2 tics en attente.
* 30ms: tic retardé, le thread est occupé, 3 tics en attente.
* 40ms: tic retardé, le thread est occupé, 4 tics en attente.
* 50ms: tic retardé, le thread est occupé, 5 tics en attente.
* 51ms: traitement terminé, début du traitement du tic notifié à t=10ms. 4 tics restant en attente.
* 60ms: tic retardé, le thread est occupé, 5 tics en attente.

Si tu utiliser un timer du type System.Threading.Timer, qui opère sur tous les threads du ThreadPool (16 par défaut), tu vas avoir cinq traitements en parallèle en moyenne, et jusqu'à 16 simultanément après un réveil du thread.

Du coup, il semblerait plus judicieux d'avoir recours au polling : un simple thread avec un code comme celui-ci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
bool error = false;
while(true)
{
   if (DonneesDansLeBus()) Traitement()
   else
   {
       error = true;
       break;
   }
}
 
if (error) msg("erreur");

Evidemment, si tu dois absolument signaler une erreur dans le cas où aucune donnée n'est présentée au bus dans un intervalle de dix secondes, ce code échouera lui aussi dans certains cas, s'il est endormi à ce moment. Il échouera aussi si ton traitement est finalement plus rapide que dix secondes, il faudra utiliser StopWatch pour vérifier le temps écoulé depuis le dernier relevé avant de signaler une erreur.

PS : La boucle de 1 à 1000 que tu proposes s'éxécuterait en à 1 à 10ns (nanoseconde, milliardième de seconde) si elle était vide et, comme je l'ai expliqué, le plus précis des timers n'a qu'une précision d'une micro-seconde, on ne peut donc pas mesurer une telle durée. Qui plus est, dans le boucle que tu proposais, c'est la lecture du temps machine qui prendrait du temps, et non l'itération/vérification de la boucle.

[Ehjoe]

c'est vrai qu'il n'y aucune différence entre vb6 et vb.net et que les pcs n'ont pas évolué depuis 15 ans

Bonjour le cerf,

Mais non, je parle de maintenant moi, mais tout le monde sait, s'il à l'habitude de VB, qu'on ne descend pas en dessous de 50 ms, et encore...