data logging ELM327

Ca fait un petit moment que je me demande aussi comment permettre d'avoir plusieurs présentations des mêmes données.

On peut, par exemple, avoir un seul mainform qui aurait des contrôles dont certains seraient visibles avec des cadrans ronds, et d'autres dans le cas de bargraph. ou encore redimensionnés avec soit une taille zéro soit une qui les rend visibles ?
Certains autres contrôles pourraient être communs, en les déplaçant simplement.

Dans l'exemple que j'ai publié ci-dessus il n'y a que 2 picturebox pour les bitmap. Tout est fait avec des label, y compris les traits fins, les histogrammes, les bargraph... Il y a par contre depuis le début aussi des images, timer et Mscom.

A+ ;-)
 
Une solution , lourde en code, probablement pas en temps machine, mais que j'hésite à employer, serait de cacher tout ce qui est présent sur la MainForm, élément par élément , et de le remplacer par une autre série de labels et picturebox.
C'est un des points que je n'ai pas résolu pour le TripMaster, qui par ailleurs est en bonne voie de codage.
 
@planétaire :
tes regroupements sont bien.
il est trés simple d'utiliser la propriété visible(true/false) pour conditionner la visibilité de n'importe quel composant sur une Form. de même on peut en gérer la position.
@mik&toy :
ne cherche pas de complications :
la technique expliquée par planétaire (et répétée ci-dessus) est idéale car facile à comprendre et à mettre en oeuvre.
 
Je cherche à sonoriser le programme, mais ce que j'ai trouvé ci-dessous, met à mal le CPU en le confisquant pour plusieurs secondes.
Y a t-il moyen de faire mieux en VB6 ?
Code: 
' PlaySound API : 
Private Declare Function PlaySound Lib "winmm.dll" Alias "PlaySoundA" (ByVal lpszName As String, ByVal hModule As Long, ByVal dwFlags As Long) As Long
Dim returnval As Long
Dim soundfile As String

Code: 
Call SoundThrottle
Code: 
Sub SoundThrottle() 
    If Sgl_348_ThrottleICE_rpm <> Old_ThrottleICE Then
        Old_ThrottleICE = Sgl_348_ThrottleICE_rpm
        If Sgl_348_ThrottleICE_rpm = 0 Then
            soundfile = "D:\DATA\Waves\suppr.wav"
            returnval = PlaySound("SystemStart", 0, &H0)
        ElseIf Old_ThrottleICE = 0 Then
            soundfile = "D:\DATA\Waves\insert.wav"
            returnval = PlaySound("SystemStart", 0, &H0)
        End If
    End If
End Sub
 
J'aimerais pouvoir expedier , en simulation, des séquences de code comme je l'ai fait avec le programme GraphCan en C , de ce genre :
Code: 
        sequence = "t03A701020304050607\nt3C850102001F05\nt03B502E400BFE5\nt3CA5004D210040\nt0B48010203040520CC08\nt12080000000010130450\nt3486010227100506\nt3CB76664007E131141\nt3CD5000000BE93\nt52C2238A\nt57F768301000000000\nt5A426323\nt5296A70000854000\nt5B6364C100\n"

Call ParseCANMessage(sequence)
Mais je n'ai pas trouvé la présentation qui convient pour le mettre en entrée de la routine ParseCAN.
Avez-vous déjà envisagé cette possibilité de valider le CanMonitor par le biais de la simulation de reception des Pids ?
 
la simulation est trés simple à gérer :
il faut et il suffit :

  1. "dumper" dans un fichier de log le contenu du buffer de lecture , avec éventuellement un "timestamp" ce qu'avait fait planétaire dans un de ses développements.
  2. en mode simulation, relire ce fichier au lieu d'écouter le port série.
 
Pour le log ça existe déjà:
En se rappelant que quand on a activé le paramètre "SuperLogfile=True" dans le .INI le dump est stocké pendant la conduite dans le fichier *.txt avec juste insertion de temps en temps d'une ligne de time stamp.

Il y a juste quelques lignes de codes à pondre.
Comme le dit Priusfan, on injecte ce fichier au lieu du port com.

On peut le rejouer ensuite avec une temporisation, sinon ça doit être en accéléré.

A+ ;-)
 
Merci, j'avais pas regardé ce que sortait le mode superLog.
Pour le réinjecter, vous faites "Call ParseCANMessage(sequence)" ou autre chose ?

Et pour la sono, vous n'auriez pas qqch d'aussi simple ?
 
