BMW M5 Forum and M6 Forums banner
21 - 39 of 55 Posts
Limite de lignes Excel - Office 2013

Juste curieux, mais quelle version d'Excel utilisez-vous ? Je pensais que 2010 permettait plus de 65 000 lignes, mais je pourrais me tromper.

Envoyé depuis l'application AutoGuide.com
messex,

Non, vous avez raison. Je ne peux pas parler pour la version 2010, mais Excel dans Office 2013 permet 1 048 576 lignes. :greenflag:
 
Bonjour AWOL

Je me demandais si vous aviez continué votre aventure canbus, le fil ici s'arrête brusquement. Vous pourriez être mort, mais je veux essayer de rester positif :)
Pourriez-vous me dire quelles couleurs sur le PDC sont pour Can + et Can - ?
Est-ce que je peux y accéder à un autre endroit, comme le contrôleur CCC ?

Cordialement
 
La logique de contrôle de lancement est également la même. La seule différence est une animation de drapeau dans le KOMBI e9x. Je ne vois rien dans les traces de codage e60 pour DKG, mais quelques autres le font, y compris le CIC et l'EKPM.
 
Donc, le premier test ne s'est pas très bien passé.

Apparemment, le bouclier CAN et le programme que j'ai reçu ne fonctionnent pas avec l'Arduino Mega. Le bouclier CAN a un emplacement micro-SD pour l'enregistrement, mais la configuration des broches est différente pour la carte Mega.

Alors, je suis allé à Radio Shack et j'ai acheté un Arduino Uno pour 29,99 $ et les problèmes ont été résolus... du moins avec la carte SD.

J'étais excité et j'ai couru vers la voiture pour le brancher et commencer à enregistrer. Et devinez quoi ? Les E60 Pre LCI n'ont pas de signaux CAN au port OBD...

