can_usb eeePC

[priusfan]

j'ai passé un bon moment à tenter l'adaptation de priuscanmonitor à l'interface canusb.

cela commence à balbutier pour le moment, mais je suis trés optimiste.

je continuerai ce dev avec mon ordinateur portable (qui était resté au bureau) ...
en effet je suis las de :
DO
modifier pgm sur une grosse bécane,
de transférer l'exe sur eeepc via clé usb
de tester le prog dans la watture
de rencontrer une erreur d'éxécution 5 ou 13 ...
de modifier
LOOP


au moins avec mon portable, je pourrai éxécuter en mode debug
l'interface canusb (par rapport à elm327) présente un grand avantage:
on peut solliciter un PID sans interrompre le polling.


ps @planétaire
te suggère de "marquer" tes timestamp de la manière suivante :
#16:52:37_19897156#
c'est beaucoup plus facile à isoler dans le flot...

ai vu que tu as mis des labels dynamiques,
tu as pu constaté que la gestion de:
position , taille , couleur , caption , visibilité sont beaucoup + souples...

@+

 

[planétaire]

Salut,

Cette résurection de canusb m'explique pourquoi la fonction Parse de PriusCanMonitor effectuait de bien étranges découpages de chaines de caractères à 2 temps. Il y a eu écriture d'abord pour canusb puis adaptation "rapide" pour elm327.
Comme tu l'as sans doute vu actuellement les octets des pid sont placés dans un tableau (comme dans canspy..). C'est + lisible.
Pour CanUsb il suffit peut-être
- de changer les séquences d'initialisation dans OpenCanPort et
- ce stockage en tableau dans ParseCanMessage

Je te joins par le même pigeon voyageur une version 519.
C'est suite à 1 demande faite par 1 utilisateur qui bénéficiera un temps de l'anonymat.
L'idée est d'agrandir la zone cadrans quand il n'y a plus qu'eux de visible.
Ca a été fait en gardant le bitmap actuel et en le zoomant à l'exécution.
Et donc ce qui était à craindre est une charge + forte de l'affichage qui doit recalculer le bitmap zoomé sans arrêt, je crains.
Sur mon Pc avec une dose d'optimisation c'est assez rapide "en mode simulation" (pas testé/route).
Mais sur eeePc c'est comment ?

L'avantage est d'avoir 1 seul bitmap et de zoomer à n'importe quel taux (2,3 sur mon Pc) mais si c'est trop lent il reste la solution de faire plusieurs bitmap sachant que le nombre de cas à prévoir est restreint.
Tonavis?
En tout cas le résultat est GEANT. Ca doit être lisible depuis la voiture de derrière.

Les labels dynamiques c'est excellents. Sûr qu'il y aura d'autres usages. Les graphiques dans l'histogramme n'en sont qu'à leur début !


Pour ce qui est des conditions de travail, ca me rappelle les débuts de la mise au point où je me garais au bord de la route puis modifiait le prog puis re-démarrage.. En fait c'est un gros gain de temps mais il faut admettre que la tablette et le Pc étant au milieu de la voiture, on est obligé de se tordre vers la droite et donc au bout d'un moment ça va plus.

A+

 

[priusfan]

...
Comme tu l'as sans doute vu actuellement les octets des pid sont placés dans un tableau (comme dans canspy..). C'est + lisible.
Pour CanUsb il suffit peut-être
- de changer les séquences d'initialisation dans OpenCanPort et
- ce stockage en tableau dans ParseCanMessage


A+

comme je l'ai sans doute vu
tu parles c'est moi qui avait créé canspy et j'apprécie cette modif.

pour ton approche avec canusb,
d'accord avec toi et c'est presque au point.
une particularité :
le séparateur avec canusb est vbcr et non vbcrlf
un truc trés sympa est le t en début de chaque trame
et également le nombre d'octets de datas

dans parsecanmessage, je suis en train de faire le ménage:
le test de numéricité est fait dans une boucle en tete
comme cela :
on fait le test une fois seulement et on ignore la trame si invalide.
on allège dans le pgm le traitement de chaque PID puisque la trame est considérée comme valide
extrait:

Deb = 1
    Fin = 1
    Dtstr = Dtstr & S1
    Do
        Deb = InStr(Fin, Dtstr, "t")
        If Deb = 0 Then
              Dtstr = Mid$(Dtstr, Fin)
            Exit Do
        End If
        Fin = InStr(Deb, Dtstr, vbCr)
        If Fin = 0 Then
            Dtstr = Mid$(Dtstr, Deb)
            Exit Do
        End If
        Print #2, "* " & Dtstr
        Trame = Mid$(Dtstr, Deb, Fin - Deb)    
        Print #2, "** " & Trame
       
        ' voila à quoi ressemble une trame (les espaces sont absents)   t038 7 C0 00 08 00 00 00 07
        ValidFrame = False
        PID = Mid$(Trame, 2, 3)                   ' c'est lui qui nous interesse
        dlc = CInt("&H" & Mid$(Trame, 5, 1))    'nb octets pour ce PID
        id = CInt("&H" & PID)
        If dlc > 0 And IsNumeric(id) = True Then
            ValidFrame = True
        End If
        For n = 1 To 8
            Can(n) = ""
        Next n
        For n = 1 To dlc
            Can(n) = Mid$(Trame, 4 + 2 * n, 2)
            ds = "&H" & Can(n)
            If IsNumeric(ds) = True Then
            Else
                ValidFrame = False
            End If
        Next n
        ' ne traite que trame valides
        If ValidFrame = True Then
            LastValidCANMsgTimer = Now

 

[planétaire]

Les mains dans le code.

comme je l'ai sans doute vu
tu parles c'est moi qui avait créé canspy et j'apprécie cette modif.
...[/CODE]

1) Le split ma mémoire se souvenait de l'auteur d'où les 2 points (ça c'est un truc de feignant les ..)
2) Le controle de numéricité en tête ça se discute:
-si tu teste tous les élements du tableau tu fais des tests inutiles donc perte de temps. Parce que non seulement tu décode des pid qu'on ne lit pas mais même ceux qu'on lit on ne prend jamais tout le contenu.
Mais quitte à le faire autant stocker le résultat sous forme numérique dans le tableau !
-si on ne teste pas au début mais au niveau de chaque pid, seuls les tests indispensables seront faits donc + rapide. L'exe sera un chouia + gros. Mais sa taille est surtout dictée par le bitmap.
-Peut-être même, n'ayant aucun espace, est-il possible de tester la numéricité en une seule fois... pour canusb.

Le code le + rapide n'est pas le mieux écrit.

A+

 

[priusfan]

Le code le + rapide n'est pas le mieux écrit.
d'accord, mais de mon coté , je préfère
un code lisible pour la maintenabilité
et élégant parceque j'aime bien ça
y aura plus qu'à mettre des tickcount pour vérifier impact...

 

[planétaire]

Le numero d'un controle ?

Ah il y a 3 petits points après l'impact. C'est du lourd.

Pas sûr que ce soit mesurable par tickcount ...

Bon à propos de code élégant je souhaiterais pouvoir obtenir le Numéro d'un contrôle d'après son nom.
En effet dans la fonction de zoom les left,top,width,height,font sont recalculés pour une vingtaine de contrôles. Là ça marche grâce à la puissance du copier-coller. Mais c'est bestial. Quel manque de panache.
Et dans l'avenir, chaque nouveau contrôle ajouté dans le picturebox des cadrans réclamera 5 lignes de code. La honte.

Donc avoir un tableau avec les 20 numéros de controle puis modifier les 5 propriétés de chaque dans 1 boucle. Absolument.

Y'a-t-il un truc ?

Ah j'oubliais il y a une 520.

 

[priusfan]

un peu de OO
pour les labels dans les histos:

tu joues avec une picture box

tu peux facilement en connaitre la taille (H, L) et la gérer (càd retailler et positionner en fonction de la réso écran et/ou de choix )

tu peux trés probablement (je dirais même plus, assez facilement *):
paramétrer largeur, hauteur et position de tes labels en fonction de la taille de la boite dans laquelle ils sont.
(et cela indépendamment de la réso écran).

* parce que finalement tu t'y connais un peu en calcul.


ps: s'il s'agit des cadrans, je n'ai pas encore regardé

 

[planétaire]

C'est pour les cadrans (qui sont dans 1 picturebox). Regarde si tu as du temps stp la fonction Redimcadrans, sinon c'est pas important ça marche très bien tel qu'écrit. Ca aurait juste été beaucoup + compact, et là comme on n'y passe presque jamais on peut faire dans l'élégance...

En fait j'avais suivi ton lien qui explique les load et unload et plus loin l'accès aux contrôles d'après leur numéro. Mais il me manque 1 info pour connaitre ce numéro.