Je n'ai jamais approfondi le pourquoi de la gestion de la variable S1.
Elle est déclarée au niveau general ET elle est passée comme paramètre à ParseCanMessage(S1) ? Gloups pas logique !

En tout cas actuellement ça fonctione ainsi:
Code: 
S1 = le contenu à décoder
Call ParseCanMonitor(S1)
S1 = ""

Pour le son je ne sais.

A+ ;-)
 
Mik&Toy à dit:
Merci, j'avais pas regardé ce que sortait le mode superLog.
Pour le réinjecter, vous faites "Call ParseCANMessage(sequence)" ou autre chose ?

Et pour la sono, vous n'auriez pas qqch d'aussi simple ?
Cliquez pour agrandir...

pour la simu:
le travail de décodage du fichier brut est inutile.
il est souhaitable de simplement relire ton fichier déjà formaté dans lequel toutes les variables pertinentes sont présentes.
envoie moi un exemplaire de ce fichier, je te ferai un module de lecture "intelligente" avec possibilité de lecture en accéléré.
dans ton dev : tu utilises AMHA beaucoup trop de timers.
par ailleurs réinventer un gestionnaire de GPS est beaucoup trop pénalisant , cela charge considérablement le CPU que de traiter une grande image; par ailleurs l'écran se prête mal à la gestion de multiples fenêtres.
ou alors, le mode simu doit être réservé pour être utilisé sur une machine fixe avec grand écran.
pour le son , il faut utiliser un autre thread, peut-être en appelant un programme externe ; le pb dans ce cas est de lui passer en parm le nom du fichier à jouer. le + simple serait d'écrire dans un fichier type ini le nom du fichier à jouer; le pgm appelé commencerait par lire ce fichier ini pour savoir ce qu'il doit faire.
 
Oui, il y a deux timers de trop, l'un pour limiter le nombre de lignes, à supprimer vu que le test existe dèjà par ailleurs. l'autre, c'est juste pour séquencer une simulation, de manière non synchrone avec le timer1, et je l'enlèverai dans la version opérationnelle.

J'ai mis en ligne les logs effectués durant le RMCVEA .

Le fichier brut me plairait quand même, en plus, pour envoyer des rafales à 100 Hz, histoire de tester les saturations.

et la carto GPS, c'est pour voir jusqu'où on peut charger la mule.

Quant à la sono, il faudrait trouver un truc très léger en temps de lecture, avec bufferisation du son comme une image dans un picturebox, mais sans "activeFlash" !
 
pour jouer du son , voir ici:
http://www.ex-designz.net/apidetail.asp?api_id=513

tu as la possibilité de lancer un son sans bloquer ton programme.
Code: 
[COLOR=#353535][FONT=verdana]SND_ASYNC
The sound is played asynchronously and PlaySound returns immediately after beginning the sound. To terminate an asynchronously played waveform sound, call PlaySound with pszSound set to NULL.[/FONT][/COLOR]
 
Quelle précision.

-Petite évaluation de la précision des mesures.
Sur mon dernier plein:
Selon la Prius 1108 km et selon la pompe 44,5 litres
Selon mon Pc 1106,8 km et 44 litres (en fait 1106,798 et 43,955)

Soit 0,1 % de différence sur la distance
et 1,1 % sur le carburant. C'est plus précis qu'au précédent plein car les pompes au début de ces 1108 km et à la fin avaient le même comportement.

-Dans PriusCanMonitor il y a maintenant, à chaque démarrage, les infos suivantes sur le plein en cours:
-vitesse moyenne km/h
-litres/100km
-distance en mètres
-consommation en millilitres
plus l'affichage de l'histogramme des consos par minute.

A+ ;-)
 
Lorsque l'on est dans une fourchette, on tombe parfois pile poil mais parfois on est complètement à côté. J'ai un beau contre-exemple avec ma performance de consommation au dernier rallye RMCVEA : je n'avais jamais si peu consommé sur un plein !

On connaît à peu près la précision "plein" et celle de l'ODB. Déterminer celle de ton programme demandera beaucoup de mesures cumulatives et comparatives avec d'autres styles de conduite que la tienne. Tes résultats sont néanmoins très encourageants.

Une manière de vérifier est de relever la consommation donnée par l'ODB au fil du plein (tous les 50 km par exemple) et de comparer avec tes chiffres. Cela ne fonctionne pas bien si tu oscilles entre 4,0l et 4,1 l /100 km sur la totalité du plein mais si les écarts varient entre 4 et 5l, on a une indication. Les points "frontières" (changements de valeurs) sont "plus précis" mais ils sont plus difficiles à relever.
 