Donc, maintenant, il faut trouver un endroit facile d'accès pour exploiter le bus CAN. Jusqu'à présent, je pense au coffre sur le module PDC. Je pourrais même déplacer le module PDC hors du logement de la roue de secours (en supposant qu'il soit là sur les Ms comme sur les non-Ms) comme l'ont fait de nombreux gars de bimmerforums pour éviter la possibilité d'un déversement de liquide dans le coffre qui l'inonderait.

J'en posterai plus quand je l'aurai branché et que j'aurai collecté des données.
Salut Jim,

Lorsque vous vous connectez au CAN ailleurs qu'à l'OBD-II, assurez-vous d'utiliser la résistance de terminaison appropriée sur votre carte émetteur-récepteur. Un bus CAN est conçu comme une "colonne vertébrale" à laquelle les participants se connectent. Si vous êtes un point de terminaison, vous devez terminer avec 2 x 60 Ohms à la masse reliés ensemble via un condensateur de 10 nF. Si vous êtes au "milieu" du bus (où vous devriez généralement viser), vous ne terminez pas. Soyez donc conscient de votre position sur le bus et essayez de vous connecter "au milieu". Sinon, vous provoquerez des réflexions et vous risquez d'avoir des problèmes de qualité du signal.

Maintenant, sur le bus CAN de l'actionneur de papillon et les bus CAN des solénoïdes VANOS, vous devez vous connecter sans terminaison car il s'agit d'un bus CAN haut débit point à point. Il n'y a pas de milieu : c'est vous avec votre sniffer. Ce sont les plus intéressants à mon avis :wink, surtout si vous pouvez les aligner dans le temps avec les données d'enregistrement. Soit dit en passant, ces émetteurs-récepteurs particuliers sont fabriqués par Infineon (TLE6250G) fonctionnant à 1 Mbit/s. Il est généralement préférable d'utiliser les mêmes émetteurs-récepteurs en mode écoute pour une fidélité optimale, mais bon, cela fonctionnera également avec un TJA1043 de NXP, je parie. Quel émetteur-récepteur est utilisé sur la configuration Arduino ?

Je ne suis pas sûr des autres réseaux CAN de nos voitures et de leurs débits de données exacts. Certains réseaux haut débit fonctionnent à 500 kbit/s. Alors méfiez-vous. Un oscilloscope bon marché est utile dans de telles matières. J'en ai un si besoin.

Le meilleur logiciel et matériel pour l'enregistrement est celui-ci : CANalyzer
Mais c'est très cher. C'est ce que les constructeurs automobiles utilisent car dans de nombreux cas, ils exécutent leur logiciel sur un système d'exploitation Vector (basé sur OSEK). J'ai regardé sur eBay, mais rien n'est apparu. Surprise, surprise. Je n'ai pas essayé très fort, je dois dire. Cependant, dites le mot et je peux venir avec une boîte à outils lorsque les questions deviennent difficiles !
 
Discussion starter · #25 · (Edited)
Salut Jim,

Lorsque vous vous connectez au CAN ailleurs que sur l'OBD-II, assurez-vous d'utiliser la résistance de terminaison appropriée sur votre carte émetteur-récepteur. Un bus CAN est conçu comme une "colonne vertébrale" à laquelle les participants se connectent. Si vous êtes un point de terminaison, vous devez terminer avec 2 x 60 Ohms à la masse liés ensemble via un condensateur de 10 nF. Si vous êtes au 'milieu' du bus (où vous devriez généralement viser), vous ne terminez pas. Alors, soyez conscient de votre position sur le bus et essayez de vous connecter 'au milieu'. Sinon, vous provoquerez des réflexions et vous risquez d'avoir des problèmes de qualité du signal.

Maintenant, sur le bus CAN de l'actionneur de papillon et les bus CAN des solénoïdes VANOS, vous devez vous connecter sans terminaison car il s'agit d'un bus CAN haut débit point à point. Il n'y a pas de milieu : c'est vous avec votre sniffer. Ce sont ceux qui sont intéressants à mon avis :wink, surtout si vous pouvez les aligner temporellement avec les données de journalisation. Au fait, ces émetteurs-récepteurs particuliers sont fabriqués par Infineon (TLE6250G) fonctionnant à 1 Mbit/s. Il est généralement préférable d'utiliser les mêmes émetteurs-récepteurs en mode écoute pour une fidélité optimale, mais bon, cela fonctionnera également avec un TJA1043 de NXP, je parie. Quel émetteur-récepteur est utilisé dans la configuration Arduino ?

Je ne suis pas sûr des autres réseaux CAN dans nos voitures et de leurs débits de données exacts. Certains réseaux haut débit fonctionnent à 500 kbit/s. Alors, méfiez-vous. Un oscilloscope bon marché est utile dans de telles affaires. J'en ai un si besoin.

Le meilleur logiciel et matériel pour la journalisation est celui-ci : CANalyzer
Mais c'est très cher. C'est ce que les constructeurs automobiles utilisent car, dans de nombreux cas, ils exécutent leur logiciel sur un système d'exploitation Vector (basé sur OSEK). J'ai regardé sur eBay, mais rien n'est apparu. Surprise surprise. Je n'ai pas essayé très fort, je dois dire. Cependant, dites le mot et je peux venir avec une boîte à outils lorsque les questions deviennent difficiles !
Remco, heureux que tu sois intervenu ici. C'était une expérience qui a bien fonctionné et mon objectif final était de prendre un module PDC de rechange et de le réutiliser pour "surveiller" le bus CAN en tant que module "pass-through" en quelque sorte. L'emplacement à l'arrière offrirait de la place pour l'installer et utiliser les données du bus pour signaler d'autres choses comme souhaité dans toute la voiture. Une des nombreuses idées que je ne semble jamais avoir le temps/la priorité de suivre.

Cependant, en regardant la modernisation DCT, nous devons savoir exactement ce qui se trouve sur le bus PT-CAN, il sera essentiel de déterminer la différence entre le trafic en SMG et en DCT.

Voici les descriptions de bus que BMW a adoptées :

View attachment 10_E60 Voltage Supply and Bus Systems.pdf
 
Les RPM bruts (non optimisés pour KOMBI) sont intégrés dans l'ID de message K-CAN, octets 4 et 5, en tant qu'entier non signé de 16 bits. Les ID de message K-CAN et PT-CAN sont les mêmes. Ces messages sont transmis en moyenne à une fréquence de mise à jour de 100 ms (alors que sur PT-CAN, ce serait en moyenne de 10 ms). Merci BMW d'avoir simplifié cela.
 
Discussion starter · #27 ·
Les RPM bruts (non optimisés KOMBI) sont intégrés dans l'ID de message K-CAN, octets 4 et 5, en tant qu'entier non signé sur 16 bits. Les ID de message K-CAN et PT-CAN sont les mêmes. Ces messages sont transmis en moyenne toutes les 100 ms (alors que sur PT-CAN, ce serait en moyenne 10 ms). Merci BMW d'avoir simplifié les choses.
Vrai pour tous les ArbId sur PT-CAN, K-CAN, ByteFlight, LLS-CAN et DK-CAN. Les ArbId sont uniques et se voient attribuer leurs numéros par ordre de priorité, il est donc logique de maintenir l'ordre cohérent.
 
Discussion starter · #30 ·
J'ai posté ceci sur bimmerforums, mais vous trouverez probablement cela utile aussi. Je l'ai trouvé en fouillant dans tool32

Code:
0x399	Status M-Drive [2]	Status M-Drive [2]	0x12	DME1
Liste de ce à quoi servent un tas d'ID de messages et des modules dont ils proviennent. Il manque des ID lorsque je vérifie par rapport à ma 535xi, donc la liste est incomplète, mais c'est quand même bien mieux que de voler complètement à l'aveugle.
Message abrégé de Terra ci-dessus pour ce que je pense que la plupart recherchent ici.

Hex ArbID pour M-Drive est 0x399. Plus précisément, vous pouvez déclencher sur l'octet 1, bits 7-8.

 
Ce qui vous intéresse probablement aussi, ce sont les messages de transmission :

Code:
0xB5	Drehmomentanforderung EGS [9]	Torque demand EGS [9]	0x18	EGS_MECH+NAVI/EGS_MECH
0xB8	Drehmomentanforderung DKG [2]	Torque requirement DKG [2]	0x18	DKG
0xBA	Getriebedaten [20]	Transmission data [20]	0x18	SMG_M/SMG/EGS_MECH+NAVI/EGS_MECH/DKG
0xBD	Drehmomentanforderung SSG [6]	Torque demand SSG [6]	0x18	SMG_M/SMG
0x1A2	Getriebedaten 2 [6]	Transmission data 2 [6]	0x18	EGS_MECH+NAVI/EGS_MECH/DKG
0x1A3	Rohdaten Längsbeschleunigung [3]	Raw data longitudinal acceleration [3]	0x18	SMG_M
0x1D2	Anzeige Getriebedaten [22]	Transmission data display [22]	0x18	SMG_M/SMG/EGS_MECH+NAVI/EGS_MECH/DKG
0x304	Status Gang [13]	Status Status [13]	0x18	SMG_M/SMG/EGS_MECH+NAVI/EGS_MECH/DKG
0x3B1	Getriebedaten 3 [2]	Transmission data 3 [2]	0x18	EGS_MECH/DKG
0x498	Netzwerkmanagement	Network management	0x18	DKG/EGS_MECH/EGS_MECH+NAVI/SMG/SMG_M
0x598	Dienste	services	0x18	DKG/EGS_MECH/EGS_MECH+NAVI/SMG/SMG_M
Seul 0xB8 semble être spécifique à DCT, et seuls 0xBD et 0x1A3 semblent être spécifiques à SMG. 0xB8 et 0xBD semblent tous deux véhiculer une demande de couple, bien qu'il ne soit pas clair si le format est le même. 0x3B1 pourrait ne pas être présent dans les transmissions SMG

L'étape suivante consisterait à démonter le MSS65, à trouver où les messages CAN sont gérés et à voir s'il existe déjà du code pour gérer les messages spécifiques à DCT.
 
Message abrégé de Terra ci-dessus pour ce que je pense que la plupart recherchent ici.

Hex ArbID pour M-Drive est 0x399. Plus précisément, vous pouvez déclencher à partir de l'octet 1, bits 7-8.

View attachment 774593
J'ai regardé ça hier soir. Je suis en train de configurer mon simulateur de messages CAN. Il y a plusieurs choix ici. Je pensais à l'octet 4, bits 5 et 4. C'est la partie M-light du tableau de bord du message. Soit un 01, soit un 10 dans ces bits indiqueront que le voyant M-drive dash / HUD est allumé. Un 00 signifie ÉTEINT. De cette façon, il est indépendant d'un statut ECU particulier dans le véhicule. Cela correspond également à la trace CAN que vous avez laissée quelque part en amont dans ce fil de discussion. Vous avez dû basculer le bouton M dans cette expérience, d'après ce que j'ai pu constater.
 
@jcolley, avez-vous des nouvelles de votre projet ? J'essaie d'activer le bouton du volant M sur le modèle E60 non M, donc si vous avez des conseils utiles pour moi, je les apprécierai.
Même si vous codez le module de direction sur un VO M5 (c'est probablement tout ce qui est nécessaire), la voiture ne saura toujours rien de ces trames CAN.
 
Même si vous codez le module de volant sur un VO M5 (c'est probablement tout ce qui est nécessaire), la voiture ne saura toujours rien de ces trames CAN.
Eh bien, j'ai déjà activé la vue M dans l'affichage tête haute (HUD) de ma E60 non M, donc j'aimerais pouvoir activer/désactiver cette vue dans le HUD lorsque j'appuie sur le bouton M du volant. Actuellement, je ne peux activer/désactiver cette vue qu'à partir des paramètres iDrive. J'ai vu qu'il y a une option M drive dans le module SZL, que je peux éventuellement activer avec le codage NSC Expert, mais je ne sais pas à quoi d'autre cette option peut être liée et je ne veux pas causer de problèmes avec cela. Je pensais que je pouvais simplement obtenir les messages qui sont envoyés dans le bus CAN lorsque le bouton M est enfoncé et, après les avoir reçus, envoyer de nouveaux messages au CIC pour activer la vue M dans le HUD. Est-ce que cela a du sens ?
 
Eh bien, j'ai déjà activé la vue M dans l'affichage tête haute (HUD) de ma E60 non M, donc j'aimerais pouvoir activer/désactiver cette vue dans le HUD lorsque j'appuie sur le bouton M du volant. Actuellement, je ne peux activer/désactiver cette vue qu'à partir des paramètres iDrive. J'ai vu qu'il y a une option M drive dans le module SZL, que je peux éventuellement activer avec le codage NSC Expert, mais je ne sais pas à quoi d'autre cette option peut être liée et je ne veux pas causer de problèmes avec cela. Je pensais que je pouvais simplement obtenir les messages qui sont envoyés dans le bus CAN lorsque le bouton M est enfoncé et, après les avoir reçus, envoyer de nouveaux messages au CIC pour activer la vue M dans le HUD. Est-ce que cela a du sens ?
K-can est configuré comme un bus série et chaque module voit le trafic et ignore les choses qui ne l'intéressent pas. Vous ne ferez pas de bêtises si vous codez SZL pour commencer à envoyer les trames m-mode-on (la seule chose que j'ai vue qui a tout fait foirer, c'est la duplication des messages 0x380 avec un numéro de vin différent).

Il y a de fortes chances que le CIC les ignore de toute façon, jusqu'à ce que vous le codiez pour activer cette fonctionnalité - je ne suis pas sûr que vous puissiez l'activer en codant pour activer la fonctionnalité, ou recoder l'ensemble du CIC avec une VO qui l'a. Probablement le premier cependant, d'après mon expérience, les trucs VO ne font pas grand-chose.

Quoi qu'il en soit, cela devrait être plus facile que de configurer un arduino comme un type d'homme-au-milieu.
 
K-can est configuré comme un bus série et chaque module voit le trafic et ignore les choses qui ne l'intéressent pas. Vous ne ferez pas de bêtises si vous codez SZL pour commencer à envoyer les trames m-mode-on (la seule chose que j'ai vue qui a tout fait foirer, c'est la duplication des messages 0x380 avec un numéro vin différent).

Il est probable que CIC les ignorera de toute façon, jusqu'à ce que vous le codiez pour activer cette fonctionnalité - je ne suis pas sûr que vous puissiez l'activer en codant pour activer la fonctionnalité, ou en recodant l'ensemble du CIC avec une VO qui l'a. Probablement le premier cependant, d'après mon expérience, les trucs VO ne font pas grand-chose.

Quoi qu'il en soit, cela devrait être plus facile que de configurer un arduino comme un type d'intermédiaire.
Oui, je sais comment fonctionne le bus CAN. Probablement, je n'étais pas clair dans mon message précédent. J'ai peur de ne rien casser, ce qui fonctionne bien pour le moment. Par exemple, ma voiture est équipée d'un système d'avertissement de sortie de voie, qui n'existe pas dans les modèles M. Ce système peut être activé/désactivé à partir du bouton, qui se trouve sous le bouton M. Si j'active le mode M dans le SZL, je risque de perdre la possibilité de démarrer et d'arrêter ce système. Ce n'est qu'un exemple que je peux donner, mais il peut y avoir d'autres cas dans lesquels l'activation du mode M dans le SZL peut conduire à un résultat négatif. De plus, comme vous l'avez mentionné, l'activation du mode M dans le SZL peut ne pas suffire et je devrai peut-être activer d'autres options dans d'autres modules... cependant, je peux facilement essayer et si le résultat n'est pas assez bon, je peux revenir à ces paramètres.
Et enfin, si je parviens à obtenir le résultat que je souhaite via le codage, ce ne sera pas aussi amusant que de l'obtenir avec Arduino :)
 
Oui, je sais comment fonctionne le bus CAN. Je n'étais probablement pas clair dans mon message précédent. J'ai peur de ne rien casser, ce qui fonctionne bien pour le moment. Par exemple, ma voiture est équipée d'un système d'avertissement de sortie de voie, qui n'existe pas dans les modèles M. Ce système peut être activé/désactivé à partir du bouton, qui se trouve sous le bouton M. Si j'active le mode M dans le SZL, je risque de perdre la possibilité de démarrer et d'arrêter ce système. Ce n'est qu'un exemple, que je peux donner, mais il peut probablement y avoir d'autres cas dans lesquels l'activation du mode M dans le SZL peut conduire à un résultat négatif. De plus, comme vous l'avez mentionné, l'activation du mode M dans le SZL peut ne pas suffire et je devrai peut-être activer d'autres options dans d'autres modules... cependant, je peux facilement essayer et si le résultat n'est pas assez bon, je peux revenir à ces paramètres.
Et enfin, si je parviens à obtenir le résultat que je souhaite via le codage, ce ne sera pas aussi amusant que de l'obtenir avec Arduino :)
Euh, je suppose que je ne vois pas comment vous allez obliger SZL à envoyer des trames CAN à partir du bouton M, si cette fonctionnalité n'est pas codée. Je crois que la signalisation entre les boutons et SZL est basée sur la résistance, donc mettre un arduino entre les deux serait une énorme galère. D'un autre côté, faire passer un fil séparé vers le bouton m nécessiterait un ressort de rappel avec plus de fils (peut-être un volant chauffant ? bien que vous puissiez être SOL avec le truc de vibration de sortie de voie dans le volant)
 
Salut les gars, je relance un vieux fil de discussion - quelqu'un peut-il partager son croquis Arduino utilisé pour renifler les messages k can ? De plus, quelqu'un peut-il confirmer que des résistances de terminaison de 120 ohms de H et L à la masse seraient nécessaires lors du raccordement au k can au PDC ?
 
Salut les gars, je relance un vieux fil de discussion - quelqu'un peut-il partager son croquis Arduino utilisé pour renifler les messages k can ? De plus, quelqu'un peut-il confirmer que des résistances de terminaison de 120 ohms de H et L à la masse seraient nécessaires lors du raccordement au k can au PDC ?
Oui, c'est la terminaison appropriée pour le K-can. Jetez un coup d'œil au croquis arduino ici.

https://github.com/pavelmalik/BMWCanBridge

Laissez-moi deviner, vous voulez intégrer des coupures d'échappement dans le mode m ? :)
 
21 - 39 of 55 Posts