@Ket il y a plusieurs zoom dans la v520, en tout 3 tailles de cadrans.
-Taille normale au démarrage du prog avec toutes les fenêtres
-Après un appui sur suppr effacement de l'histogramme
-Après un autre appui il ne reste que les cadrans et cumuls+moyennes, les cadrans sont + gros
-Après la 3ème frappe il n'y a plus que les cadrans et ils sont + gros encore
-Puis ça recommence.

A+

 

[priusfan]

canusb & eeePC

il est possible d'utiliser un eeePC série 700 avec le programme canmonitor et un interface canusb.

les photos ci-dessous ont été prises sur une machine de ce type
512 mo de ram
4 gigas de SSD
résolution écran : 800 * 480
windows XP SP2
pas d'antivirus
ça y est ça gazouille:


et en plus cela ne bouffe pas toutes les ressources sur une toute petite machine :


j'ai quand même un peu triché en mettant un "on error resume next"
dans parsecanmessage.

on fignolera quand il fera jour.

 

[priusfan]

ci-joint un comparatif des variantes dans les sources:

 

[priusfan]

voila à quoi pourrait ressembler le parsecanmessage banalisé:

    Dtstr = Dtstr & S1
    Do
        Select Case Interface
            Case "ELM327"
                Fin = InStr(Deb, Dtstr, vbCrLf)
            Case "CANUSB"
                Fin = InStr(Deb, Dtstr, vbCr & "t")
        End Select
        If Fin = 0 Then
            Dtstr = Mid$(Dtstr, Deb)
            Exit Do
        End If
        LePid = Mid$(Dtstr, Deb, Fin - Deb)    'Le Pid à analyser sans le CrLf exemple_de_syntaxe= "030 00 01 02 03"
        Deb = Fin + 2                          'Prochaine recherche après le Crlf
        ers = False
        Select Case Interface
            Case "ELM327"
                Can() = Split(LePid, " ", -1)
                dlc = UBound(Can())
                If dlc > 0 And IsNumeric("&H" & Left$(LePid, 3)) = True Then
                    id = CInt("&H" & Can(0))                        'Parce que le select case sera + rapide.
                    Else:
                    ers = True
                End If
            Case "CANUSB"
                Do While ers = False
                    If Len(LePid) < 7 Then  ' chaine trop courte , on l' ignore
                        ers = True
                        Exit Do
                    End If
                    For n = 1 To Len(LePid) ' chaine purement numérique ?
                        ds = "&H" & Mid$(LePid, 1, 1)
                        If IsNumeric(ds) = True Then
                        Else
                            ers = True
                            Exit Do
                        End If
                    Next n
                    id = CInt("&H" & Left$(LePid, 3))                  ' c'est lui qui nous interesse
                    dlc = CInt("&H" & Mid$(LePid, 4, 1))
                    If dlc = 0 Or dlc > 8 Then          ' dlc invalide : trop court ou trop long
                        ers = True
                        Exit Do
                    End If
                    If Len(LePid) <> 4 + 2 * dlc Then   ' chaine mal formée
                        ers = True
                        Exit Do
                    End If
                    For n = 1 To 8
                        Can(n) = ""
                    Next n
                    For n = 1 To dlc
                        Can(n) = Mid$(Trame, 3 + 2 * n, 2)
                       
                    Next n
                    Exit Do
                Loop
        End Select
        If ers = False Then
            LastValidCANMsgTimer = Now
            Select Case id

 

[priusfan]

ci dessous un message de attila datant du 29/11/2007

... Exact torque values are not reported as far as I know, but need
to be solicited. Which means you have to send a request on the
CAN and wait for a response :
1. Send to ID 0x7e2 : 02 21 c3 00 00 00 00 00 (len: 8 )
2. you should get back on ID 0x7eA : 10 27 61 c3 ?? ?? ?? ?? (len 8 ) these are not relevant for torque
3. Now send to ID 0x7e2 : 30 00 00 00 00 00 00 00 (len 8 )
And you'll get the rest of the data
ID 7ea 21 ?? ?? ?? ?? ?? ?? ??
ID 7ea 22 ?? ?? ?? ?? ?? ?? ??
ID 7ea 23 ?? ?? ?? ?? ?? ?? ??
ID 7ea 24 ?? ?? ?? ?? ?? ?? ??
ID 7ea 25 ?? ?? ?? ?? ?? ?? ??

In all those questions marks lies MG1 and MG2 RPM, torq, temp, inv temps as well as engine speed request and eng speed etc.
Play with it and observe...

Cheers,

Attila

et bien je viens de rèussir à capturer ces données avec le canusb.
d'abord une remarque importante:
le paramètrage du canusb est nettement + sympa que le elm327.
en effet : on peut laisser le canusb en mode autopoll (c'est à dire que l'on peut observer tout le trafic) et en même temp solliciter des réponses.