1)
Pour ce plein l'Odb venait de passer à 3,9 l/100 depuis environ 50 kilomètres, pour un 4 l/100 à la pompe. Soit 43,2 litres d'après l'odb au lieu de 44,5 à la pompe et 44 selon le Pc.
Mais tu as sûrement raison, la manière de conduire peut changer l'écart Odb-Pc dont le nombre de démarrages à froid, la durée de chaque période de fonctionnement du thermique (erreur d'arrondi pour l'odb?), incertitude sur la consommation lors des arrêts du thermique pour le Pc...

J'ai plutôt l'impression que l'imprécision vient surtout de la différence de remplissage entre la pompe au début du plein et celle à la fin.
Ce que je constate est que si on tourne la poignée du pistolet vers l'arrière on peut remplir d'une traite jusqu'au déclenchement. On attend un peu puis on rentre un litre assez facilement. Ensuite c'est très lent et là ça dépend de la pente du sol et de notre patience. C'est ce que je reproduit maintenant systématiquement.
Il y a donc deux seuils reproductibles : déclenchement ET le litre suivant.
A mon avis si on peut reproduire ces 2 seuils, la précision du plein est "bonne".

2)
Ci dessous ébauche de projet de CanMonitor avec cadrans:
167149f59586de65c.jpg


Petit cadran les ampères, dans le cadran les ampères en chiffres et le Soc en %
Grand cadran les tr/mn avec sa valeur numérique, les l/100 "instantanés", et la température du thermique.
Pourquoi cette forme ? C'est pour avoir les valeurs intéressantes vers le haut: pas d'ampères et tours/mn vers 1700.

A améliorer: ajouter des précisions sur certains chiffres... ajouter des bargraph pour le soc, température thermique...

Ce programme fonctionne (en mode simulation et un bref essai pour l'instant)

3) A Priusfan & Mik&Toy: je ne vois pas à quoi sert le bouton démarrer. Si vous ne l'utilisez pas il saute.

A+ ;-)
 
Ce qui ressort peut-être peu de mon précédent message, c'est :

- il est très intéressant d'avoir la capacité de connaître avec un bon niveau de précision la consommation instantannée et surtout de pouvoir la capturer

- ton programme semble fournir cet outil avec une précision du même ordre que celles des autres moyens de mesure à notre disposition
 
@planétaire:
le bouton démarrer , dans le projet original, marche en bascule avec un bouton stop.
le rôle de ces boutons est de démarrer / arrêter la capture.
en effet leur utilité n'est pas évidente.
quelle technique as tu utilisé pour tes compteurs ? des lignes dans un picturebox ?
 
Technique: un objet "line" pour l'aiguille sur un objet "image". Vue la forme imbriquée des 2 cadrans j'ai fait qu'une seule image. Mais si nécessaire il doit être possible de le faire avec 3 plus petites.
Je ne sais pas comment VB réalise la gestion de la line & du bitmap: Est-ce qu'il assure le réaffichage du rectangle minimal (qui "contient" la line) quand la line s'en va ? ou bien est-ce qu'il réaffiche tout le bitmap ?

La line fait 4 de largeur c'est ... simple.
Le Bitmap est stocké dans l'exe et lui augmente fortement la taille.
Peut-être pas la suite le charger à l'exécution, permettant de + d'avoir différentes versions ? Loupe d'orme...

Je vais voir les impressions en conduisant avant d'améliorer le look.
Déjà le démarrage du thermique "balance" l'aiguille des ampères dans le négatif: c'est plus visuel que des bargraph ou chiffres.

(Les Picturebox me posent problème, pas moyen de mettre qq chose dessus. Je les ai retirés, même dans la version avec 5 bargraph qui en avait 2. Des "image" conviennent très bien on peut mettre dessus une ligne, des label.. en décidant ce qui est au-dessus)

Oui, le bouton démarrer bascule avec un autre arrêt. Seulement à l'arrêt, car manier le mulot en roulant serait de la folie. Actuellement je ne m'en sert pas, si j'ai à marquer un point j'arrête et redémarre le prog !!

A+ ;-)
 
« … Les Picturebox me posent problème, pas moyen de mettre qq chose dessus … »
Si, ça marche si tu crée les labels dessus après l'avoir sélectionné. Mais on ne peux pas faire venir les labels du MainForm en les traînant avec la souris. par contre le couper/coller fonctionne, toujours avec présélection du picture box avant de coller.

Tes cadrans , y z ont de la gueule ça va faire la pige à l'Insight !
Les aiguilles , c'est toujours plus précis parce qu'on à affaire à un angle, et qu'il n'y a pas besoin de point de repère pour l'estimer (on est pas dans avion de voltige)
 
