Hallo, ich habe ein neues CAN Analyse Tool entwickelt, das Programm ist in Delphi Version 6 geschrieben und ist Open Source. Inspiriert wurde ich vom CAN-Interceptor (Martin Starka) was die Auswertung der CAN-Daten über einen Berechnungsterm löst. Diese Funktionalität habe ich auch in meinen Tool übernommen, wodurch der Programmieraufwand erheblich reduziert wird. Als Hardware unterstützt das Programm die Tiny-CAN Module und alle (hoffe ich) Module die das Lawicel-Protokoll (auch bekannt als SL-CAN Protokoll) unterstützen. Für das Lawicel-Protokoll wird als serielle Geschwindigkeit 57,6 kBaud verwendet und der COM Port wird automatisch gesucht. Die Hardware muss beim starten des Programms bereits mit dem PC verbunden sein! Vielleicht gibt es ja Leute die sich beteiligen wollen ? Download (Exe und Quellen): http://www.mhs-elektronik.de/userdata/downloads/can_cool.zip Grüße Klaus
Hallo Klaus, sieht gut aus! Leider habe ich kein Tiny-Can Interface zum Testen. Genail währes es, wenn dein Tool noch Vector CanDB (DBC) einlesen könnte :-) gruß Heinz
Hallo Heinz, ein Tiny-CAN brauchst Du gar nicht, es müsste eigentlich jedes Interface funktionieren was das SL-CAN Protokoll unterstützt. Du kannst dir ein Interface selber bauen :-) z.B. http://www.fischl.de/usbtin/ oder auch http://www.mictronics.de/projects/usb-can-bus/ Das mit dem DBC Files einlesen wird leider nie Funktionieren, die Aufschlüsselung der CAN Daten erfolgt ja nicht über eine CAN Datenbank sondern über eine Berechnungsterm! Für DBC Files müsste man das ganze Programm komplett umschreiben :-( Im Busmaster kannst Du DBC Files einlesen: http://rbei-etas.github.com/busmaster/ Ist auch Open Source Gruß Klaus
Klaus Demlehner schrieb: > Du kannst dir ein Interface selber bauen :-) > z.B. http://www.fischl.de/usbtin/ > oder auch http://www.mictronics.de/projects/usb-can-bus/ Danke. Werde ich mir mal ansehen. Habe privat noch ein Kvaser Interface mit CanKing. Das reicht z.Zt. noch für kleine Basteleien. > Das mit dem DBC Files einlesen wird leider nie Funktionieren, > die Aufschlüsselung der CAN Daten erfolgt ja nicht über eine CAN > Datenbank sondern über eine Berechnungsterm! > Für DBC Files müsste man das ganze Programm komplett umschreiben :-( > > Im Busmaster kannst Du DBC Files einlesen: > http://rbei-etas.github.com/busmaster/ > Ist auch Open Source Busmaster hatte ich mir auch schon mal früher angesehen, fand die GUI und den Funktionsumfang aber nicht so toll. Das ist aber schon mind. ein Jahr her. Die aktuelle Version (und besonders der Blick auf den Milestone Plan) lassen aber einiges hoffen. (Flexray, lin,...) :-) Muss mich unbedingt wieder damit beschäftigen. Werde morgen mal versuchen ein kleines CANoe Project in Busmaster zu realisieren. Hoffe ich muss am CAPL nicht so viel umbauen... Wurde auch mal Zeit, dass es eine Opensource alternative zu der überteuerten Software von der Ingersheimer Straße gibt. Wenn ich überlege wie viel unsere Firma jedes Jahr an V***** bezahlt wird mir schlecht :-(
http://rbei-etas.github.com/busmaster/ ein monopolist mit dem anderen ersetzen, schön dank auch... als opensource starten, alsbald dann verkaufen...
Hallo Vectorist, ich finde es toll was die da auf die Beine gestellt haben! Das mit einen Opensource Projekt verschließen ist nicht so einfach wie Du glaubst, wenn dann würde es 2 Versionen geben eine Open Source und eine Kommerzielle. Hallo Heinz, das design der GUI ist nicht der Knüller :-) Aber es erfüllt seinen Zweck und die Software kostet ja halt auch nichts. Leider komme ich mit dem MFC nicht klar:-( sonst hätte ich mich an der Entwicklung mehr beteiligt. Ich selbst verwende ja auch CanEasy und die Bedienung, super einfach, die Doku genial ..... aber Spaß kostet halt auch Geld :-) Gruß Klaus
Klaus Demlehner schrieb: > ich finde es toll was die da auf die Beine gestellt haben! > Das mit einen Opensource Projekt verschließen ist nicht so einfach wie > Du glaubst, Wenn sich alle Entwickler der Software einig sind, schon. > wenn dann würde es 2 Versionen geben eine Open Source und eine > Kommerzielle. Zumindest die bisherige OpenSource-Version kann man nicht nachträglich dann zu Closed Source umerklären. Die bleibt bestehen. Das Problem wird aber sein, daß sich wenige finden, an einem OpenSource-Projekt dieser Art zu arbeiten. Privat brauchen eher wenige so ein Tool, und die typischen Firmen aus der Branche scheuen sich meist davor, ihre Entwickler dafür zu bezahlen, um an einer Software zu arbeiten, die dann an die Konkurrenz verschenkt wird.
OpenSource<>OpenSource man sollte immer dazu schreiben WELCHE lizenz..
heinz schrieb: > Wurde auch mal Zeit, dass es eine Opensource alternative zu der > überteuerten Software von der Ingersheimer Straße gibt. > Wenn ich überlege wie viel unsere Firma jedes Jahr an V***** bezahlt > wird mir schlecht :-( Naja, Entwicklung (vor allem in Deutschland) kostet eben auch Geld. Und bei Vector sitzen eine ganze Menge von Entwicklern an CANoe/CANalyzer (da ist noch nichts nach Indien outgesourced) ;-) Der hohe Preis kommt also nicht von ungefähr...
DerBlimp schrieb: > Naja, Entwicklung (vor allem in Deutschland) kostet eben auch Geld. Und > bei Vector sitzen eine ganze Menge von Entwicklern an CANoe/CANalyzer > (da ist noch nichts nach Indien outgesourced) ;-) > Der hohe Preis kommt also nicht von ungefähr... <Ironie> Ja das habe ich mir auch beim review von Vecrors AUTOSAR code gedacht.... Das isst mal echte Qualliätsarbeit LOL. Erfüllen der ISO26262 ist damit ein Kinderspiel! </Ironie>
Robert L. schrieb: > OpenSource<>OpenSource > man sollte immer dazu schreiben WELCHE lizenz.. Im fall von Busmaster ist es wohl LGPLv3.
Hallo Klaus, dein Projekt find ich super. Ich hätte da noch eine Frage: Wenn ich das Programm starte kommt die Fehlermeldung, die ich im Anhang gehängt habe. Woran liegt das?
>Woran liegt das?
es liegt daran, dass die FTD2XX.dll auf dem Computer fehlt
;-)
na da ist ja ein ganz schlauer unterwegs. Lesen kann ich auch. Die Frage ist nur, wo bekomme ich die he?
Duu schrieb: > na da ist ja ein ganz schlauer unterwegs. Lesen kann ich auch. Die Frage > > ist nur, wo bekomme ich die he?Beitrag melden Bearbeiten Löschen lmgtfy. com/?q=FTD2XX.dll
Duu schrieb: > Hallo Klaus, > > dein Projekt find ich super. Ich hätte da noch eine Frage: > Wenn ich das Programm starte kommt die Fehlermeldung, die ich im Anhang > gehängt habe. Woran liegt das? Ups, da fehlt der FTDI Treiber :-) Dort bekommst Du den http://www.ftdichip.com/Drivers/CDM/CDM20824_Setup.exe Grüße Klaus
DerBlimp schrieb: > > Naja, Entwicklung (vor allem in Deutschland) kostet eben auch Geld. Und > bei V.... sitzen eine ganze Menge von Entwicklern an CAN../CANa... > (da ist noch nichts nach Indien outgesourced) ;-) > Der hohe Preis kommt also nicht von ungefähr... Die nutzen nur ihre Marktbeherrschende Stellung schamlos aus sonst nichts! Mit dem weil deutsche Software Entwickler unbezahlbar sind hat das nichts zu tun. :-) Ich finde es ist eine Frechheit das immer wenn es irgendwie um CAN geht immer sofort Werbung für V.... gemacht wird. Da sollte man mal lieber schreiben wie die eigentlich mit Kunden und anderen Firmen umgehen! Ich bin noch niemanden begegnet der sich über die nicht geärgert hat. Übrigens CANcool ist 100% Made in Germany und kostet gar nichts :-) Und die Hardware kannst Du selber Bauen oder in Indien fertigen lassen Nichts für ungut Klaus
Bei solchen Projekten habe ich immer so meine Bedenken. Es gab ja mal den CAN-Hacker, der war ja ganz großer Mist. bei diesem Projekt habe ich so meine Zweifel ob man wirklich eine große Datenrate erzielen kann. Die Übertragung erfolgt offensichtlich in ASCII. Kann sich mal der Entwickler zu den erzielbaren Transferrate äußern. MfG Eddi
Klaus Demlehner schrieb: > Übrigens CANcool ist 100% Made in Germany und kostet gar nichts :-) > Und die Hardware kannst Du selber Bauen oder in Indien fertigen lassen Na dann bist du ja fein raus und brauchst nix mehr von Vector kaufen ;-)
Hallo Eddi hal9001 schrieb: > Bei solchen Projekten habe ich immer so meine Bedenken. > Es gab ja mal den CAN-Hacker, der war ja ganz großer Mist. Mit dem Entwickler komme ich nicht klar, aber die CAN-Hacker Software finde ich gar nicht so schlecht. Was ist da Mist ? > > bei diesem Projekt habe ich so meine Zweifel ob man wirklich > eine große Datenrate erzielen kann. Die Übertragung erfolgt > offensichtlich in ASCII. Kann sich mal der Entwickler zu > den erzielbaren Transferrate äußern. CANcool ist ja noch eine Beta Version, was die maximalen Transferraten angeht habe ich noch keine Messungen gemacht. Das hängt natürlich auch von der verwendeten Hardware ab. Die Tiny-CANs verwenden ja ein spezielles Binär-Protokoll und das größte Modul schafft ohne Probleme 100% Buslast. Ob die Software es auch schafft? Bei meiner anderen Software Tiny-CAN View musste ich da ganz schön Aufwand betreiben. Bei dem ASCII Protokoll wird die max. Buslast nicht sehr groß sein, für den Bastler der z.B. nur seine Heizungsanlage auslesen will wirds auf jeden Fall reichen. Gruß Klaus
Klaus Demlehner schrieb: > Mit dem Entwickler komme ich nicht klar, aber die > CAN-Hacker Software finde ich gar nicht so schlecht. > Was ist da Mist ? Ich habe die Software damals ausprobiert. Die ist bei nicht allzuhoher Buslast einfach abgekackt. Ohne Fehlermeldung. Man musste das Produkt dann über den Prozessexplorer abschiessen. Ich denke man sollte wenn man so eine Software macht 1Mbit mit DLC 0 wegschaufeln können. Da kommt halt alle 130uSek ein Paket. Ob man das mit einem 16Mhz AVR durch Bitwackeln am Port wegschaufeln kann, wage ich zu bezweifeln. Mach doch mal was gescheites, nimm einen STM32, benutze den internen CAN und den USB, denke dir ein gescheites Protokoll aus. Für mich ist da das Problem, wo ist die Grenze. Bis zu welcher Buslast funzt das ganze. Wenn du schon bei dem Konzept bleibst, sorge wenigstens dafür das wenigstens eine Meldung kommt wenn Telegramm im Nirvana verschwinden.
Ach so Ich würde auch einen Dekoder für CanOpen und DeviceNet einbauen. Der unbedarfte Benutzer will ja wissen was seine Heizungssteuerung so macht und nicht die Grütze vom CANOpen oder DeviceNet zu Fuss dekodieren.
Klaus Demlehner schrieb: > Da sollte man mal lieber schreiben wie die eigentlich mit Kunden und > anderen Firmen umgehen! Naja die haben einen schönen Glaspalast und ne super kantine, das muss ja jemad bezahlen. Es gibt bei CANAnalyse ja noch alternativen oder?
hal9001 schrieb: > > Ich habe die Software damals ausprobiert. Die ist bei nicht allzuhoher > Buslast einfach abgekackt. Ohne Fehlermeldung. Man musste das Produkt > dann über den Prozessexplorer abschiessen. Ok, so viel habe ich da nicht getestet :-) > > Ich denke man sollte wenn man so eine Software macht 1Mbit mit > DLC 0 wegschaufeln können. Da kommt halt alle 130uSek ein Paket. > Ob man das mit einem 16Mhz AVR durch Bitwackeln am Port wegschaufeln > kann, wage ich zu bezweifeln. Glaube ich nicht, in meiner eigenen Hardware verwende ich einen DMA Transfer für die Kommunikation. > > Mach doch mal was gescheites, nimm einen STM32, benutze den internen > CAN und den USB, denke dir ein gescheites Protokoll aus. Nein Danke ich bleibe bei meinen Fujitsu FX und Renesas RX Controllern > > Für mich ist da das Problem, wo ist die Grenze. Bis zu welcher Buslast > funzt das ganze. Wenn du schon bei dem Konzept bleibst, sorge wenigstens > dafür das wenigstens eine Meldung kommt wenn Telegramm im Nirvana > verschwinden. Das Programm unterstützt ja 2 Konzepte: Tiny-CAN (Binär-Protokoll) und SL-CAN (ASCII Protokoll) Ich habe dieses ASCII Protokoll ja nicht erfunden! Es gibt aber einige Hardware die mit diesem Protokoll arbeiten Leider setzt sich eben nicht immer das beste durch :-( Gruß Klaus
hal9001 schrieb: > Klaus Demlehner schrieb: >> Da sollte man mal lieber schreiben wie die eigentlich mit Kunden und >> anderen Firmen umgehen! > > Naja die haben einen schönen Glaspalast und ne super kantine, > das muss ja jemad bezahlen. Es gibt bei CANAnalyse ja noch > alternativen oder? Da fragst Du noch :-)) Natürlich: http://www.mhs-elektronik.de/userdata/downloads/can_cool.zip Grüße Klaus
hal9001 schrieb: > Naja die haben einen schönen Glaspalast und ne super kantine, > > das muss ja jemad bezahlen. Es gibt bei CANAnalyse ja noch > > alternativen oder? Ja natürlich, zu reinen analyse gibt es viele, CCP tools auch, bei der Restbussimulation sieht es da schon übersichtlicher aus. Wenn man eine Toolchain benötigtigt, die Design, Analyse, Simulation, Fehlerdiagnose, Calibration, uvm. aus der selben Datenbasis unterstützten soll, dann gibt es wenig allternativen zum großen V. Vector bietet zwar alles aus "einem guss" und es funktioniert auch (meist). Aber Quallitätssoftware made in Germany sieht anders aus. Und der Support ist auch eher von der Sorte: "Das kann ich nicht beantworten, da muss ich beim Entwickler nachhören". Und das dauert dann halt auch mal ein paar Tage...
Hallo Klaus, ich habe deinen Rat befolgt und den FTDI Treiber von dem Link installiert. Rechner neu gestartet, aber die Fehlermeldung kommt weiterhin. Das Programm startet, aber die Meldung macht mich doch ein wenig stutzig. Brauche ich vielleicht eine Hardware dazu?
Hallo Heinz, > > Vector bietet zwar alles aus "einem guss" und es funktioniert auch > (meist). Aber Quallitätssoftware made in Germany sieht anders aus. Und > der Support ist auch eher von der Sorte: "Das kann ich nicht > beantworten, da muss ich beim Entwickler nachhören". Und das dauert dann > halt auch mal ein paar Tage... Ja da hört man von allen die mit denen zu tun haben/hatten das gleiche :-) Wobei Du beim Support ja noch Glück hattest, da kenne ich schon andere Geschichten. Gruß Klaus
Duu schrieb: > Hallo Klaus, > > ich habe deinen Rat befolgt und den FTDI Treiber von dem Link > installiert. Rechner neu gestartet, aber die Fehlermeldung kommt > weiterhin. Das Programm startet, aber die Meldung macht mich doch ein > wenig stutzig. Brauche ich vielleicht eine Hardware dazu? Stimmt da hast Du recht, Sch... Windows. Der Treiber wird erst dann "fertig" Installiert wenn du eine Hardware mit FTDI Chip ansteckst, wenn Du einen USB-Seriell Wandler hast? (In den meisten sind FTDI Chips verbaut) Du kannst auch die beiden DLLs (mhstcan.dll u. mhsslcan.dll) aus dem "bin" Verzeichnis löschen, hoffe dann startet die Software. Gruß Klaus
Hallo Klaus, erstmal vielen Dank für die Veröffentlichung dieses Tools! Ich bin gerade dabei, das Lawicel Protokoll auf meinem eigenen USB-Can-Interface zu implementieren. Inzwischen funktioniert es auch soweit, dass ich Pakete mit CAN Cool senden und empfangen kann. Einzig die Anzeige der Timestamps funktioniert nicht. Ich sende, wie im Protokoll beschrieben, den Timestamp in Millisekunden (2Byte bzw 4Byte Ascii Hex), falls dies mit Z1[CR] aktiviert wurde. Klicke ich in CAN Cool auf "CAN-Controller-Reset" dann sehe ich ein paar Pakete mit Time 3532244015 eintreffen. Danach geht der Zähler wieder auf 0. Hast Du eine Idee woran das liegen könnte? Gruß Björn
Heinz schrieb: > <Ironie> > Ja das habe ich mir auch beim review von Vecrors AUTOSAR code > gedacht.... > Das isst mal echte Qualliätsarbeit LOL. > Erfüllen der ISO26262 ist damit ein Kinderspiel! > </Ironie> Hast Du ein paar Details und Alternativen? mentor, elektrobit?
Hallo Björn, Björn B. schrieb: > Hallo Klaus, > > erstmal vielen Dank für die Veröffentlichung dieses Tools! Danke :-) > > Ich bin gerade dabei, das Lawicel Protokoll auf meinem eigenen > USB-Can-Interface zu implementieren. Inzwischen funktioniert es auch > soweit, dass ich Pakete mit CAN Cool senden und empfangen kann. Einzig > die Anzeige der Timestamps funktioniert nicht. Ich sende, wie im > Protokoll beschrieben, den Timestamp in Millisekunden (2Byte bzw 4Byte > Ascii Hex), falls dies mit Z1[CR] aktiviert wurde. Klicke ich in CAN > Cool auf "CAN-Controller-Reset" dann sehe ich ein paar Pakete mit Time > 3532244015 eintreffen. Danach geht der Zähler wieder auf 0. > Hast Du eine Idee woran das liegen könnte? Ich kann den Fehler nachvollziehen und habe den Fehler im Code auch schon gefunden, ich habe beim SL Protokoll den Timestamp einfach vergessen :-) Gib mir noch ein paar Tage für das Update. Bis dahin kannst Du deine Hardware auch mit dem CAN Hacker testen. Gruß Klaus
Klaus Demlehner schrieb: > Gib mir noch ein paar Tage für das Update. > > Bis dahin kannst Du deine Hardware auch mit dem CAN Hacker testen. Hallo Klaus, na klar, ich habs nicht eilig. Du hast recht, mit dem CAN Hacker funktionieren auch die Timestamps :-) Gruß Björn
Hallo Björn, ich habe den Timestamp Fehler behoben. Ersetzte die "mhsslcan.dll" im "bin" Verzeichnis von CANcool Gruß Klaus
Hallo Klaus, jetzt funktioniert es prima :-) Vielen Dank! Gruß Björn
Hallo Klaus, Schon mal vielen herzlichen Dank für dieses wunderbare Tool! Vom Ansatz her fast genau das, was ich mir wünsche. Als Besitzer eines Lawicel CAN232 und seit ein paar Tagen auch eines Tiny-Can I-XL finde ich es toll endlich mal beide mit einer einzigen Software bedienen zu können. Mit dem Lawicel habe ich es aber noch nicht getestet. Wobei der Lawicel und Canhacker auch ein tolles Team sind und die Leistung des CAN232 in meinem Fall bisher noch immer reichte. (dafür kann man den halt mit einem kleinen Atmega oder so ganz einfach ansteuern, und darauf kam es mir an) Da ich mich nun schon seit ein paar Tagen mit Programmen wie CAN-View (lief auf Anhieb, aber der Funktionsumfang...) CANviaUSB (lief erst nach Tausch der mhstcan.dll) und Busmaster (ganz schön störrisch, ebenfalls das DLL-Problem, da verträgt sich aber noch irgendwas nicht....Probleme!) ...liegt wohl am USB-Chip des I-XL.... Mit can_cool lief mein Tiny-Can sofort! (ich werds noch unter WIN2000 testen, wäre schön, wenns da auch ginge, weil ich da in einem ganz besonderen Fall nicht auf XP oder neuer updaten kann) Wünsche und Vorschläge: (das fiel mir ganz spontan auf beim Erstkontakt mit dem Programm) 1. Umschalten zwischen Trace und Objekt Liste bitte mit einem (1) Klick 2. Die Fenster Empfangen / Senden sollten sich die Größe merken, zumindest so lange wie das Programm läuft,so dass man ggfs einfach zwischen "Vollbildern" hin und her schalten kann. Und noch ein ganz großer Wunsch, weil ich das bei sämtlichen anderen erschwinglichen Programmen vermisse, dabei wärs wohl gar nicht viel Aufwand.........Die Werte gibts ja schon... Ich hätte sehr gerne eine Möglichkeit, eine ID auszuwählen, bei der die Byte dann nicht nur als HEX und DEZ sondern auch binär dargestellt sind. .....und wenns nur ein Feld aus 8 x 8 Kästchen mit Nullen und Einsen ist, wie es z.B. bei der Eingabe in BUSMASTER gemacht ist. (Das wäre eine gewaltige Hilfe beim "knacken" unbekannter Bit-codierter CAN-Messages insbesondere im Automobil-Bereich) Wenn man dann auch noch ganze Passagen aufzeichnen und wieder genau so senden kann/könnte bzw auch noch editieren könnte wärs nahezu perfekt. mfG Franz
Mir ist gerade noch was aufgefallen, Es wäre schön, wenn man das Senden auch wieder stoppen könnte ;-) (z.B. durch nochmal auf Senden klicken, dann sollte da natürlich Stop stehen so lange gesendet wird) Ist das dem Triggern so gedacht, dass man auf eine empfangene ID eine Antwort schicken kann? vielleicht noch mit einstellbarer Verzögerung? Das mit aufzeichnen und wieder Senden ganzer Sequenzen ist ja schon vorgesehen, habs vorhin nicht sofort bemerkt mfG Franz
Hallo Franz, Vehikelfranz schrieb: > Als Besitzer eines Lawicel CAN232 und seit ein paar Tagen auch > eines Tiny-Can I-XL finde ich es toll endlich mal beide mit einer > einzigen Software bedienen zu können. > Mit dem Lawicel habe ich es aber noch nicht getestet. Wäre gut wenn Du es testen könntest, würde mich interessieren obs funktioniert. > > Da ich mich nun schon seit ein paar Tagen mit Programmen wie > CAN-View (lief auf Anhieb, aber der Funktionsumfang...) Ist was die Performance betrifft mein bestes Programm :-) > CANviaUSB (lief erst nach Tausch der mhstcan.dll) Ok, danke gut zu wissen :-) > und Busmaster (ganz schön störrisch, ebenfalls das DLL-Problem, > da verträgt sich aber noch irgendwas nicht....Probleme!) > ...liegt wohl am USB-Chip des I-XL.... Ich bring den Busmaster bei mir schon zum laufen. Die DLL muss man austauschen, stimmt. > > Mit can_cool lief mein Tiny-Can sofort! :-) > (ich werds noch unter WIN2000 testen, wäre schön, > wenns da auch ginge, weil ich da in einem ganz besonderen > Fall nicht auf XP oder neuer updaten kann) Kann ich dir nicht versprechen, Win7 ist in der 32 oder 64 Bit Version kein Thema. > > Wünsche und Vorschläge: > (das fiel mir ganz spontan auf beim Erstkontakt mit dem Programm) > 1. Umschalten zwischen Trace und Objekt Liste bitte mit einem (1) Klick Notiert, ändert sich aber vorläufig nicht. > 2. Die Fenster Empfangen / Senden sollten sich die Größe merken, > zumindest so lange wie das Programm läuft,so dass man ggfs einfach > zwischen "Vollbildern" hin und her schalten kann. Kann ich so nicht ganz nachvollziehen. Wenn Du das Programm aber beendest, wenn ein Fenster in "Vollbild" dargestellt wird dann wird leider die Vollbildgröße gespeichert. Leider weiß ich aber nicht wie ich das ändern kann :-( > > Und noch ein ganz großer Wunsch, weil ich das bei sämtlichen > anderen erschwinglichen Programmen vermisse, dabei wärs wohl > gar nicht viel Aufwand.........Die Werte gibts ja schon... > > Ich hätte sehr gerne eine Möglichkeit, eine ID auszuwählen, > bei der die Byte dann nicht nur als HEX und DEZ sondern auch > binär dargestellt sind. .....und wenns nur ein Feld aus > 8 x 8 Kästchen mit Nullen und Einsen ist, wie es z.B. bei der > Eingabe in BUSMASTER gemacht ist. Das ist in der nächsten Version drin, jedes Byte wird sogar noch als "analoger" Balken dargestellt und bei den Intervallen wird eine Min/Max Zeit angegeben > > Wenn man dann auch noch ganze Passagen aufzeichnen und wieder > genau so senden kann/könnte bzw auch noch editieren könnte > wärs nahezu perfekt. Das Tool ist Open Source, ran an die Tasten :-) Gruß Klaus
Vehikelfranz schrieb: > Mir ist gerade noch was aufgefallen, > > Es wäre schön, wenn man das Senden auch wieder stoppen könnte ;-) Wenn man Tx Mode auf "Off" stellt sollte der Timer eigentlich gestoppt werden. Funktioniert aber (noch) nicht :-) Du kannst aber auch einfach die Zeit auf 0 stellen. > (z.B. durch nochmal auf Senden klicken, dann sollte da natürlich > Stop stehen so lange gesendet wird) Das mit dem "Senden" Button ist schon richtig so, Du kannst das Paket ja immer noch per Hand senden. > > Ist das dem Triggern so gedacht, dass man auf eine empfangene ID > eine Antwort schicken kann? Ja > vielleicht noch mit einstellbarer > Verzögerung? Übertriebs nicht > > Das mit aufzeichnen und wieder Senden ganzer Sequenzen ist ja > schon vorgesehen, habs vorhin nicht sofort bemerkt Aufzeichnen Ja....senden eigentlich nicht Grüße Klaus
Hallo Klaus,
....das waren ja nur Wünsche.....
klar, dass man nicht alles haben kann,
aber wünschen darf man sichs trotzdem ;-)
Das mit den Fenstern und dem Merken der Größe
ist nicht weiter tragisch, ich hab nur in alter Gewohnheit
auf die Titelleiste doppelgeklickt, und da maximiert das nicht,
wenn man an den Rändern die Größe ändert, dann klappts mit dem Merken.
Das ist jetzt nicht problematisch und fällt eher unter
Feintuning für später mal.
>>Das Tool ist Open Source, ran an die Tasten :-)
Tja, schön wärs, aber meine Programmierkenntnisse
reichen dafür nicht, wobei ich mich aber auch viel mehr
in Richtung Hardware und Atmegas (Bascom und neuerdings Arduino)
orientiere.
Ich beschäftige mich im Rahmen diverser
Elektroauto-Projekte mit so Dingen wie
"Wie bekomme ich den Ladezustand auf die Tankuhr
und die Stromstärke auf den Drehzahlmesser"
und dazu muss halt dann schon mal der Datenstrom
zum Tacho eines Smart oder dergleichen entschlüsselt werden.
deshalb ist mir die Bit-Darstellung so extrem wichtig.
linke Tür , rechte Tür, Blinker oder Öldruck,
man sieht ja schnell mal wo es drinsteckt, aber
im Kopf umrechnen geht ja noch wenn sich nur ein Bit
ändert, aber meist hängen mehrere zusammen,
und bis man sich da durch Tabellen kämpft ist die Woche um....
..und das Steuern der Ladegeräte läuft inzwischen auch fast
immer per CAN
Eines meiner nächsten Vorhaben wäre gewesen, mir so einen
Bit-Decoder auf Basis des Lawicel und eines Atmega zu basteln.
Für den Datenstrom eines Autos reicht die Performance
des Lawicel locker, das ist nicht mein Problem, mir gehts ums
entschlüsseln und dann ggfs mal darum ein paar Sequenzen zu senden.
Das klappt mit dem Canhacker ganz gut, da muss auch nicht das Rad
neu erfunden werden.
Can-View... Dass da die Performance gewaltig ist bemerkt man
sofort im direkten Vergleich z.B. zu CANviaUSB, aber was ich noch
mehr daran schätze ist die Möglichkeit, das z.B. mit Profilab
zu verknüpfen....aber nur um die Bits darzustellen eine
ziemliche Kanone für den Spatz....
Der Plugin ist trotzdem so gut wie gekauft,
das brauche ich gewiss noch öfter!
Ich werde das Programm mit dem Lawicel CAN232 testen, sobald ich den
wieder habe. Der ist momentan ausgeliehen, aber das hat doch schon
jemand anders hier in den Thread getestet.
Da bin ich sehr zuversichtlich dass das funktioniert.
Wobei das aber nicht wirklich entscheidend ist für das
was ich so vorhabe:
Tiny-Can am Laptop, Lawicel Can232 am Atmega für Tests
und mobilen Einsatz und letztendlich macht dann meist eh alles
ein entsprechend programmiertes Gateway-Modul, weil meist die
Datenrate nicht zusammenpasst
mfG
Franz
Hallo Klaus, Can_cool läuft unter WIN2000 ! (zumindest in der derzeitigen Version) Großartig! (da gibts sehr oft Probleme mit Diensten wie freeaddrinf und so weiter..... auch mit can-view geht unter 2000 nichts) mfG Franz
Hallo Franz, > klar, dass man nicht alles haben kann, > aber wünschen darf man sichs trotzdem ;-) Natürlich und ich freue mich auch über Anregungen > > Das mit den Fenstern und dem Merken der Größe Es macht eigentlich nicht viel Sinn die Fenster im Vollbild darzustellen, ich habe die Funktion jetzt einfach disabled :-) > Eines meiner nächsten Vorhaben wäre gewesen, mir so einen > Bit-Decoder auf Basis des Lawicel und eines Atmega zu basteln. > Für den Datenstrom eines Autos reicht die Performance > des Lawicel locker, das ist nicht mein Problem, mir gehts ums > entschlüsseln und dann ggfs mal darum ein paar Sequenzen zu senden. > Das klappt mit dem Canhacker ganz gut, da muss auch nicht das Rad > neu erfunden werden. Der Canhacker kann Sequenzen senden ? > > Can-View... Dass da die Performance gewaltig ist bemerkt man > sofort im direkten Vergleich z.B. zu CANviaUSB, aber was ich noch > mehr daran schätze ist die Möglichkeit, das z.B. mit Profilab > zu verknüpfen....aber nur um die Bits darzustellen eine > ziemliche Kanone für den Spatz.... > Der Plugin ist trotzdem so gut wie gekauft, > das brauche ich gewiss noch öfter! Mit dem ProfiLab Plugin kannst Du halt auch Muxer Nachrichten auswerten, ich weiß nicht ob ich die Unterstützung für Muxer in CanCool einbaue. > > Ich werde das Programm mit dem Lawicel CAN232 testen, sobald ich den > wieder habe. Der ist momentan ausgeliehen, aber das hat doch schon > jemand anders hier in den Thread getestet. Glaube ich auch, leider hat es mir aber noch niemand bestätigt! Björn hat es mit seiner eigenen Hardware zum laufen gebracht. Gruß Klaus
Hallo Klaus, > Das mit den Fenstern und dem Merken der Größe >Es macht eigentlich nicht viel Sinn die Fenster im Vollbild >darzustellen, ich habe die Funktion jetzt einfach disabled :-) Das passt schon! Die Breite ist ja ziemlich vorhersehbar, da findet sich sicher noch eine sinnvolle Anordnung, no Problem! >Der Canhacker kann Sequenzen senden ? Ja, man kann halt RX und TX Listen speichern und wieder reinladen und auch emfangene Daten in das Sendefenster rüberkopieren und dann wieder rausschicken. Aber mit dem Lawicel-Protokoll geht das ohnehin mit fast jedem Terminalprogramm. mit dem "Terminal G-A-System" kann man z.B. auch längere Scripts zusammenstellen, sogar mit Pausen zwischen den Zeilen etc. sehr praktisch! Es kommt halt immer drauf an, was man gerade für eine Funktion braucht. Dass ein CAN-Modul mit RS232-Ansteuerung keine Rakete ist sollte jedem von vorneherein klar sein, aber um ein paar vordefinierte CAN-Frames auf den Bus zu legen reichts allemal. >Mit dem ProfiLab Plugin kannst Du halt auch Muxer Nachrichten auswerten, ich weiß nicht ob ich die Unterstützung für Muxer in CanCool einbaue. Das ist jetzt nicht mein Problem, aber das ist ja auch schon eine ganz andere Größenordnung an Funktionalität. Das wäre ja schon eher als Plugin für erweiterte Darstellungsoptionen denkbar. Mir wäre ja schon eine richtig schön übersichtliche Darstellung der Daten aus einer wählbaren ID so als eigenes Fenster mit den acht Byte in HEX DEZ und Binär womöglich noch mit Balken (ist mir weniger wichtig, aber warum nicht, wenn man schon mal dabei ist) eine riesengroße Hilfe. Wie schon gesagt, das hat keiner für die empfangenen Daten, nur zum Senden, aber da weiss man ja meist was man will und kann es sich auch schnell mal ausrechnen oder aus einer Tabelle holen. Es sollte halt zeitnah reagieren und immer den aktuellen Zustand zeigen Wenn das ein paar Euro kostet, auch egal, aber halt nicht im oberen dreistelligen Bereich ;-) mfG Franz
Hallo Klaus, Nachdem ich endlich meinen Lawicel CAN232 wieder zurück habe konnte ich den mal anschliessen. (Can_Cool 1.00) Die Erkennung klappt schon mal, sowohl automatisch, wenn der Dongle schon steckt, wie auch nach "Can Controller reset" wenn ich den erst nach Programmstart anstecke, und ich empfange dann auch sinnvolle Daten! ob das Senden klappt konnte ich noch nicht testen, weil ich gerade keine Gegenstelle mit bekanntem Protokoll bzw einen zweiten Rechner mit CAN zur Verfügung habe. Wird noch nachgereicht, aber ein andermal..... Was mir ganz spontan nicht so gefiel: Wenn ich den Lawicel abstecke wird es vom Programm nicht erkannt, zumindest nicht gemeldet.Selbst bei "CAN-Controller Reset" bleibt unten die Meldung "OK" stehen. Mit freundlichen Grüßen Franz
Update CANcool :-) * Aufschlüsselung der CAN Daten in Dezimal, Hex, Binär, ASCII und als Balkenanzeige (Screenshot) * Bekannte CAN Nachrichten werden grün dargestellt * Bugs behoben * SL-CAN Treiber überarbeitet, keine Verzögerungen mehr beim Empfang und Senden von Daten. * SL-CAN Adapter mit USB (FTDI) Chip werden besser unterstützt. * Einstellung der Seriellen Baudrate bis 3M Baud, damit sollten die Adapter der Firma VSCom (theoretisch) funktionieren Download (Exe und Quellen): http://www.mhs-elektronik.de/userdata/downloads/can_cool.zip Grüße Klaus
Hallo Klaus, Das sieht alles schon sehr gut aus! Vor allem eben die Anzeigen, die ich mir schon so lange gewünscht habe funktionieren! Wenn ich allerdings den Tiny-Can I-XL bei laufendem Programm abstecke, dann hängt der PC bei 100% CPU-Auslastung fest und reagiert kaum noch. Da muss ich dann die Reset-Taste drücken. mfG Franz
Hallo, können Sie mir die genauen Infos geben, wie Sie das System angeschlossen haben und welche Komponeneten genutzt wurden? Ich nutze auch eine SL Heizung und würde es gut finden die Daten auf den PC abrufen zu können. Gruß und Danke Jens
Hallo Franz, die Aufschlüsselung der CAN Daten in Dezimal, Hex, Binär, ASCII und als Balkenanzeige usw. gibt's seit jeher auch im CANHacker. Dafür markiert man im Monitor Fenster die gewünschte Nachricht und klickt dann auf "Details" (Symbol mit der Lupe). Gruß Olaf
Nun ja CANCool kann schon noch deutlich mehr als der CANHacker. CANCool ist zudem Open Source, der CANHacker nicht! Die Software hat noch Potential sich zu entwickeln. :-)
Ja, CANHacker soll auch immer ein kleines , simples tool ohne viel overhead bleiben. Ich fand's nur so "tragisch" ;-), dass Franz jahrelang diese Funktion vermisst hat, obwohl sie doch schon immer drin war. Viel Erfolg mit Deinem Projekt, Klaus Gruß Olaf
Can Hacker bzw. SL Protokoll schluckt ja bekanntlich Nachrichten, weil die serielle Verdindung langsamer als die Can Baudrate ist. Die Erste Can Cool Version lief ja (glaube ich) über den SL Protokoll. Nun kann man ja zwischen Binär (treiber TinyCan) und SL auswählen. Ist es davon auszugehen, dass auf binär keine Nachrichten beim Tracen auf dem modernen FZG CAN mit 500kbaud verloren gehen? Danke Gruß Alex
Alex schrieb: > Can Hacker bzw. SL Protokoll schluckt ja bekanntlich Nachrichten, weil > die serielle Verdindung langsamer als die Can Baudrate ist. Stimmt eigentlich nicht ganz, Du kannst ja mit der Seriellen Übertragungsrate einfach höher gehen, die kleinen FTDI Chips können ja schon 3 MBit/s. Das Problem ist vielmehr die fehlende Datenflusskontrolle! > Die Erste Can Cool Version lief ja (glaube ich) über den SL Protokoll. Nein die lief nur mit den Tiny-CANs :-) > Nun kann man ja zwischen Binär (treiber TinyCan) und SL auswählen. Ich wollte das sich auch andere an der Entwicklung von CANcool beteiligen, deshalb die Unterstützung für die SL-CAN Module. Hat leider bis jetzt noch nicht funktioniert :-( > Ist es davon auszugehen, dass auf binär keine Nachrichten beim Tracen > auf dem modernen FZG CAN mit 500kbaud verloren gehen? Mit dem Tiny-CAN IV ist auch 1MBit/s kein Thema, zumindest mit CAN View und CanEasy. Wie performant CANcool ist habe ich bis jetzt noch nicht getestet. Leider ist es bei CANcool im Augenblick so das der GUI Thread auch die Trace Daten speichert. Grüße Klaus
Alex schrieb: > Can Hacker bzw. SL Protokoll schluckt ja bekanntlich Nachrichten, weil > die serielle Verdindung langsamer als die Can Baudrate ist. Wenn die Hardware es unterstützt (d.h. wenn ein FTDI Chip verbaut ist), sollte man unbedingt die Übertragung via D2xx Treiber wählen anstatt den Umweg über einen virtuellen comport zu gehen. http://www.ftdichip.com/Drivers/D2XX.htm Damit sollte auch bei hoher Buslast das SL Protokoll kein Problem darstellen. Oder man verwendet das Peak CAN USB Dongle (wird ebenfalls vom CANHacker unterstützt). Gruß Olaf
Olaf schrieb: > Ich fand's nur so "tragisch" ;-), dass Franz jahrelang diese Funktion > vermisst hat, obwohl sie doch schon immer drin war. ......Au weia!!!!!........ Ich war da wohl ein bisschen blind! Aber schön, es jetzt endlich nutzen zu können. @Olaf: Vielen Dank für den Hinweis, Ich nehme hiermit alle Beschwerden zurück! Sorry! Franz
Rolf Magnus schrieb: > Das Problem wird aber sein, daß sich wenige finden, an einem > OpenSource-Projekt dieser Art zu arbeiten. Privat brauchen eher wenige > so ein Tool, und die typischen Firmen aus der Branche scheuen sich meist > davor, ihre Entwickler dafür zu bezahlen, um an einer Software zu > arbeiten, die dann an die Konkurrenz verschenkt wird. Man schenkt es eher seinen Kunden... Wichtiger ist aus meiner Sicht aber, dass es keine Entwicklergemeinde gibt. Somit bleiben die Kosten an einer Firma hängen. Der Kundenkreis ist auch arg beschränkt. Damit ist auch nicht mit größeren Spendenaufkommen zu rechnen.
Hallo Klaus, anlässlich einer Neuentwicklung in meiner Firma konne ich jetzt mal so richtig intensiv einige Tage lang mit der Kombination Tiny-Can und CAN-COOL arbeiten, und das hat ganz hervorragend funktioniert. (auch mit CAN-View!) (kein Vergleich zum uralten Kommandozeilen-Tool in Verbindung mit einer damals schier unbezahlbaren Softing-Karte ;-) ) Für den Test sehr!! vieler verschiedener Kommandos war CAN-Cool besser geeignet, weil da mehr Zeilen ins Sendefenster passen. Performance war hier überhaupt nicht von Bedeutung. Zum Auswerten des Timings der Antworten im Vergleich zum Vorgängermodell war CAN-View besser geeignet, weil man da gesendete und empfangene Frames samt Timestamp im Trace darstellen kann. Auch die Möglichkeit Werte wahlweise auch als Dezimalzahl einzugeben ist da ein sehr praktisches Feature. Auch wenns inzwischen leider hier etwas ruhig geworden ist, habe ich nochmal zusammengefasst, was mir bei CAN-COOL so aufgefallen ist, bzw was noch gelegentlich mal verbessert werden könnte bzw sollte. Das Programm ist jetzt schon sehr brauchbar und viel zu gut um in einer Schublade zu verschwinden.... Folgende Dinge habe ich vermisst bzw sind mir aufgefallen: 1. ein Symbol zum Löschen des Trace mit einem Klick wäre schön. 2. Beim Trace sollten immer die letzten Zeilen sichtbar sein. 3. eine wahlweise Darstellung der gesendeten Frames im Trace wäre sinnvoll. 4. eine Möglichkeit, die "Sende-Liste" Zeile für Zeile nacheinander zu senden wäre schön, (habs aber noch nicht gebraucht) so müsste man auch kleinere Sequenzen schicken können. z.B.per TX-Mode "then next" so müsste man sogar auch noch eine Verzögerung einstellbar über "Period" hin bekommen. Apropos Sende-Liste hier wäre eine deutlichere Markierung der gerade "aktiven" Zeile sinnvoll. Problem: Wenn man oben in der Liste "Senden" bei einer Zeile anklickt, die nicht gerade unten editiert wird, dann wird das untere "Senden" dieser Zeile zugeordnet,aber die Werte werden so nicht in die Editier-Zeile übernommen. man kann dann unten schreiben was man will, es wird immer die zuletzt oben angeklickte Zeile gesendet wenn man unten auf Senden klickt. Erst wenn man auf den Text der jeweiligen Zeile klickt passts wieder. Nochmals vielen Dank für dieses wunderbare Programm! Franz
Hallo Franz, danke für deine Vorschläge, ich werde versuchen das meiste in der nächsten Version von CanCool einzupflegen. Leider ist die Zeit das größte Problem, an den „Tiny-CAN“ Projekt gibt es immer viel Arbeit, in der neuen Version habe ich die unterstützung für C#, Labview, Python verbessert, 1000 Bugs gefixt und sonst noch ein paar Keinichkeiten. :-) Ich hoffe das CanCool auch bald wieder an die reihe kommt :-) Vorher werde ich mir aber auf jeden Fall noch sie SL-CAN Implementierung zur Brust nehmen, damit sich das nicht mehr aufhängt. Grüße Klaus
Hallo Klaus, um mit schmalen Budget in die CAN-Welt einzusteigen habe ich mir den fischl.de/usbtin/ Adapter zusammengebaut. Leider liefert dieser am Antriebs-CAN (500 Kbit/s) von meinem VW scheinbar nur Blödsinn: - Mit CanCool äußert sich das so, dass teilweise IDs mit nur 1 oder 2 Ziffern dabei sind - Mit dem Tool Canhacker habe ich dann IDs wie 05t, 2t5, 5t2 und teilweise DLC von 0 Liegt das Ganze am USBtin? Ist das Teil zu langsam? Oder liegt es evtl an einer 'falschen Verkabelung'? - Das Kabelpaar zum Anschluss vom CAN ist verdrillt - Masse ist angeschlossen - Den 120Ohm Abschlusswiderstand hab ich weggelassen. (Der Bus ist ja schon irgendwo im Fahrzeug terminiert) Danke und Grüße Sven
Ich habe auch mehrere dieser Adapter gebaut und hatte schon bei 100kbit Probleme mit verschluckten Daten. Das liegt meiner Meinung nach an der USB Übertragung. Der Usb-Bulk-Transfer ist bei der Firmware auf 7Byte am Stück begrenzt. Das hat zur Folge, dass jede CAN-Nachricht in mindestens 2 USB Übertragungshäppchen gestückelt wird. Ich hatte für mich ein paar Änderungen an der Firmware gemacht, die meine Probleme lösten. Es wäre für mich auch interessant ob das bei dir hilft. Ich hänge die Firmware mal an. Und würde mich über einen Erfahrungsbericht freuen. Bei Erfolg gibt's das natürlich auch im Quellcode.
Hallo Sven > > Liegt das Ganze am USBtin? Ist das Teil zu langsam? Ja :-( Die Hardware wurde aber auch für solche Buslasten nicht gebaut! Du wirst auch mit anderen SL-CAN Adaptern kein Glück haben. Das liegt einfach an dem ASCII Protokoll und an den kleinen Controllern die da überall verbaut sind. Vielleicht bringt die Firmware von Jürgen ja Besserung :-) CAN Botschaften gehen aber auf jeden Fall verloren. > Oder liegt es evtl an einer 'falschen Verkabelung'? Nein! Ein CAN Controller empfängt Nachrichten "richtig" oder gar nicht, bei Fehlern wird ein Fehlerzustand am Bus erzeugt, worauf der Sender die Nachricht wiederholt, usw... Gruß Klaus
In der Version 1.3 der originalen Firmeware wurden auch schon Verbesserungen gemacht, die den Durchsatz erhöhen. Ich habe mal getestet bis zu welchen Bitraten das noch fehlerfrei läuft wenn ein LPC11C24 "Dauerfeuer" macht. Alles in allem muss man sagen, bei 125kbit ist Schluss. Für alles was schneller kommt, sollte man ein anderes Tool nehmen. Oder einen Filter setzen, wenn nur bestimmte Nachrichten interessieren. Der Buffer im Adapter ist ausserdem nur 128Byte groß, was auch ziemlich knapp ist. Dadurch ist es ziemlich sicher, dass bei Bitraten > 125kbit Nachrichten verschluckt werden, wenn sie nur schnell genug nacheinander kommen. Die Buslast selbst spielt dabei nicht mal die große Rolle. Meine Firmewareänderungen können die 250kbit und mehr auch nicht sicher bieten. Die 125kbit gehen aber problemlos. Selbst setze ich das nur bis 100kbit ein, da ich den Bootloader des LPC11C24 im Netz verwende und somit sowieso nicht mehr geht. Alles in allem bleibt aber bei der Auswahl des Adapters immer noch das Protokoll als Entscheidungsträger übrig. Flashmagic (NXP-Can Bootloader) kann nur Peak, Busmaster kann kein SLCAN, u.s.w. Bei Peak gibt's allein 3 verschiedene APIs. CanHacker verwendet Light-Api, Busmaster die CanApi2 und Flashmagic die Basic-Api. Manche Adapterhersteller bieten Wrapper-Dlls für die Peak-Api an, aber garantiert die die man gerade nicht braucht. Insofern ist das SLCAN Protokoll schon ganz gut, auch wenn es auf ASCI beruht.
Bei mir (Win7) zickt das Programm wenn ich es beenden will. "Unableto write to [...] \CanCool.prj" Auch wenn ich es als Admin ausführe und in den Dokumente-Ordner lege. Ich habe mir mit einem PIC32 einen LAWICEL-Clone gebaut, der USB-UART packt 2,5 oder 3 MBaud, leider kann der CanHacker (der ansonsten damit wunderbar funktioniert!) maximal 115200, dadurch geht bei 500kbps einiges verloren.
Danke Klaus und Jürgen für eure Rückmeldung. Hab jetzt wieder etwas mehr Zeit für das Thema und werde mal weiter rumprobieren. @Jürgen: Hatte vor einem Monat auch schnell noch eine Firmware compiliert mit der usb_cdc.c von dir: http://www.mikrocontroller.net/attachment/highlight/213096 Damit war es schon wesentlich besser. Hast du sonst noch andere Änderungen vorgenommen?
Eine neue Version von CAN-Cool ist fertig. Download (Exe und Quellen): http://www.mhs-elektronik.de/userdata/downloads/can_cool.zip * Tolle Button-Leiste :-) * Empfangene Nachrichten können ins Senden-Fenster kopiert werden * 1000 Bugs behoben :-) * Eine selektierte Nachricht wird im Senden-Fenster blau hinterlegt * Intervall Nachrichten können global freigegeben/gesperrt werden CAN Cool wurde jetzt mit Delphi 7 erzeugt. Bei der ersten Version waren zum Teil falsche Komponenten dabei, ich hoffe dieser Fehler ist auch behoben. Ich danke allen für die Vorschläge/Tests und hoffe auf weitere Anregungen. Grüße Klaus
Das macht Spass! Die Funktion des "Senden" Buttons oben habe ich zwar noch nicht verstanden, aber alles Andere ist für das was ich gerade damit mache bestens geeignet. Ich teste und protokolliere damit in der Firma eine lange Liste von CAN-Befehlen an einer Neuentwicklung....übrigens mit dem Lawicel232, während mein Kollege gerade mit meinem Tiny-Can arbeitet. Die Möglichkeit sich da eine Liste von Befehlen zusammenzustellen und durch einfaches Anklicken zu senden und auch schnell mal zu ändern ist da eine sehr große Hilfe.Das scheint jetzt fehlerfrei zu laufen. Was ich da noch vermisse ist die Möglichkeit mehrere oder einfach alle in der Liste nacheinander zu senden Bei der Digitalanzeige scheint es immer noch ein Problemchen zu geben. Wenn Nachkommastellen dazukommen, dann kommt da einfach eine Null nach dem Komma dazu, aber man bekommt da keinen Wert rein. Sinnvoller wärs doch, einfach den Punkt entsprechend zu setzen ohne die Zahl irgendwie zu verändern. In dem speziellen Fall wollte ich einen Wert der als 1/100 mm ankommt in x,xx mm darstellen. Das ist mir so nicht gelungen. Den Umrechnungsfaktor kann man ja problemlos in der Formel unterbringen. Nochmals vielen Dank für dieses tolle Programm! Franz
Hallo, ich habe mir den USBtin von fischl nachgebaut. Dieser funktioniert so weit einwandfrei. Nur bekomme ich ihn leider nicht mit can cool verbunden. Den Fehler mit den FTDI Treiber dll's bekomme ich auch. Nach dem ich die zwei dll's im bin Ordner lösche, ist dieser weg. In den Einstellungen wähle ich den entsprechenden COM Port so wie die Baudrate für RS232. Beim Verbinden mit dem gerät, kommt dann allerdings der Fehler: "Fehler beim öffnen des Device". In der Statusleiste von can cool steht unten Treiber dll nicht geladen. Als Betriebssystem nutze ich Windows 8.1. Ich habe es allerdings auch schon unter Windows 7 mit dem gleichen Ergebnis ausprobiert. Daher vermute ich, dass ich etwas falsch mache. Hat jemand einen Tipp? Gruß, Andy
:
Bearbeitet durch User
Hallo zusammen, sind die bekannten ELM327-Adapter zum Auslesen des CAN-Busses in Fahrzeugen auch mit dieser Software kompatibel? Danke und viele Grüße Klaus
Wohl eher nicht, die meisten Chinanachbauten können wider Erwarten NICHT loggen, was auf dem Bus abgeht.
Wie bekomme ich die Werteanzeige aktiviert? Bin da wohl zu unfähig. Was muss ich auswählen um die Werte dargestellt zu bekommen in einer Anzeige ? Danke schonmal Mfg Thomas
Thomas schrieb: > Wie bekomme ich die Werteanzeige aktiviert? Bin da wohl zu unfähig. Was > muss ich auswählen um die Werte dargestellt zu bekommen in einer Anzeige > ? Einfach auf "Neu..." klicken, Anzeige auswählen, über das Popup-Menü (rechte Maustaste) konfigurieren. Gruß Klaus
Gibt es noch irgendwo eine Anleitung wie das mit dem Berechnungsterm funktioniert, bzw. steht das d0 etc. für die Bytes die betrachtet werden sollen? MfG Thomas
Thomas schrieb: > Gibt es noch irgendwo eine Anleitung Leider gibt es keine Doku. >wie das mit dem Berechnungsterm > funktioniert, bzw. steht das d0 etc. für die Bytes die betrachtet werden > sollen? Genau so ist es, d0 steht für das Datenbyte 0, d1 für das Byte 1, usw... Grüße Klaus
Jürgen S. schrieb: > Kann das Ding Automobilprotokolle auswerten? Ich vermute jetzt mal Du meinst ODB II ? Nein, kann es nicht, das Programm ist aber Open Source. Wenn jemand Zeit und Lust hat stünde dem nichts im Wege :-) Grüße Klaus
Hi All . I want to know : Why Interceptor doesn't run with Lawicel interface ? Any help is welcome . Regards
Hallo, eine neue Version von CANcool hat das Licht der Welt erblickt! Das Problem mit den höheren Buslasten ist behoben :-) Ein Thread kümmert sich um die Echtzeit-Verarbeitung der Daten, ein weiterer Thread kümmert sich um die Visualisierung. Auch das Speichern eines Traces geschieht in einem eigenen Thread, so kann der Vorgang auch abgebrochen werden. Zu Beachten: * Das Programm benötigt die Installation des FTDI Treibers auch dann, wenn die benutzte Hardware keinen FTDI Chip verwendet. * Beim „Schnittstellen Setup“ darf „USB“ nur dann ausgewählt werden, wenn die Hardware einen FTDI Chip verwendet. * Zum Betrieb der Tiny-CANs ist die Installation des Tiny-CAN Software Pakets erforderlich. * Sollte die Verbindung zur Hardware nicht aufgebaut werden kann das auch über „Optionen -> Verbindung zur Hardware herstellen“ erfolgen. Das Programm ist nach Delphi 7 portiert. Eine CD-ROM mit Delphi 7 ist dem Buch „Delphi für Kids“ beigelegt (Erhältlich bei Amazon für 24,95 EUR). Tipp für Windows 10: Delphi 7 muss in einem eigenen Verzeichnis installiert werden, bei mir ist das „C:\data\Borland\Delphi7“. Die IDE läuft einwandfrei, obwohl Windows 10 das Gegenteil behauptet. Download (EXE und Quellen): http://www.mhs-elektronik.de/userdata/downloads/can_cool.zip Ich freue mich über Feedback... Grüße Klaus
Klaus D. schrieb: > Ich freue mich über Feedback... So, gerade ausprobiert. (Ich verwende eine selbst gebaute Hardware auf Basis eines Arduino nano China-Clons mit einem MCP2515. Firmware habe ich selber geschrieben.) Folgendes ist mir aufgefallen: im laufenden Betrieb habe ich das Setup-Fenster angeklickt. Dann dieses mit Abbrechen wieder geschlossen. Danach ist der Timestamp völlig daneben, siehe Bild. Schön wäre wenn man die Größe der Anzeigeelemente ändern könnte... Die Digitalanzeige im 7-Seg. Stil finde ich etwas schlecht ablesbar. Mir persönlich würde hier eine normale Schriftart (Arial,..) besser gefallen. Noch eine Frage: Wenn die CAN-Baudrate geändert werden soll, wann wird dann der entsprechende Befehl Sx an das Interface gesendet? Ansonsten funktionierts, Danke!
Hallo Thomas > > So, gerade ausprobiert. > (Ich verwende eine selbst gebaute Hardware auf Basis eines Arduino nano > China-Clons mit einem MCP2515. Firmware habe ich selber geschrieben.) Warum spinnen nur alle so auf den MCP2515 ? Es gibt so tolle Cortex-M3/M4 Controller mit CAN (ST, Cypress, ...) > > Folgendes ist mir aufgefallen: im laufenden Betrieb habe ich das > Setup-Fenster angeklickt. Dann dieses mit Abbrechen wieder geschlossen. > Danach ist der Timestamp völlig daneben, siehe Bild. Habe ich notiert :-) > > Schön wäre wenn man die Größe der Anzeigeelemente ändern könnte... Kann man ja auch, in der Instrumenten Konfiguration -> Größe (klein/mittel/groß) > > Die Digitalanzeige im 7-Seg. Stil finde ich etwas schlecht ablesbar. > Mir persönlich würde hier eine normale Schriftart (Arial,..) besser > gefallen. Da hast Du vielleicht sogar recht, nur sieht es halt dann nicht mehr so cool aus :-) > Noch eine Frage: Wenn die CAN-Baudrate geändert werden soll, wann wird > dann der entsprechende Befehl Sx an das Interface gesendet? Ja, der Treiber würde aber auch das schreiben des BTR Registers unterstützen, in CANcool ist das aber nicht integriert. Problem ist das jeder SL-CAN Adapter einen anderen CAN-Controller drauf hat, wie das dann lösen ? > > Ansonsten funktionierts, Danke! Danke Dir für das Feedback
Klaus D. schrieb: > Es gibt so tolle Cortex-M3/M4 Controller mit CAN (ST, Cypress, ...) Die 8-Bitter und den MCP2515 kenne ich halt schon. Für meine Hobbyprojekte reichen der 8 Bit aus. In die ARMs muss ich mich erst noch einarbeiten. >> Schön wäre wenn man die Größe der Anzeigeelemente ändern könnte... > Kann man ja auch, in der Instrumenten Konfiguration -> Größe > (klein/mittel/groß) Okay, hab ich dann wohl übersehen. >> Wenn die CAN-Baudrate geändert werden soll, wann wird >> dann der entsprechende Befehl Sx an das Interface gesendet? > Ja, der Treiber würde aber auch das schreiben des BTR Registers > unterstützen,.. Meine Frage war eher: Wird der Befehl Sx sofort gesendet sobald im Config-Fenster eine andere Baudrate gewählt wird oder erst später, z.B mit dem Start-Button? Und entspricht der Start-Button dem Lawicel-Befehl "O"? (Direktes Schreiben in Register habe ich in meiner Firmware gar nicht drinnen, somit kein Problem wenn das auch in der Software fehlt;-)
Thomas F. schrieb: > Meine Frage war eher: Wird der Befehl Sx sofort gesendet sobald im > Config-Fenster eine andere Baudrate gewählt wird oder erst später, z.B > mit dem Start-Button? > Und entspricht der Start-Button dem Lawicel-Befehl "O"? Bei folgenden Ereignissen: * Programm Start * Ändern der Konfiguration (Setup Fenster schließen) * Verbindung zur Hardware herstellen werden immer folgende Kommandos gesendet: C -> Close S -> CAN Speed Zx -> Timestamp O -> Open oder L -> Open Listen Only Der Start/Stop Button beeinflusst nur das Empfangsfenster Funktioniert deine Hardware nicht richtig mit CANcool ?
Klaus D. schrieb: > Funktioniert deine Hardware nicht richtig mit CANcool ? Manchmal werden keine Botschaften empfangen. Ich habe aber inzwischen noch einen Bug in meiner Firmware gefunden, bin aber noch nicht dazu gekommen diesen zu beheben.
CANcool ist jetzt im 1. Release verfügbar :-) Die Software ist im Tiny-CAN Softwarepaket (auf meiner Homepage) enthalten und auf GIT https://github.com/MHS-Elektronik/CANcool Der obige Link funktioniert immer noch. Ich habe aber die Projekt-Dateien geändert, ihr könnt also eure alten Projekte nicht mehr einlesen. Darum hier noch eine ältere Version: http://www.mhs-elektronik.de/userdata/downloads/can_cool_old.zip
Hallo Klaus, habe mir von GIT die exe und die beiden dlls geladen. Im Setup dann SL-CAN und RS232 (habe einen virtuellen USB-Port) ausgewählt. Dann erhalte ich folgende Fehlermeldung.
Thomas F. schrieb: > Hallo Klaus, > > habe mir von GIT die exe und die beiden dlls geladen. Im Setup dann > SL-CAN und RS232 (habe einen virtuellen USB-Port) ausgewählt. > > Dann erhalte ich folgende Fehlermeldung. Ups, welche Version von Windows benutzt Du denn ? Ich arbeite hier immer noch mit meinen geliebten XP :-) Unter Win10 habe ich nur die Tiny-CANs getestet. Zum Betrieb der Software muss in jedem Fall der FTDI Treiber installiert sein, egal ob Tiny-CAN oder SL-CAN
Klaus D. schrieb: > Ups, welche Version von Windows benutzt Du denn ? > Ich arbeite hier immer noch mit meinen geliebten XP :-) Ich habe Win 7 Pro 32 Bit. > Zum Betrieb der Software muss in jedem Fall der FTDI Treiber > installiert sein, egal ob Tiny-CAN oder SL-CAN. Hab ich drauf. Die Version 1.00 von CAN-cool fragt die FTDI-Treiber ja auch ab und die 1.00 funktioniert soweit.
Peter schrieb: > Der Schrott funktioniert nicht gescheit, habs aufgegeben. Was hast Du denn für ein Problem/Probleme ? Scheinst dich ja wohl ganz schön darüber geärgert zu haben wenn Du hier so einen Kommentar abgibst, nur mit dem Kommentar kann Dir halt auch keiner helfen!
Thomas F. schrieb: > Klaus D. schrieb: >> Ups, welche Version von Windows benutzt Du denn ? >> Ich arbeite hier immer noch mit meinen geliebten XP :-) > > Ich habe Win 7 Pro 32 Bit. > >> Zum Betrieb der Software muss in jedem Fall der FTDI Treiber >> installiert sein, egal ob Tiny-CAN oder SL-CAN. > > Hab ich drauf. > Die Version 1.00 von CAN-cool fragt die FTDI-Treiber ja auch ab und die > 1.00 funktioniert soweit. Hallo Thomas Ich habe das jetzt unter Win7 32Bit (Standard Version) getestet, ich kann Dein Problem nicht reproduzieren. Ich vermute es ist davon abhängig wie und wo die Dateien geschrieben werden. Vielleicht funktioniert es wenn Du die Dateien als Admin ins Windows Programm-Verzeichnis kopierst. :-) CANcool ist inzwischen auch im Tiny-CAN Software Paket enthalten. http://www.mhs-elektronik.de/index.php?module=download&action=file&id=51 Das Installationsprogramm schreibt die Dateien mit Admin rechten in das Programm-Verzeichnis, dann sollte es klappen.
Wieder mal ein Update, hoffe es funktioniert endlich mal gescheit :-) http://www.mhs-elektronik.de/userdata/downloads/can_cool.zip Grüße Klaus
Habs gerade entpackt und getestet: SL-CAN über RS232 V-Port:COM6 57600kBit Direkt nach der Konfiguration habe ich keine Anzeige der empfangenen Botschaften obwohl welche vom Interface gesendet werden. Nach Drücken von Busoffreset dann ein paar Botschaften. Nochmals Busoffreset: Jetzt gehts, aber der Timestamp ist wieder total daneben. Mehr habe ich nicht ausprobiert, Senden geht leider grad mit meiner Firmware nicht, da habe ich noch einen Bug drin.
Der Timestamp scheint mir um Faktor 10 zu langsam zu laufen. Meine Wiederholrate am Bus ist 1s. Angezeigt werden 100ms.
Hallo Thomas, ich kann deine Probleme nur zum Teil nachvollziehen. Wird das Device neu Konfiguriert oder zurückgesetzt (BusOff Reset) ist der Timestamp daneben, dieses Problem kann ich auch nicht lösen. Es wird der Timestamp in der Hardware zurückgesetzt und der Offset stimmt dann natürlich nicht mehr. Das 100ms/1s Problem kann ich nicht bestätigen, bei mir wird korrekt 100ms angezeigt. Wird die Übertragungsgeschwindigkeit im Setup geändert wird die Änderung tatsächlich erst nach drücken des BusOff Reset Buttons wirksam. Einmal drücken reicht aber :-) Bei den Tiny-CANs besteht dieses Problem nicht. Ich verwende: Tiny-CAN I mit SL-Firmware CANcool Version: 2.20 mhsslcan.dll Version: 2.00 Grüße Klaus
Hallo Klaus, danke für deine Software und für's zur Verfügung stellen :) Ist mittlerweile das Problem mit der FTDI-DLL behoben? Habe wie weiter oben geschrieben das Paket von FTDI installiert. Der Fehler bleibt der selbe, einen RS232 Wandler auf FTDI Basis habe ich leider nicht. Habe dann wie weiter geschrieben die 2 DLL's im BIN Ordner gelöscht und jetzt habe ich das Problem, dass die Meldung "Fehler beim öffnen des Device" kommt. In der Statusleiste steht Treiber DLL nicht geladen. Weiter oben wurde das Problem auch schon beschrieben, aber ich habe noch keine Lösung dazu gefunden. Mein System: Win 7 64-bit Arduino an Com-Port mit Lawicel Protokoll auf MCP2515 bzw. Arduino Due mit integriertem CAN Controller (aber das macht ja kein Unterschied bei diesem Problem) Ein Verbesserungsvorschlag: Statt der Auswahl des Com-Ports per Radiobutton eine Dropdown-Box oder Textfeld verwenden, da viele Com-Ports höhere Nummern haben und dann quasi zwangsumgestellt werden müssen :) Danke und LG Mat
Hallo Mat MAt schrieb: > Hallo Klaus, > > danke für deine Software und für's zur Verfügung stellen :) > > Ist mittlerweile das Problem mit der FTDI-DLL behoben? Nein, das ist auch kein Bug > > Habe wie weiter oben geschrieben das Paket von FTDI installiert. > Der Fehler bleibt der selbe, einen RS232 Wandler auf FTDI Basis habe ich > leider nicht. Die meisten haben halt irgend ein Gerät auf dem ein FTDI Chip verbaut ist :-) > > Habe dann wie weiter geschrieben die 2 DLL's im BIN Ordner gelöscht und > jetzt habe ich das Problem, dass die Meldung "Fehler beim öffnen des > Device" kommt. > In der Statusleiste steht Treiber DLL nicht geladen. Die hast Du gerade gelöscht :-) > > Weiter oben wurde das Problem auch schon beschrieben, aber ich habe noch > keine Lösung dazu gefunden. Du müsstest Windows dazu bringen den Treiber (FTDI) zu installieren obwohl die Hardware noch nicht verbunden ist. Also nicht als Pre-installed driver. Ich habe keine Ahnung wie das geht :-( Grüße Klaus
Klaus D. schrieb: >> Weiter oben wurde das Problem auch schon beschrieben, aber ich habe noch >> keine Lösung dazu gefunden. > Du müsstest Windows dazu bringen den Treiber (FTDI) zu installieren > obwohl die Hardware noch nicht verbunden ist. Ich habe die FTDI-Treiber-Bibliotheken von FTDI runtergeladen: http://www.ftdichip.com/Drivers/VCP.htm und dann händisch nach \Windows\System32\ kopiert. Das hatte bei mir ausgereicht. Ein Gerät mit FTDI-Chip für eine automatische Treibersuche+Installation habe ich auch nicht.
Hallo, können mit CAN-Cool auch Lawicel-kompatible Adapter verwendet werden, die per USB einen virtuellen COM-Port mit einer Portnummer größer 8 nutzen? Es ist kein FTDI-Chip sondern das USB-Modul eines STM32.
Jens E. schrieb: > einen virtuellen COM-Port mit einer Portnummer größer 8 nutzen? Wenn dir die Com-Port Nummer Kopfzerbrechen bereitet, ändere sie doch auf einen kleineren Wert.
Hola es posible usar Arduino con una shield can bus seestudio? CAN-BUS Shield adopts MCP2515 CAN Bus controller with SPI interface and MCP2551 CAN transceiver http://www.seeedstudio.com/wiki/CAN-BUS_Shield SAludos
Hallo, ist es möglich noch die CAN-Baudrate von 83,3kHz (Mercedes W203 Innenraum CAN) zu integrieren? MfG, Helmut
Die Software ist schon richtig gut. Einiges ist mir jedoch noch unklar: - Wie kann man aus CANcool gespeicherte Traces wieder einladen? - Kann man Traces auch "abspielen" sodass sich die Gauges, etc. ablesen lassen?
Hi, vielen Dank für dieses super Tool! Gibt es die Möglichkeit über die Analoganzeigen auch negative Werte darzustellen? Bisher habe dazu nichts finden können. Grüße und Dank, Bernhard
Die zweite Tasse Kaffee brachte mir heute die Erleuchtung. Anbei der Term für die Anzeige eines 16 bit signed integer: ((d1 << 8) + d0)-((d1 >> 7)*65535) Gruß, Bernhard
Beitrag #4988183 wurde vom Autor gelöscht.
Hi, habe angefangen mich mit CAN genauer zu befassen. Dafür wurde Hardware nachgebaut, der USBtin. Dabei ist man natürlich auch über diese Software gestoßen. Dafür zunächst Dank. Aber leider sind auch paar negative Punkte aufgefallen. Zunächst wäre es super, wenn nicht nur COM1 bis COM8 auswählbar wären. Kommt leider auch vor, dass Windows COM9, COM12 oder COM21 vergibt... Noch toller wäre es natürlich, wenn das Tool nur die vorhandenen Anschlüsse auflistet, wie andere Tools dies machen. Dann könnte man sich auch den Blick in den Gerätemanager sparen. Dann ist es etwas komisch, dass man sich nur verbinden kann, ein trennen aber nicht möglich ist. Zwar wird der COM-Port nicht blockiert und ein BusOff Reset ist möglich, falls es Probleme gibt, warum aber kein BusOff, bzw. Verbindung zur Hardware trennen? Laut LAWICEL wäre der Befehl um den CAN-Kanal zu schließen C[CR]. Eine Option ob eine Verbindung bei Programmstart hergestellt werden soll wäre sicher auch ganz schön. Scheinbar ist das senden von Nachrichten nicht sauber implementiert. Es kommt hin und wieder zu Problemen. Es scheint sich das CAN-Modul in der auf der anderen Seite befindlichen Hardware zu verabschieden. Dieses Phänomen ist definitiv reproduzierbar unter folgenden Gegebenheiten: CANcool mit angeschlossener Hardware. Gegenstelle, die über CAN verbunden ist. (mal von 2 Teilnehmern ausgegangen) Gegenstelle ist konfiguriert bei entsprechender empfangener Nachricht selber eine Nachricht zu schicken. Konfiguriert man nun CANcool mit einer passenden zu schickenden Nachricht, mit "TX Mode" auf "Trigger" und mit richtig eingestellter "Trigger ID", so wird nach dem abschicken dieser Nachricht eine neue Empfangen und daraufhin eine neue über den Trigger verschickt. Dies läuft so lange gut, bis man mitten drinnen erneut Paar mal (zwei-, dreimal) auf den Button Senden klickt. Dies lässt sich auch herbeirufen, wenn der Senden-Button extrem oft nacheinander betätigt wird. Ein Reset der Gegenstelle ist hierbei ein Problemlöser. Dabei sei auch angemerkt, dass Shortcuts ganz angenehm sein könnten, um entsprechend angefertigte Nachrichten abzusetzen. z.B. über den Num-Block Tasten 0-9 etc... Damit wäre das senden vereinfacht und Aufmerksamkeit könnte auf den Empfangenen Daten liegen, während über die Tasten auf der Tastatur entsprechende Nachrichten verschickt werden... Der Verbindungsaufbau zur "RS232 zu CAN"-Schnittstelle scheint nicht besonders robust zu sein. Es war teilweise ein Glücksspiel eine Verbindung aufzubauen. Es kam meist zu undefinierten CAN-Fehlern beim verbinden. Es ist dabei auszuschließen, dass der Lochrasterplatinenaufbau der Hardware dafür verantwortlich ist, da andere Tools ihre Arbeit klaglos aufnehmen bei den gleichbleibenden Bedingungen. Ein vertauschen der CANH und CANL Leitung beseitigt kurioserweise diesen Fehler, natürlich ist eine Datenübertragung dann nicht möglich, auch wenn die Statusleiste positives Feedback gibt. Eine Implementierung der PlotLab library von Mitov Software, welche auch für Delphi vorliegen soll wäre sicher eine schöne Sache. SignalLab zum senden wäre sicher auch was. Hoffentlich sind paar der Beobachteten Marotten nachvollziehbar und korrigierbar.
P. S. schrieb: > Hi, > > habe angefangen mich mit CAN genauer zu befassen. > Dafür wurde Hardware nachgebaut, der USBtin. > Dabei ist man natürlich auch über diese Software gestoßen. > Dafür zunächst Dank. > > Aber leider sind auch paar negative Punkte aufgefallen. > > Zunächst wäre es super, wenn nicht nur COM1 bis COM8 auswählbar wären. > Kommt leider auch vor, dass Windows COM9, COM12 oder COM21 vergibt... > Noch toller wäre es natürlich, wenn das Tool nur die vorhandenen > Anschlüsse auflistet, wie andere Tools dies machen. Dann könnte man sich > auch den Blick in den Gerätemanager sparen. Wenn deine Hardware einen FTDI Chip drauf hat brauchst Du nur USB auswählen und ggf. die Seriennummer eintragen. Die COM Ports lassen sich unter Windows auch neu zuweisen. Die Einstellung 1 - 8 ist ausreichend. Die Umstellung muss man ja nur einmal machen. > > Dann ist es etwas komisch, dass man sich nur verbinden kann, ein trennen > aber nicht möglich ist. Zwar wird der COM-Port nicht blockiert und ein > BusOff Reset ist möglich, falls es Probleme gibt, warum aber kein > BusOff, bzw. Verbindung zur Hardware trennen? Laut LAWICEL wäre der > Befehl um den CAN-Kanal zu schließen C[CR]. > Eine Option ob eine Verbindung bei Programmstart hergestellt werden soll > wäre sicher auch ganz schön. Kann ich nicht versprechen ob das kommt, die Verbindung zu trennen wäre schon sinnvoll :-) > > Scheinbar ist das senden von Nachrichten nicht sauber implementiert. > Es kommt hin und wieder zu Problemen. Es scheint sich das CAN-Modul in > der auf der anderen Seite befindlichen Hardware zu verabschieden. > Dieses Phänomen ist definitiv reproduzierbar unter folgenden > Gegebenheiten: > CANcool mit angeschlossener Hardware. > Gegenstelle, die über CAN verbunden ist. (mal von 2 Teilnehmern > ausgegangen) > Gegenstelle ist konfiguriert bei entsprechender empfangener Nachricht > selber eine Nachricht zu schicken. > Konfiguriert man nun CANcool mit einer passenden zu schickenden > Nachricht, mit "TX Mode" auf "Trigger" und mit richtig eingestellter > "Trigger ID", so wird nach dem abschicken dieser Nachricht eine neue > Empfangen und daraufhin eine neue über den Trigger verschickt. > Dies läuft so lange gut, bis man mitten drinnen erneut Paar mal (zwei-, > dreimal) auf den Button Senden klickt. > Dies lässt sich auch herbeirufen, wenn der Senden-Button extrem oft > nacheinander betätigt wird. Ein Reset der Gegenstelle ist hierbei ein > Problemlöser. Wenn diene CAN Hardware abstützt kann CANcool nichts dafür :-) > Dabei sei auch angemerkt, dass Shortcuts ganz angenehm > sein könnten, um entsprechend angefertigte Nachrichten abzusetzen. z.B. > über den Num-Block Tasten 0-9 etc... Damit wäre das senden vereinfacht > und Aufmerksamkeit könnte auf den Empfangenen Daten liegen, während über > die Tasten auf der Tastatur entsprechende Nachrichten verschickt > werden... Die Software ist Open Source, jeder kann das Programm nach seinen Vorstellungen erweitern. > > Der Verbindungsaufbau zur "RS232 zu CAN"-Schnittstelle scheint nicht > besonders robust zu sein. Es war teilweise ein Glücksspiel eine > Verbindung aufzubauen. Es kam meist zu undefinierten CAN-Fehlern beim > verbinden. Was meinst Du mit undefinierten CAN-Fehlern ? Soweit mir bekannt funktioniert CANcool mit den USBtin einwandfrei, nur bei hohen Buslasten kommt es zu Problemen. > Es ist dabei auszuschließen, dass der Lochrasterplatinenaufbau der > Hardware dafür verantwortlich ist, da andere Tools ihre Arbeit klaglos > aufnehmen bei den gleichbleibenden Bedingungen. Welche Tools ? > Ein vertauschen der CANH und CANL Leitung beseitigt kurioserweise diesen > Fehler, natürlich ist eine Datenübertragung dann nicht möglich, auch > wenn die Statusleiste positives Feedback gibt. > > Eine Implementierung der PlotLab library von Mitov Software, welche auch > für Delphi vorliegen soll wäre sicher eine schöne Sache. SignalLab zum > senden wäre sicher auch was. Die Software ist Open Source, es werden nur Open Source Bibliotheken benutzt.
Klaus D. schrieb: > Die COM Ports lassen sich unter Windows auch neu zuweisen. Die > Einstellung 1 - 8 ist ausreichend. Die Umstellung muss man ja nur einmal > machen. ich hatte vor Ewigkeiten mal ne kleine Lib für die Serielle Schnittstelle geschrieben, die hat eine Schnittstellensuche drin: Beitrag "PortableSerialLib - Portable Serial Port Library" Da hatte ich mich ein weilchen mit beschäftigt :) Vielleicht hilft es dir ja. Das Konzept der Lib passt eventuell nicht, aber das Finden aller Vorhandenen und das Öffnen beliebig benannter Serieller Schnittstellen hilft vielleicht.
Vielen Dank für die Antwort, schön, dass hier noch Leben ist. >Wenn deine Hardware einen FTDI Chip drauf hat brauchst Du nur >USB auswählen und ggf. die Seriennummer eintragen. Nein, leider nicht, bzw. vielmehr glücklicherweise. Ohne FTDI geht es halt weniger aufwendig. Außerdem muss man nicht befürchten kein Original erwischt zu haben, was dann dazu führt, dass man angeschmiert ist. > Die COM Ports lassen sich unter Windows auch neu zuweisen. Die > Einstellung 1 - 8 ist ausreichend. Die Umstellung muss man ja nur einmal > machen. > Ja sicher lassen sich diese neu zuweisen, auf Rechnern allerdings, wo man dafür nicht die Berechtigung hat, eben auch nicht. Im Endeffekt soll diese Software eine bessere Alternative zum bisher bestehendem sein, für eine Lehr- und Forschungseinrichtung. Vor Jahren wurde aus der Notwendigkeit entsprechendes geboren. Da ich letztens krank war und mich mit CAN endlich einmal intensiver befassen wollte, habe ich diese Gelegenheit genutzt zum eintauchen in diese Thematik. Dafür habe ich mir auch entsprechendes ausgeliehen, bin damit jedoch damit nicht weiter gekommen, weswegen über den Tellerrand geschaut wurde. Das vorhandene hätte man überall angehen müssen etc. Wenn es jedoch schon direkt große Probleme gibt, und es ist ein großes Problem, wenn jemand kommen muss, um mal eben einen virtuellen Com-Port zu verändern, dann kann man kaum Überzeugungsarbeit leisten. Die bisherige Software bietet zumindest die Auswahl aus COM1 bis COM12 an, dass hat dann in den meisten Fällen tatsächlich geklappt. Mit dem Open Source CAN-Bus Analyse Tool konnte deswegen schon auf den drei auspropierten PCs nicht gearbeitet werden, wegen der COM-Port Auswahl. > Kann ich nicht versprechen ob das kommt, die Verbindung zu trennen wäre > schon sinnvoll :-) Schon einmal vielen Dank dafür. > Wenn diene CAN Hardware abstützt kann CANcool nichts dafür :-) > Dazu kann ich noch nichts sagen. Konnte heute einen Can-Analyser anschließen, aber in dieser Hinsicht gab es keine Erkenntnisse. Es konnte so nichts ungewöhnliches aufgespürt werden. Es ist zu vermuten, dass der Senden-Button dazu führt, dass eine neue Nachricht verschickt wird, während eine alte am senden ist. Aber dazu wäre dann ein Oszilloskop anzuschließen. Oder vielleicht könnte man auch die Seriellen Daten erfassen, die zwischen PC und USBtin anfallen, was jedoch schwierig ist, ohne anzapfbare serielle Daten. Der weg von Open Source CAN-Bus Analyse Tool über USB auf TX und über einen weiteren Wandler von RX auf USB und Terminal-Programm wird wohl wegen den benötigten Antworten auch nicht so einfach sein. Vielleicht eher ein µC, der entsprechend reagiert und die Daten, die er empfängt an ein Terminalprogramm ausgibt... naja, zunächst mal ein Oszi versuchen... Aber anders ist das Verhalten vom Empfänger nicht zu erklären, warum CAN dann nicht mehr reagiert, nach dem provozieren dieser Reaktion. Soll aber natürlich nicht heissen, dass man da auch nachhakt, solche Fehler abzufangen und CAN weiter lauffähig zu halten... > Die Software ist Open Source, jeder kann das Programm nach seinen > Vorstellungen erweitern. Ja, das stimmt. Ist auch ein großer Vorteil und sicher dann ein ToDo für die Zukunft... >Was meinst Du mit undefinierten CAN-Fehlern ? >Soweit mir bekannt funktioniert CANcool mit den USBtin einwandfrei, nur >bei hohen Buslasten kommt es zu Problemen. Als Anhang ist ein screenshot von der Statusleiste mit dem CAN-Status CAN: Unbek. Fehler. Was diesen Fehler Verursacht ist unbekannt. mit z.B. USBtinViewer war eine Verbindung direkt möglich. Mit can_cool waren viele Versuche nötig, bis eine Verbindung erfolgreich bestand. Aber das auch noch weiter beobachtet... Nur Mysteriös, dass ein falsch angeschlossener CAN-Bus zu einem OK führt... > Welche Tools ? USBtinViewer CANHacker und Hterm, welches ein Adäquates Terminal-Programm zum nicht vorhandenem Windows-Terminal-Programm ist. Passende Sequenzes zum USBtin gibt es praktischerweise auch direkt. > Die Software ist Open Source, es werden nur Open Source Bibliotheken > benutzt. War nur ein Vorschlag, da PlotLab auch Open Source ist. Da ich heute einen CAN-Analyser angeschlossen hatte, der auch Error-Frames ausgespuckt hat, siehe Anhang, habe ich das Gefühl, dass CANcool diese nicht beachtet, oder doch? Eine Visuelle Darstellung wie im Anhang wäre toll. Lawicel beachtet eigentlich das Status-Flag... Das erklärt auch, warum CAN auch schon mal tot ist und man sich wundert, warum es nicht geht. Ob dies auch den Can-Status: Unbek. Fehler verursacht bzw. zu den Schwierigkeiten mit dem Verbinden führt? Da muss wohl noch mal der andere Analyser dran... Es wäre eigentlich auch ganz schön, wenn das Fenster für die Empfangenen Daten nicht nur für empfangene Daten wäre, sondern für den Datentransfer. Es wäre schön zu sehen, welche Daten empfangen und gesendet wurden mit entsprechender Kennzeichnung der gesendeten und empfangenen Daten (Icon, oder TX/RX)...
Hallo, wie wäre es wenn man eine passende Hardware entwickelt die auch 1 Mbit handeln kann? Ich dachte an Arm mit Usb und Can "On Chip". Wahrscheinlich muss man dann das Protokoll anpassen um den Durchsatz zu schaffen. Das ganze dann auch Open Source. Wäre doch super oder übersehe ich etwas? Gruß
Rene Z. schrieb: > Hallo, > > wie wäre es wenn man eine passende Hardware entwickelt die auch 1 Mbit > handeln kann? Ich dachte an Arm mit Usb und Can "On Chip". > Wahrscheinlich muss man dann das Protokoll anpassen um den Durchsatz zu > schaffen. Das ganze dann auch Open Source. Wäre doch super oder übersehe > ich etwas? > > Gruß Es ist doch so, dass die Übertragungsrate einstellbar ist. Deshalb ist die Frage, ob man unbedingt Hardware braucht, die 1 Mbit/s bei voller Buslast perfekt kann... Aktuell würde ich dies so betrachten, dass man einen 2. Schritt vor dem 1. machen möchte. Hatte heute mal Zeit weiter CANcool anzuschauen. Es wurde ein Bus mit dem USBtin aufgebaut, der eigentlichen Hardware, auf der gerade CAN in Betrieb genommen wird, eine andere Hardware, auf der CAN läuft und ein Komerzieller CAN-Analyser. Diesmal war das benutzen von CANcool unproblematischer, mit etwas mehr Achtsamkeit beim Aufbau des Bus. Dennoch verliert das Tool schnell die Verbindung. Beim Senden von Nachrichten kommen definitiv die Probleme. Das komplette Tool hängt sich sogar auf, mindestens Kommunikationsprobleme treten auf. Es können weder Nachrichten gesendet noch empfangen werden. Laut CAN-Analyser läuft der CAN-Bus dabei weiterhin und ohne Fehler. Auch ist die Hardware, also USBtin nicht das Problem. Mit der Software USBtinViewer gibt es diese Probleme nicht. Die Software läuft permanent gut. Nachrichten werden wie zu erwarten verschickt und empfangen. Auch das betätigen vom Sende-Button führt zu keinen erkennbaren Problemen, wie es mit CANcool zu beobachten war. Es wurde also bloss eine andere Software für USBtin verwendet ohne auch nur irgend etwas an der Hardware anzupacken. Dieser Umstand ist schon sehr Schade. CANcool ist ein sehr schönes Tool und bietet sehr schöne Features. Mit den beobachteten Problemen und der Unzuverlässigkeit beim verbinden und betreiben ist es aber dann doch leider so aktuell nicht nutzbar. Hoffentlich lässt sich dies ändern. Definitiv liegt der Fehler in CANcool, da der BUS sauber läuft und Nachrichten weiterhin mit dem CAN-Analyser zu beobachten waren und die Probleme mit dem anderem Tool nicht zu beobachten sind.
Ach ja, auf http://www.kreatives-chaos.com/artikel/can-debugger wird wohl entsprechende Hardware vorgestellt... "Ein kleiner Adapter um auch einen CAN Bus bei 1 MBit mit voller Auslastung mithören zu können." ob das Projekt noch lebt... von der CAN-Software hört man jedoch nicht so viel... und etwas viele Bauteile...
P. S. schrieb: > Ach ja, auf http://www.kreatives-chaos.com/artikel/can-debugger > wird > wohl entsprechende Hardware vorgestellt... > "Ein kleiner Adapter um auch einen CAN Bus bei 1 MBit mit voller > Auslastung mithören zu können." > > ob das Projekt noch lebt... > von der CAN-Software hört man jedoch nicht so viel... > und etwas viele Bauteile... Davon habe ich hier zwei liegen. Wollte immer schon mal was an der Firmware ändern. Nie Zeit gehabt.
> Davon habe ich hier zwei liegen. Wollte immer schon mal was an der > Firmware ändern. Nie Zeit gehabt. Hm, ok. Und die gehen nicht bei 1 Mbit? Wofür soll die Änderung sein? Was für eine Software wird mit denen benutzt? CANcool macht da bisher den besten Eindruck, aber leider läuft es so instabil, dass man es nicht benutzen kann. Am Anfang hat es noch funktioniert, als auf dem CAN kaum Daten übertragen wurden, aber beim letzen versuch hat ein Teilnehmer im 6mS-Takt gesendet, da wurde alles sehr unstabiel und die Software hat ihre Arbeit eingestellt oder sich nach dem Sendeversuch komplett verabschiedet. Ohne gute Software auf dem PC bringt halt auch die beste CAN-Hardware nichts. DBC-File Support etc. braucht man sich dann auch nicht zu wünschen... Das Problem liegt halt dann darin die Ursache dafür zu finden, ist dann alles nicht so einfach. Hoffentlich können wenigstens diese Probleme reproduziert werden...
P. S. schrieb: > Wofür soll die Änderung sein? z.B. "Im Lawicel-Modus werden noch keine Filter unterstützt, es werden immer alle Nachrichten weitergeleitet." Eigentlich braucht man ja nur: 1. Bitrate einstellen, sxxyyzz[cr] 2. Filter setzen, mxxxxxxxx[cr] und Mxxxxxxxx[cr] 3. Nachricht schreiben, tiiildd..[cr], Tiiiiiiiildd..[cr], riiildd..[cr], Riiiiiiiidd..[cr] 3. Can starten, O[cr] 4. Can beenden, C[cr] Timestamp wird immer mitgesendet und Statusmeldungen gibt es wenn ein Fehler aufgetreten ist sonst nicht. Bis auf eine Mob gehen alles auf Eingang und die verbleibende wir zum senden benutzt. Das reicht doch um sich den Canbus anzuschauen und gelegentlich was zu senden. Man stellt die Bitrate ein, setzt wenn nötig die Filter und startet die Canverbindung. Jetzt werden alle anstehenden Nachrichten zum Pc gesendet bis die Canverbindung beendet wird. Wenn eine Nachricht auf den Bus gesendet werden soll wird sie halt vom Pc aus übertragen. Alles andere ist meiner Meinung nach Sache des wesentlich potenteren Pc. Gruß Rene
:
Bearbeitet durch User
Hallo > DBC-File Support etc. braucht man sich dann auch nicht zu wünschen... Es gibt ja auch noch den Busmaster von Etas, da kannst Du DBC Files importieren. Ist übrigens auch Open Source. > Das Problem liegt halt dann darin die Ursache dafür zu finden, ist dann > alles nicht so einfach. Hoffentlich können wenigstens diese Probleme > reproduziert werden... Leider nicht, ich habe keine USBtin Hardware, ich benutze immer ein Tiny-CAN mit SL Firmware und da treten keine Probleme auf. Ich habe eine Spezialversion von CANcool gemacht, diese Version erzeugt die Datei log.txt in der alle Fehler abgespeichert werden. Bitte schick mir diese Datei per Mail an klaus@mhs-elektronik.de Download Spezialversion: http://www.mhs-elektronik.de/userdata/downloads/CanCoolTest.zip Ich hoffe ich kann dann feststellen was hier schief läuft. :-) Grundsätzlich läuft CANcool schon sehr stabil und kommt auch mit 100% Buslast bei 1MBit/s klar, entsprechende Hardware natürlich vorausgesetzt. Grüße Klaus
Hi Klaus D. schrieb: > Hallo > > Es gibt ja auch noch den Busmaster von Etas, da kannst Du DBC Files > importieren. Ist übrigens auch Open Source. Ja, der scheint aber keine "LAWICEL type hardware" zu unterstützen. Aktuell kann man in Version 3.2.0 folgende Hardware auswählen: ETAS BOA ETAS ES581.3 ETAS ES581.4 ETAS ES582.1 ETAS ES58 IAOLAR-EVE i-VIEW InterpidCS neoVI IXXAT VCI Kvaser CAN MHS Tiny-CAN NSI CAN-API PEAK USB VECTOR XL VScom CAN-API > Leider nicht, ich habe keine USBtin Hardware, ich benutze immer ein > Tiny-CAN mit SL Firmware und da treten keine Probleme auf. > > Ich habe eine Spezialversion von CANcool gemacht, diese Version erzeugt > die Datei log.txt in der alle Fehler abgespeichert werden. Bitte schick > mir diese Datei per Mail an klaus@mhs-elektronik.de > > Download Spezialversion: > http://www.mhs-elektronik.de/userdata/downloads/CanCoolTest.zip > > Ich hoffe ich kann dann feststellen was hier schief läuft. :-) > > Grundsätzlich läuft CANcool schon sehr stabil und kommt auch mit 100% > Buslast bei 1MBit/s klar, entsprechende Hardware natürlich > vorausgesetzt. > > Grüße > Klaus Vielen Danks. Das ist super. Werde mal schauen... Gruß
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.