concrètement dans le programme , à des fins de test, j'ai utilisé encore un timer réglé à 0,5 sec et je l'ai géré comme ceci :

Private Sub Timer2_Timer()
    ctr = ctr + 1
    If ctr = 5 Then ctr = 1
    Select Case ctr
        Case 1
            Call SendCANCommand("t7E0802213C0000000000", False)
        Case 2
            Call SendCANCommand("t7E0802213E0000000000", False)
        Case 3
            Call SendCANCommand("t7E280221C30000000000", False)
        Case 4
            Call SendCANCommand("t7E283000000000000000", False)
    End Select
End Sub

les 2 premiers demandent la temp du pot catalytique (amont / aval).
les 2 autres : cf msg de attila.

résultat d'une capture ici : priusfan.info/canmonitor/CAN_21052009_1702.zip

nota j'ai mis des marqueurs spécifiques pour les PID 7Ex dans la routine parsecan:
Case "7E8"
Print #2, "=xxx===" & LePid & "===xxx======"
Case "7EA"
Print #2, "=yyy===" & LePid & "===yyy======"

je n'ai pas encore mesuré si cette action interfère sur le débit des données capturées.

 

[shadoko]

Je suis béat d'admiration...

 

[Mik&Toy]

C'est un grand pas pour le CanUsb, une nouvelle jeunesse ...

Ça tendrait à prouver que le compilateur C du Linux/Xandros n'est pas à la hauteur de la situation.

Qui pourrait nous fournir un compilateur efficace sans avoir besoin de passer sous le joug de grosbill ?

 

[priusfan]

je ne partage pas du tout ton propos :
je fait que l'on puisse exploiter mieux le canusb que l'elm327 est indépendant des plateformes et langages de développement.

il est trés simple de reproduire les lignes ci dessus dans le pgm graphcan.

 

[Mik&Toy]

Je n'ai pas précisé que c'était de l'acquisition ( parsecan) et non de la capture que je voulais parler.
A quelle vitesse peut on faire tourner le CanUsb dans cette nouvelle configuration sous VB ?

 

[planétaire]

@Priusfan. Super !
Pour arriver à lire cette capture,
j'ai modifié la moulinette que j'avais pour elm327 qui permet maintenant, à partir de la capture brute de ton CanUsb, d'obtenir un csv lisible dans 1 tableur.
Donc après machouillage il est sur ton ftp sous le nom CAN_21052009_CSV.rar qui est le même trajet mais en csv, en gardant les infos les + intéressantes déjà connues (vitesse t/mn etc) plus les 8 octets du 7EAx.

Du boulot à analyser. Atila ne t'a pas donné le codage du 7EAx ?

Dans le fichier brut on constate des paquets de pid mais contrairement à l'elm il y a deux tailles de paquets ! Un gros et un petit ??
Il y a des parasites qu'on voit d'ailleurs dans le csv.

A+

 

[priusfan]

@mik : la capture canusb peut être effectuée à 500k; cela n'a pas été tenté sur plateforme linux, je ne sais pas si le driver ftdi tiendrait le coup , c'est à essayer.
s'il y a un blocage , il ne vient pas de linux et encore moins du compilateur , mais uniquement du driver usb.

@planetaire
je n'ai pas + d'explications , mais quand même dans la famille 7EA
cela se découpe comme cela :
7EA no comment
8 nb octets de la trame

ce qui nous intéresse : les trucs en rouge
7EA8102761C3460B114B 46 0B 11 4B 'réponse au C3
7EA82100005A380E700A 00 00 5A 38 0E 70 0A 'réponse 1 au 30
7EA822680B0E0BC00080 68 0B 0E 0B C0 00 80 'réponse 2 au 30
7EA8238A418500800366 8A 41 85 00 80 03 66 'réponse 3 au 30
7EA8246A6A7C73006490 6A 6A 7C 73 00 64 90 'réponse 4 au 30
7EA82590494608950000 90 49 46 08 95 00 00 'réponse 5 au 30

ces machins doivent donc être mémorisé en "live"

 

[Mik&Toy]

@ priusfan : « … mais uniquement du driver usb. » Est-ce grave , Docteur ?
Y a t'il un moyen donc de Linuxer à donf avec ce biniou ?

Parce je me rappelle que tu t'étais déjà penché sur les captures 7EA dans GraphCan. J'aimerai bien pouvoir reprendre ce développement sous C mais débridé .

 