Le retour du cadran rond.

J'ai un peu roulé avec.
Ca change les habitudes. Et oui, après quelques milliers de km !
Je vais approfondir la chose. Ca en vaut le coup.
Des remarques:
-Il y a parfois des déchirements d'image, plutôt au niveau des labels (qui affichent les chiffres).
Il faut optimiser un peu l'affichage, par exemple ne réafficher que quand ça change.
De toute façon il reste le mode Xor pour les aiguilles qui normalement évite tout réaffichage du bitmap.
-Pour les ampères il faut faire une échelle exponentielle comme pour les bargraph.
-Les cadrans sont jolis mais il faudra que j'améliore la définition de cette image, je suis parti d'un cadran existant et ai zoomé + coupé pour faire les 2 cadrans.

@Mik&Toy, au sujet des picturebox tu as sûrement raison, je les déplaçais avec le mulot sur le picturebox au lieu de copier/coller. Enfin comme je n'en ai pas vraiment besoin. D'ailleurs qu'est-ce qu'ils apportent de plus que l'objet image pour faire un cadran + une aiguille ?

Mon impression est que les cadrans permettent de mieux séparer les groupes d'infos : ici batterie et thermique. Et en plus le centre est disponible pour des chiffres.

Pour le bouton démarrer. Vous vous en servez ?

A+ ;-)
 
Les picturebox sont beaucoup plus sympa - pas de déchirement - plus rapides - et en plus on peut les imbriquer, genre un grand, plus grand que l'écran, dans un petit, et on peu trimbaler l'image dedans, pour une carte par ex.
ils peuvent aussi disparaitre facilement avec tout ce qu'ils contiennent (juste un seul xxx.visible = false) et donc être permutés entre-eux au même endroit

Le bouton démarrer, c'est si on doit changer de n° de port com au setup. après il faut relancer, il me semble.
 
à titre d'exemple de module à ajouter au CanMonitor, un module d'affichage du courant batterie, avec un échelle semi-log (loupe de -15 à + 15 A)

Code: 
' *** AMPEREMETRE
'""""""""""""""""""""""""""""
Dim Ampere_actif As Boolean

 dans MainForm-Load()

    ' positionne et désactive par défaut le cadran amperemètre
        Ampere_actif = False
        AmpereBox.Visible = False
        AmpereBox.Top = 1600
        AmpereBox.Left = 6000
pour l'appeler et l'activer, à partir d'un bouton "Label = AciveAmpere"
Code: 
Private Sub ActiveAmpere_click()
    If (Ampere_actif = False) Then
        Ampere_actif = True
        AmpereBox.Visible = True
    Else
        Ampere_actif = False
        AmpereBox.Visible = False
    End If
End Sub
et pour l'afficher dans un "PictureBox = AmpereBox" contenant pour aiguille une "Line = ziguy_Amp"
Code: 
Public Sub Cps10_AmpereDisp()
Dim angular As Integer
Dim gradu As Double

       If (Cdn_03B_BattCurrent_dAmp < 0) Then
                ziguy_Amp.BorderColor = &H80FF&
            If (Cdn_03B_BattCurrent_dAmp < -1200) Then
                    angular = 0
            Else
                If (Cdn_03B_BattCurrent_dAmp < -150) Then
                    angular = 50 - Fix((-Cdn_03B_BattCurrent_dAmp - 100) / 20) ' scale for 1050 dA
                Else
                    angular = 100 - Fix((-Cdn_03B_BattCurrent_dAmp) / 3)       ' scale 15 for 150 dA
                End If
            End If
        Else ' (Cdn_03B_BattCurrent_dAmp >= 0)
                ziguy_Amp.BorderColor = &HFF00&
            If (Cdn_03B_BattCurrent_dAmp > 1200) Then
                    angular = 200 ' center zero amp position
            Else
                If (Cdn_03B_BattCurrent_dAmp > 150) Then
                    angular = 150 + Fix((Cdn_03B_BattCurrent_dAmp - 100) / 20) ' scale for 1050 dA
                Else
                    angular = 100 + Fix((Cdn_03B_BattCurrent_dAmp) / 3)        ' scale for 150 dA
                End If
            End If
        End If
        
   '    ziguy_amp.X1 = 1680
   '    ziguy_amp.Y2 = 1680 ' rayon = 1680 - 240 = 1440
   ' angle en radian (conversion de 360 degre en 2.pi radian)
        gradu = (angular + 80) * 3.141592 / 180
        ziguy_Amp.X2 = 1680 - 1440 * Sin(gradu)
        ziguy_Amp.Y2 = 1680 + 1440 * Cos(gradu)
        