[priusfan]

pour commencer tu peux tenter de remplacer dans graphcan.c
#define BAUD B230400
par
#define BAUD B500000

 

[Mik&Toy]

Et alors là, pas besoin de RealTerm pour débloquer l'interface ?
Tu dis que ça doit marcher . je le vérifirai en rentrant du Phébus.

Au sujet du pid 7EA, c'est la source rêvée pour authentifier le pid 039 Couple thermique.

 

[planétaire]

7ea 21, 22

En partant du .Csv issu de la "grosse capture de Priusfan", il y a un début de ressemblance entre le couple supposé (039) et le pid 7EA 22 ainsi que le pid 7EA 21.

Le pid 7EA 22 est découpé ainsi: un octet après l'octet de valeur &h22 puis deux mots de 16 bits puis un octet.
Ces deux mots ont une valeur très proche.
Chacun varie à peu près comme le couple (du thermique selon le pid 039).

Mais les accélérations ont été plutôt brèves et on a peu de pid 7EA.
Il faudrait échantillonner à disons 10 fois/seconde pour pouvoir comparer et avoir une stabilisation du régime par exemple à 1500, 2000, 3000, 4000 tr/mn.

Pour l'instant le 039 est meilleur car à partir de sa valeur on obtient un rendement du thermique qui tient la route, ce qui n'est pas encore le cas avec le 7EA 22.
En effet ce calcul de rendement est fort intéressant pour confirmer qu'un pid est le couple.
Le rendement doit atteindre jusqu'à 36% et le couple 110Nm.
Le couple doit augmenter avec les tr/mn jusqu'à xxxx tr/mn.

Le Pid 7EA 21 peut éventuellement contenir le couple dans l'octet 4. Valeur maxi 101 pour 3600-3800 tr/mn. Il est même peut être plus proche du 039 que le 7EA 22.

Mais il y a une phase stabilisée à 1280tr/mn 18km/h où le 039 donne un rendement un peu fort de 35% mais le 7EA 21 donne 50% qui est faux.

Et à l'inverse le reste du temps le rendement obtenu à partir du 7EA 21 octet 4 est en gros 2% plus fort que le 039 ce qui est meilleur.
Ce 7EA 21 a le même défaut que le 039 : il a quand même une valeur de couple quand les tr/mn sont nuls..

And who is the winner ? (*)

A+

(*) In english, just for Shadoko

 

[priusfan]

perso , je ne crois pas trop à cette info de couple du thermique dans un ensemble en provenance de l'ECU du controle du système électrique...
on pourra peut-être trouver des corrélations....

j'ai enfin créé un programme bi-interface.
je ne l'ai testé que pour la partie canusb et il marche normalement ,sauf qu'il me signale à l'écran une erreur CAN qui n'existe pas....
@tester partie elm327

comme il s'agit d'un changement majeur de version, on est passé à 6.0.0
l'ensemble est dans le dossier PriusCanMonitor_planetaire/PCM600/ avec un petit fichier readme.txt

ps: j'ai du réécrire mes adaptations car ma clé usb favorite m'a laché et que pour "gagner du temps" je faisais mes dev dessus.

 

[planétaire]

Testé et approuvé avec Elm327.

Pour ton pb d'affichage "erreur can" je ne sais si ça va t'aider mais c'est géré par un label "Erreurcan" rendu visible ou masqué et par la variable Iflagack qu'à priori tu gères comme il faut dans Mscomcan..
Un dépassement de délai dans SendCanCommand dans l'envoi du "X1" ??
Je sais pas pourquoi j'y crois pas trop à cette hypothèse. Non en fait je mettrais en commentaires les endroits qui affichent ce label jusqu'à tomber sur le coupable. Et là..

A+

 

[priusfan]

super qu'il n'y ait pas eu de régression.

pour le pb d'erreur can , je vais le traiter comme je le faisais avant :
call SendCANCommand("V")
call SendCANCommand("S6")
call SendCANCommand("Z0")
call SendCANCommand("X1")
càd, ignorer totalement le iflagack.

étape suivante :
je vais modifier la ligne suivante
Print #2, Format("#" & Now, "hh:mm:ss") & "_" & Format(GetTickCount, "0") & "#" '17/5/9

comme ceci
Print #2, Format("#" & Now, "hh:mm:ss") & "_" & Format(GetTickCount, "0") & "_" & len(tempstr) &"#"

de façon à vérifier l'impact du mode sollicité sur le nombre de trames capturées.

également, il faudra que je mesure le délai entre la demande et la réponse.

@suivre