End Sub

.... succeptible d'être amélioré en vitesse en utilisant un algoritme simplifié à la place des Sin et Cos (à voir ?)
 
Bonjour à tous !

Je suis de retour sur le forum, après de nombreux mois d'absences dont la cause principale est un rythme infernal au boulot.

Toutefois, je ne vous ai pas oublié, loin de là, puisque j'utilise tous les jours le CanMonitor sur mon trajet maison - travail de 250 kms aller-retour, et je peux témoigner de sa fiabilité :cool:

Ce week-end, je suis revenu sur le forum et j'ai suivi avec intérêt les dernières conversations, notamment celles portant sur les affichages de graphiques. Je pense que la solution Flash (dont l'initiateur, je le rappelle, est Priusfan :jap:) n'est pas à écarter, au contraire. Car si les éléments sont un peu longs à créer, leur intégration dans VB est très simple (voir le post #113) et leur éxécution extrémement rapide.

Voici l'interface que j'utilise actuellement :

233249f572096df62.jpg


Les compteurs flash dont je dispose actuellement sont les suivants :
- compte-tours, avec indication au centre de la température moteur
- vitesse : il est un peu saccadé, car le code sur lequel il est basé n'est rafraîchi que toutes les secondes
- altimètre : celui-ci peut paraître surprenant, mais je suis aussi pilote à mes heures perdues... Et je le trouve néanmoins utile pour expliquer la consommation de la Prius.
- batterie : celui-ci combine l'état de charge de la batterie, sa température, sa tension, et les courants entrant et sortant avec échelle logarithmique.

L'histogramme présenté un peu plus haut serait très facile à recréer en flash, et je veux bien le faire (le mois de Mai s'annonce plus calme niveau boulot). Par contre, j'utilise une version ancienne de Prius Monitor (fin décembre) qui n'inclue pas les dernières trouvailles en terme de codes et de logique de déchiffrage. Y-a t'il quelque part une version consolidée avec les derniers codes ? Si oui, je pourrais y intégrer les compteurs flash que j'ai créés.

Je peux aussi fournir les compteurs individuels et le code nécessaire pour leur intégration.

Prius_Pilot
 
Bonjour, Prius_Pilot !
Je me demandais ce que tu étais devenu.
Quelles sont les conclusions que tu as pû tirer de tous tes trajets avec le prog.?

De mon côté j'ai essayé et apprécié les cadrans ronds avec aiguilles.
Je viens d'actualiser mon message pour éviter de stocker des copies d'écrans intermédiaires.
J'ai voulu voir si on pouvait se passer de flash car il demande un peu plus d'effort pour installer priusCanMonitor (qui réclame déjà d'installer dans la base de régistre le comm_machin.dll ce qui peut gêner des non-informaticiens).
A priori on peut faire quelque chose de correct sans flash, avec des temps de réponses valables. Mais, sûr, avec flash ça peut être + joli et il n'y a pas les mêmes limitations.

J'ai aussi gardé l'altitude car elle est utile dans les glide pour savoir si on est sur un vrai ou faux-plat (pas évident à l'oeil)

Mais je n'utilise pas une version "consolidée". Je peux te communiquer le dernier code sur lequel je travaille (*). Dans cette version je prévois de gérer un historique des trajets précédents plus important (provisoirement limité aux 30 derniers trajets)

Il faut voir aussi ce qu'a fait Mik&Toy.

Pour cela en MP communique-moi ton email.

A+ ;-)
 
re-bonjour, Prius-pilot,
Moi aussi j'attendais de tes nouvelles.

Par exemple pour nous dire tout sur le Flash, comme combien ça met de temps comparé au cadran rond en "picturebox" avec aiguille en "line".
Et aussi si l'utiisation de trigo sin-cos en flottant plombait le calcul.

Et si tu pouvais aller jusqu'à un variomètre d'altitude qui tremblote pas en permanence. moi, j'essaie de faire parler les capteurs accéléromètres, pas évident.

Je peux également te transmettre quelques modules d'affichage en "line" et en "shape", que tu pourrais nous traduire en Flash, si t'as le temps.

PS: @ tous: quelle est la précision max récupérable du GPS sur les lat et lon du flow NMEA : 6 chiffres décimaux sous le degré, ou meilleur que ça ?
 
Identifiez-vous ou inscrivez-vous pour participer.
Pages vues depuis le 20 Oct 2005: 314,215,049
Retour
Haut Bas