Hallo erstmal, ich bin mir noch nicht ganz schlüssig, wie ich mein CAN Protokoll aufziehen soll. Und zwar verwende ich einen CAN Dongle der am PC angeschlossen ist. Des weiteren habe ich noch drei XC888 Boards mit jeweils einem CAN Knoten. Der CAN Dongle und die drei Boards sind alle an einem CAN Bus angeschlossen. Jetzt habe ich mir zuerst überlegt, ich verwende das Message Objekt Nr. 0. Dieses lässt alle CAN Nachrichten durch, das heisst ich kann nach der gewünschten CAN ID prüfen. Jedes XC888 Board erhält noch zwei weitere Messaeg Objekte die zum Senden verwendet werden. Sobald ich vom CAN Dongle eine CAN Nachricht auf den Bus sende, dann soll z.B. der Teilnehmer 1 (XC888 Board) diese interpretieren und dann die Nachricht an den Teilnehmer 2 (XC888 Board) senden). Die Software auf den XC888 Boards soll einheitlich sein. Nur die Baugruppenadresse sind unterschieldich. Die Anfrage vom CAN Dongle soll dann so ungefähr aussehen wie bei dem CANOPEN Protokoll das SDO. Hat jemand noch einen weiteren Vorschlag wie ich sowas realisieren könnte?
Aufbau Telegramm zur Anforderung (CAN Dongle): 11 Bit ID: Nummer 1 bis 5 (Anzahl der Anforderungen vom CAN Dongle) 1 Datenbyte = DLC 2 Datenbyte = Quelle Baugruppenadresse 3 Datenbyte = Quelle Message Objekt Nummer 4 Datenbyte = Ziel Baugruppenadresse 5 Datenbyte = Ziel Message Objekt Nummer Auf den XC888 Boards müsste ich dann diese Anforderungen vom CAN Dongle interpretieren und dementsprechend eine Nachricht senden.
Für jede Anregung bin ich sehr dankbar! Hat jemand vielleicht eine bessere Lösung?
Hi ole! Was meinst du mit "nö" ? Ist meine vorgeschlagene Lösung sinnvoll?
> Jetzt habe ich mir zuerst überlegt, ich verwende das Message Objekt Nr. > 0. Dieses lässt alle CAN Nachrichten durch, das heisst ich kann nach der > gewünschten CAN ID prüfen. So verlierst du effektiv 11-29 Bits an übertragener Information. Dafür benötigst du nicht die ID 0, sondern kannst den CAN-Controller auch so programmieren, dass er alle Objekte durchlässt. Ich stand vor einem ähnlichen Problem und habe mich der Einfachheit/Einfallslosigkeit halber an LAN-Adressierung orientiert. Ob das nun die ideale Lösung ist will ich mal offen lassen. CanOPEN war mir schlicht zu kompliziert, ich wollte das in einem Mega8 unterbringen und weder der MCP2515 noch der LPC2129 können etwas mit Message-Objekten anfangen (BasicCAN). Ich verwende dafür die erweiterte 29-Bit-Adressierung. Aufgeteilt in <n1> Bits Quelladdresse inkl. einer Broadcast-Adresse, <n2> Bits Zieladresse und die übrigens Bits für Funktionscode und ggf. noch ein paar Parameterbits. In die Parameterbits passt so beispielsweise auch die Positioninfo eines Text-LCDs rein, so dass der ganze Dateninhalt der Message für den LCD-Text verwendbar bleibt. Die in die ID eingebaute Quelladresse dient dabei hauptsächlich der Notwendigkeit, die CAN-ID eindeutig zu machen. Dynamische Verwaltung von IDs, Kataloge und was CanOPEN noch so alles hat habe ich mir erspart.
Hallo Patrick, >Sobald ich vom CAN Dongle eine CAN Nachricht auf den Bus sende, dann >soll z.B. der Teilnehmer 1 (XC888 Board) diese interpretieren und dann >die Nachricht an den Teilnehmer 2 (XC888 Board) senden). Du hast wohl das CAN-Konzept nicht ganz verstanden!!!??? Jeder Teilnehmer list ja die CAN-Botschaften auf dem Bus und wenn sie für Ihn relevant ist beachtet er sie. Im anderen Fall verwirft er sie. Keiner braucht also Botschaften weiterzureichen.
Patrick wrote: > Hi ole! > > Was meinst du mit "nö" ? Ist meine vorgeschlagene Lösung sinnvoll? Wer soll denn sagen können ob das so sinvoll ist? Es gibt halt kein fertiges Protokoll, daß für jeden Anwendungszweck optimal ist. Mein Vorschlag, so wie ich es immer mache: Nimm Dir einen Stapel Schmierpapier und einen Bleistift. Überlege Dir, was für Informationen Du übertragen willst und überlege Dir dann ein sinvolles Protokoll. Ich bastele seit Ewigkeiten an einem Hausbus und habe schon mindestens siebzehnmal das Protokoll über den Haufen geworfen, weil mir immer neue Anforderungen einfallen. Also, ein bischen eigene Kreativität musst Du schon entwickeln. Und dann heisst es umsetzen und schauen ob das Ganze in der Praxis funktioniert. siehe auch: http://de.wikipedia.org/wiki/Kontinuierlicher_Verbesserungsprozess Gruß, eddi
Hallo Hardy, du hast geschrieben: "Du hast wohl das CAN-Konzept nicht ganz verstanden!!!??? Jeder Teilnehmer list ja die CAN-Botschaften auf dem Bus und wenn sie für Ihn relevant ist beachtet er sie. Im anderen Fall verwirft er sie. Keiner braucht also Botschaften weiterzureichen." Ich muss doch genau genau sagen, welche Daten ich woher und wohin sie gesendet werden sollen. Ich hab doch eine XC888 Boards die ich mit dem CAN Dongle ansprechen will. Mit dem CAN Dongle möchte ich entscheiden, woher die Daten und wohin sie gesendet werden sollen. Oder gibt es da noch eine andere Möglichkeit? Ich meine nein!
> Ich muss doch genau genau sagen, welche Daten ich woher und wohin sie > gesendet werden sollen. Grundsätzlich kriegt jeder Teilnehmer am CAN-Bus jede Message mit. Dabei kann dessen Controller so eingestellt werden, dass er nur bestimmte IDs rausfischt. Kann aber auch so arbeiten, dass alle Messages empfangen werden. Es ist also nicht der Absender, der den Adressaten aussucht. Sondern der Busteilnehmer der die ihn nicht betreffenden Messages verwirft.
Tja und wie könnte man z.B. dies verwirklichen? Definitiv muss ich doch von einer Stelle aus sagen, was gemacht wird. Also jetzt bin ich verwirrt.
Jede CAN Nachricht hat eine ID. Anhand der ID bestimmst du den Empfänger. Wenn du eine Nachricht schicken willst, schreibst du sie auf den Bus. Nun liest jeder CAN Teilnehmer die Nachricht und entscheidet dann ob sie für ihn ist oder nicht. Du musst also in jedem Teilnehmer konfigurieren, welche IDs er verwerten soll und welche nicht. Du adressierst mit einer ID also keinen Empfänger in dem Sinne, sondern du konfigurierst die Empfänger dahingehend, dass du sagst welche IDs sie verabeiten sollen und welche nicht.
Hallo MisterT, kannst du mir ein konkretes Zahlenbeispiel geben?
Teilnehmer1: Teilnehmer2: Teilnehmer3: CAN-Dongle LED LED LED gibt Anweisungen was zu tun ist Schalter Schalter Schalter Ich muss doch dem Teilnehmer2 sagen, dass er die Daten von den Schalterstellungen auf den Bus schicken soll und das der Teilnehmer 3 diese Info auf den LEDs ausgeben soll.
Lies mal das hier: http://de.wikipedia.org/wiki/Controller_Area_Network http://www.me-systeme.de/canbus.html Daraus geht so einiges hervor. In deinem Fall z.B., dass dein Teilnehmer 2 Nachrichten mit der ID 100 (angenommen) verschickt und Teilnehmer 3 nun weiß, dass diese Nachricht mit der ID 100 für ihn ist und entsprechend die Nachricht umsetzt.
Danke für die Link. Diese kenne ich beriets schon. Ich weiss immer noch nicht wie ich mein Protokoll gestallten soll. Also ich stehe voll auf dem Schlauch!
Hi Frank, soll jeder Teilnehmer dann die Nachricht mit der ID 0x100 empfangen können? Wo steckt dann die Info drin welcher teilnehmer diese Nachricht auswerten (Daten anzeigen auf LED ) soll?
Ich hab gedacht, das ich den Identifier so definiere: ID: Teilnehmernrummer + Message Objekt Nr 8 Daten Bytes: Nutzdaten z.B. Schalterstellung
Definiere dir erstmal die Nachrichten, also was du von welcher Station wegschicken willst. Dann gibst du jeder dieser Nachrichten eine eindeutige ID. Wenn das getan ist, guckst du, welcher Knoten welche Nachricht zu verarbeiten hat. Und genau dieser Knoten (können natürlich auch mehrere sein) verarbeitet genau diese Nachricht. Die anderen Knoten verwerfen die Nachricht, da sie mit dieser ID nichts anfangen können. Knoten 1 sendet also zum Beispiel eine Temperatur und eine Windgeschwindigkeit. Wenn du weißt, dass ein anderer Knoten die Temperatur verarbeitet, um evtl. einen Lüfter schneller laufen zu lassen, und ein dritter Knoten die Windgeschwindigkeit verarbeitet, um die Markise automatisch ein und ausfahren zu lassen, dann definierst du dir 2 Nachrichten. Die Erste beinhaltet also die Temperatur und bekommt die ID 5. Die Zweite hat die Windgeschwindigkeit und bekommt die ID 4. Jetzt musst du Knoten 2 so programmieren, dass er Nachrichten mit der ID 5 annimmt. Knoten 3 nimmt dementsprechend nur Nachrichten mit der ID 4 an. Da aber so ziemlich alle CAN-ICs bereits Filter besitzen, kannst du diese Filter so programmieren, dass diese genau diese IDs an den Host (die CPU oder µController) dieses Knotens weiterleiten, der nachrichten mit dieser ID bekommen soll.
> ID: Teilnehmernrummer + Message Objekt Nr > 8 Daten Bytes: Nutzdaten z.B. Schalterstellung Du musst runter von der Vorstellung, dass die ID einer CAN-Message gezielt irgendwelche Nodes adressiert. Tut sie nicht. Wenn CAN ein Grossraumbüro ist, dann läuft das nicht so, dass Chef reinkommt und "Patrick!" brüllt. Nein, er brüllt "Kaffee!" und hofft darauf, dass sich jemand angesprochen fühlt. Ob sich davon Patrick oder Andreas angesprochen fühlt, ist ihm egal, das müssen die schon selber wissen.
Exakt. Du musst jedem Knoten sagen, auf welche ID er hören soll und auf welche nicht. Deshalb meinte ich auch, erstelle dir alle Nachrichten, die es gibt (auf Papier) und verteile dann die IDs. Diese IDs nimmst du dann für die Programmierung der Knoten her. Ach ja: Du bist nicht gewzungen, alle 8 Byte der Nachricht zu benutzen. Die Nutzdatenlänge ist ja im CAN-Header codiert und kann zwischen 1 und 8 betragen. (ne Länge von 0 Byte lassen wir hier mal außen vor ...)
Danke für Eure Hilfe! Hat mich ein bisschen weitergebracht. Temperatur ID:0x001 (kann nur gesendet werden) Schalterstellung ID:0x002 (kann nur gesendet werden) LED (PortX) ID:0x003 (kann nur empfangen werden) Ich möchte nun das der Teilnehmer 1 die Schalterstellung auf den CANBUS sendet. Der Teilnehmer 3 soll diese Nachricht empfangen können, und auf dem PortX ausgeben. Weiterhin möchte ich dann das der Teilnehmer 2 die Schalterstellung auf den CANBUS sendet. Der Teilnehmer 1 soll die Nachricht empfangen und auf dem PortX ausgeben. Wie kann ich nun veranlassen, dass dies so durchgeführt werden kann? Ja dazu verwende ich doch den CAN-Dongle. Damit kann ich zunächt prüfen was so alles auf dem CANBUS los ist und ich kann expliziet sagen was z.B. teilnehmer 1 und 2 und 3 tun sollen. Ich habe schon eine klare Vorstellung wie ich mir dies vorstelle, nur die Umsetzung fällt mir unheimlich schwer.
Achtung: Eine Kleinigkeit gilt es zu beachten: Da die ID noch eine zweite Funktion hat (bus arbitration), dürfen keine 2 Nodes die gleiche ID senden. Bei Sensorinformation (Temperatur, Schalter) ist das trivial. Jeder Sensor kriegt seine eindeutige ID und sendet regelmässig seine Info, ob's jemanden interessiert oder nicht. Bei Nodes, die auf Kommando reagieren (z.B. Lüfter abhängig von Temperatur und Schalter an/aus), wird das etwas komplizierter. Da gibt es nun verschiedene Möglichkeiten: - Es gibt verschiedene IDs für die verschiedenen Absender. Entweder indem du die IDs einfach durchzählst. Oder, summarum einfacher, indem du die 11 oder 29 Bits der ID in 2 Komponenten zerlegst: Absenderkennung (Node-ID) und Messagetyp (Temperatur1, Schalter2, LED, Lüfter, ...). Das bietet zudem dem Vorteil, dass du beim Schüffeln auf dem Bus bei jeder Message siehst, wo die herkommt. - Oder du drehst das ganze Verfahren um. Da gibt es dann keinen separaten Controller, der über den Bus auf die Sensoren horcht, und dann über wiederum über den Bus sagt "Lüfter ein!". Sondern die Node direkt am Lüfter horcht selber auf die Sensor-Informationen und schaltet abhängig davon ihren Ausgang zum Lüfter.
- Telinehmer 1: sende diese Nutzdaten als Nachricht mit ID x - Teilnehmer 3: verarbeite Nachrichten mit ID x - Teilnehmer 2: sende Nutzdaten als Nachricht mit ID y - Teilnehmer 1: verarbeite Nachrichten mit ID y Löse dich von der Vorstellung, dass du die einzelnen Teilnehmer direkt adressierst wie z.B. beim SPI mit dem CS-Signal. Desweiteren musst du jedem Teilnehmer ein EIGENES Programm spendieren, in dem du definierst, welche Nachrichten dieser Teilnehmer empfangen darf. Jeder Teilnehmer lauscht laufend am Bus. Durch diverse Methoden kann niemals mehr als eine Nachricht fehlerfrei auf dem Bus vorhanden sein. Ist eine Nachricht auf dem Bus, erkennt das jeder Teilnehmer und speichert die Nachricht zwischen (macht i.d.R. das CAN-IC wie z.B. SJA1000 oder MCP2515 oder die im µController integrierte Peripherie), schaut sich die ID der Nachricht an, vergleicht diese ID mit der Akzeptanzmaske und dem Akzeptanzcode (mittels deren du einstellen kannst, welche ID überhaupt an die verarbeitende Software weitergeleitet wird), und falls die Überprüfung positiv ist, also dieser Teilnehmer die Nachricht mit ID x verarbeiten darf, dann wird die Nachricht an die verarbeitende Software weitergeleitet, ansonsten verworfen.
> Du musst jedem Knoten sagen, auf welche ID er hören soll
Plural. Auf welche IDs. Können mehrere sein. Kann ein ganzer Bereich von
IDs sein.
Joa, stimmt. Aber der Einfachheit halber erstmal nur die ID. :)
Warum machst du das nicht Event gesteuert? Wenn ich das richtig verstanden habe, soll zB Schalterplatine1 an Lampenplatine senden. Das würde doch reichen, wenn das nur dann passiert, wenn wirklich (an den Eingängen) was passiert? Somit bekommt jede Nachricht eine Nummer (COB-ID) abhängig vom Inhalt der Nachricht. zB (in hex) Schalterplatinen: 1 + X Lampenplatinen: 2 + X (was auch immer die senden sollten) Temperaturpl. 3 + X wasweißich 4 + X ...usw. X: (0..255) durchnummerierte Teilnehmer, vielleicht per knotenschalter einstellbar Falls auf einer Platine mehreres drauf ist, zB Schalter und Temperatur, so wird diejenige COB-ID genommen, die zum Nachrichteninhalt gehört. Jeder hört jetzt alle Nachrichten immer mit und entscheidet, auf welche er hören muss. (ich glaube CAN-empf. können sowas per hardware über MAsken filtern). Wenn für ihn interessant, dann wird die nachricht umgesetzt. So wäre es auch denkbar, dass mehrere Empfänger auf dieselbe Nachricht hören.
>Warum machst du das nicht Event gesteuert?
Wenn man bspw. zyklisch sendet, weiss man, dass der Teilnehmer noch da
ist, auch wenn kein event auftritt. Kann manchmal für einfache
Fehlermeldungen recht interessant sein.
Willst du die Verschaltung der unterschiedlichen Funktionen zur Laufzeit
ändern können? Wenn nicht, dann kannst du in die Knoten ja fest
programmieren auf welche Nachrichten sie hören sollen und welche sie
senden.
Ansonsten musst du den Sendern mitteilen welche Nachrichten sie senden
sollen. Den Empfängern brauchst du es vielleicht nicht mitteilen, wenn
aus der Adresse klar wird, welche Funktion du darstellen möchtest. Aber
es muss sichergestellt sein, dass jede ID nur einmal vergeben ist.
>ass der Teilnehmer noch da...
Dafür gibt es die sogenannten Heartbeat-Meldungen, das sind Nachrichten
mit einer hohen COB-ID (Niedrige Priorität). Diese werden von jedem
Teilnehmer in regelmäßigen Abständen abgesendet. Nach meinem obigen
Beispiel zB so:
Heartbeat: 10 + X (hex)
Danke für die zahlreichen Informationen und Vorschläge. Gestern bin ich noch bis spät in die Nacht hinein vor meinem PC gehockt. Ich bin nicht zu einer Lösung gekommen. Seit einigen WOchen mache ich da mit dem XC888 Mikrocontroller herum. Eigentlich will eigentlich nur, dass wenn eine Anforderung vom CAN Dongle kommt, dass dann z.B. der Teilnehmer 1 die Daten an Teilnehmer 3 senden soll oder das Teilnehmer 2 auch seine Daten an Teilnehmer 1 senden soll. Gestern hab ich dann mal versucht das ganze mit REMOTE zu realisieren, das hat auch nicht funktioniert. Ich bin total verwirrt. Weiss nicht was ich da noch tun kann. Ich werde mal immer immer weitermachen.
>Seit einigen WOchen mache ich da >mit dem XC888 Mikrocontroller herum. Lies du auch unsere Vorschläge, oder jammerst du nur, dass es nicht geht?? Du brauchst erstmal ein Konzept. Das haben hier schon viele beschrieben, wie es gehen könnte. Einfach wild losprogrammieren geht immer schief! (nicht unbedingt sofort, aber dann später!)
Auf Papier hab ich mir auch schon sämtliche Konzepte, so wie ich mir dies vorstelle aufnotiert. Ich bekomme dies nicht so umgesetzt. Wie würdet ihr genau die Anforderung (CAN-Dongle) aufbauen? ID? Daten? Ich meine die CAN Nachricht, die ich ja benötige damit z.B. ein Teilnehmer 1 die Schalterstellung auf den BUS sendet und dann vom Teilnehmer 3 verarbeitet wird.
Auf Papier hab ich mir auch schon sämtliche Konzepte, so wie ich mir dies vorstelle aufnotiert. Ich bekomme dies nicht so umgesetzt. Wie würdet ihr genau die Anforderung (CAN-Dongle) aufbauen? ID? Daten? Ich meine die CAN Nachricht, die ich ja benötige damit z.B. ein Teilnehmer 1 die Schalterstellung auf den BUS sendet und dann vom Teilnehmer 3 verarbeitet wird. Würdet ihr überhaupt die REMOTE Betriebsart vom CAN verwenden?
JEder sendet dann seine Daten, wenn eine Änderung eingetreten ist. DUrch die Arbitrierung wird gesorgt, dass es keine Kollisionen gibt. SOmit wird immer die wichtigste Nachricht zuerst gesendet. Und da jeder weiß, auf welchen NAchrichtentyp (SChalterstellung, Temp. - ist ja Teil der COB-ID) er hören muss. passt das. Wo liegt das Problem?
Puhhh....ja macht es jetzt Sinn die REMOTE Betriebsart zu verwenden oder nicht? Der XC888 ist so konzipiert, dass man erst die Message Objekte konfigurieren muss. Das heisst ich lege als aller erstes fest welche Message Objekte mit welche ID. Ich weiss halt nicht wie ich das ganze jetzt machen soll. Wie könnte man die Anforderung definieren? Matthias Lipinsky was meinst du mit 4 + X usw?
ich schrieb:
>X: (0..255) durchnummerierte Teilnehmer, vielleicht per knotenschalter
einstellbar
Schreib erstmal auf, welche Teilnehmer du hast.
bsP:
Platine mit 8Schaltern. 2 mal vorhanden
Platine mit 3 Temperatursensoren 1 mal vorhandne
Platine mit 16 Lampen 1 mal vorhanden
Platine mit 4Schaltern und zwei Tempsensoren 1 mal vorhanden
..
Dann legst du nach obigem Beispiel von mir (20.07.2007 18:06) für jeden
Teilnehmer, den (die) COB-IDs fest, die er senden soll, sowie empfangen
soll.
Und dann sehen wir weiter.
Ich würde den 29Bit-ID verwenden und die Bits verschieden zuordnen: Die ersten 2-4Bits würde ich als Prioritätsstufe benutzen, damit man wichtige Nachrichten (z.B. Notaus) an den anderen vorbeileiten kann. Die nächsten 8-10Bits würde ich als Absenderadresse und 8-10Bits als Empfängeradresse verwenden. Damit ist es möglich, bestimmte Absender- und/oder Empfängergruppen zu filtern. Die restlichen Bits können dann den Nachrichtentyp kennzeichnen. Allerdings würde ich mir zuerst einen MC auswählen, der auch zu jedem Messageobjekt eigene Filterregeln erlaubt. Wenn ich Dich richtig verstanden habe, kann Dein MC das ja nicht und Du mußt alle Nachrichten empfangen und umständlich in Software filtern. Dadurch können keine wichtigen Nachrichten bevorzugt bearbeitet werden, sondern versacken erstmal in der Queue mit allen anderen. Eine wichtige Eigenschaft des CAN-Busses geht damit verloren (Echtzeitigkeit). Peter
Hallo Peter und Matthias, wie schon erwähnt, können mit dem Message Objekt 0 alle CAN Nachrichten empfangen werden. Verwende ich dieses Message Objekt nicht sonder die Messaeg Objekte ab der Nummer 1, dann kann ich jedem Message Objekt das Arbitration Register sowie das Acceptance Register eingestellt werden. Ich verwende insgesamt 3 Teilnehmer. Jeder Teilnehmer besitzt DIP Schalter (2 hoch 4 Zustände) sowie eine LED Bank (4 LED'S), die an Port 3 angeschlossen sind. Des weiteren habe ich noch einen CAN Dongle, der an einem PC angeschlossen ist. Mit diesem soll dann die Anforderung gesendet werden, so dass die drei Teilnehmer diese Nachricht empfangen und dementsprechen verarbeiten können. Die drei Teilnehmer sind gleich Aufgebaut, sie sollen sich nur anhand der Teilnehmernummer unterscheidbar sein.
Angehängte Dateien:
In diesem Bild kann man sehen, wie ein MO mit DAVE konfiguriert wird.
So Matthias meine ID's sollen so aussehen: DIP-Schalter: 1 + X LED Block : 2 + X x:(0...255) durchnummerrierte Teilnehmer die per Schalter einstellbar sind. Diese ID's müsste man doch nun in jedem Teilnehmer so konfigurieren oder? Teilnehmer1: DIP-Schalter: 1 + 1 LED-Block : 2 + 1 Teilnehmer2: DIP-Schalter: 1 + 2 LED-Block : 2 + 2 Teilnehmer3: DIP-Schalter: 1 + 3 LED-Block : 2 + 3 Diese ID's stehen doch dann fest im XC888 drin, sobald der XC888 mit Spannung versorgt wird. Wie kannn ich dann weiter vorgehen? Ich muss nun mit dem CAN-Dongle eine Anforderung senden können.
Warum willst du immer mit Anforderungen arbeiten? Du kannst ne Broadcast-Nachricht verschicken, die alle Knoten lesen und die darauf so reagieren, dass sie die aktuellen Daten verschicken. Dadurch hast du aber immer ne Burst-Last auf dem Bus, Nachrichten blockieren sich und die Daten brauchen länger, als wenn du immer genau die Nachricht automatisch (ohne Anforderung) verschickst, wenn es neue Daten gibt.
>Warum willst du immer mit Anforderungen arbeiten? Eben. Du rufst doch auch nicht deine Mutter jeden Tag an und fragst, obs was Neues gibt. Sie wird sich dann schon melden. Also mach es hier auch so. Neue Daten werden von allein gesendet. Fertig. Kleiner Tip noch: Nimm höhere Zahlen als COB-IDs >DIP-Schalter: 1 + X >LED Block : 2 + X Das geht nicht. Welche COB-ID hat Teilnehmer 2 mit Lampe, und welche COB-ID Teilnehmer 1 mit Ledblock?? Richtig, dieselbe. Und das darf nicht sein. Es darf zu keinen Überschneidungen kommen. Das war in meinem Beispiel schlecht dargestellt und nicht beachtet. Sorry. MIt dem Besipiel kannst du bis 256 Teilnehmer gehen. X ist wieder die Teilnehmernummer. Schalter : 256 + X (Damit sind irgendwelche EIngänge gemeint.) (nicht die TeilnehmerNr. die wird nicht versendet) LED Block : 512 + X Temperatur : 768 + X weiter : 1024 + X So hast den Vorteil, du kannst 256 Teilnehmer haben, und hast noch die COB-IDs 0..255 frei. Die sind sehr hoch priorisiert und können (später) für "Notfall" meldungen nach dem Prinzip verwendet werden: Notfallmeldung: 0 + X
falls du irgendwann man das Ergebnis hast, kannst du dann hier mal die Lösung posten? Mir ist nämlich die Aufgabe noch nicht vollkommen klar ;-)
Hi Matthias L., ich habs verstanden. Also alle Teilnehmer sollen zunächst alle Infos (DIP-Schalterstellungen) auf den CANBUS senden. Aber wie mache ich es jetzt so, dass der Teilnehmer 3 die Schalterstellung empfangen und auf die LED's ausgeben soll? Die Teilnehmer 1 und 2 sollen die Schalterstellungen nicht auf den LED's anzeigen.Danach möchte der Benutzer, dass der Teilnehmer 1 die Schalterstellung von Teilnehmer 2 empfangen und anzeigen soll. Der Benutzer soll entscheiden welcher Teilnehmer welche Botschaft anzeigen soll oder nicht.
Hä? Was?
>., ich habs verstanden. A
Glaub ich noch nicht.
Das klingt alles sehr komisch! Und durcheinander!
1)
Die DIP SChalterstellungen werden NICHT versendet!
2)
Poste mal, welcher Teilnehmer GENAU was kann und machen soll!
Also, wieviele Teilnehmer gibt es, und was machen diese?
zB. 3x je 8Schalter,
2x je 2Lampen
3x je eine 7Segmentanzeig, vierstellig
1x je 3 Temp-sensoren
oder sowas.
Also, erkläre das mal zuerst
Hi Matthias L., es sind insgesamt drei Teilnehmer, diese sind alle gleich aufgebaut. Jeder Teilnehmer besitzt einen DIP-Schalter mit dem man 16 Zustände einstellen kann und jeweils darauf sind 4 LED's die an Port 3 angeschlossen sind. Zudem besitzt jeder Teilnehmer einen CAN Anschluss. Die Teilnehmernummer soll zuerst mal in dem Programmcode vergeben werden. (gleich nach main)
Die DIP Schalter sind für die Knotennummer? Welche Eingänge, Ausgänge, das ist doch das interessante Ja, und weiter?
Ziel der Aufgabe soll es sein, dass die Software auf allen Teilnehmern gleich sein soll. Die Teilnehmers sollen sich nur anhand der Teilnehmernummer unterscheiden. Ich Trottel hab noch vergessen zu erwähnen, dass mit dem anderen DIP Schalter die LED's gesteuert werden sollen. Der Benutzer soll dann entscheiden können, ob der Teilnehmer 2 die DIP-Schalterstellung von Teilnehmer 1 anzeigen soll. Oder dass der Teilnehmer 3 die DIP-Schalterstellung von Teilnehmer 2 anzeigen soll. Ausgängen: DIP-Schalterstellung Eingänge: LED Anzeige
Ich hoffe ich hab mich diesmal etwas verständlicher ausgedrückt.
Also wenn du nicht in der Lage bist, Fragen zur Ausstattung eines
"Teilnehmers" zu beantworten, musst du dir jemand anders suchen"
>Poste mal, welcher Teilnehmer GENAU was kann und machen soll!
1) Was ist auf welchen(jedem?) Teilnehmer drauf?
- wieviel Tasten zur Bedienung (die dann irgendwie versendet werden)
- wieviel LEDS zur Anzeige irgendwelcher Tasten
- wieviel Knotennummernschalter
- wieviel Temperatursensoren
- was weiß ich noch...
Ist das so schwer...?
Langsam verlier ich die Geduld
>>Was ist auf welchen(jedem?) Teilnehmer drauf? Jeder Teilnehmer ist GLEICH aufgebaut: 1) 4 LED's 2) 1 DIP-Schalter (16 Zustände einstellbar) 3) CAN Knoten 4) Mikrocontroller XC888 Zunächst soll die Nummer der Teilnehmer fix im Programmcode vergeben werden. Später möchte ich noch weitere DIp-Schalter dazu verwenden. Ich hab noch zusätzlich einen CAN-Dongle zur Verfügung. Das sind alle Angaben. Mehr gibt es nicht.
Zunächst möchte ich NUR die Schalterstellungen von jedem Teilnehmer auf den CANBUS senden. Je nach Wunsch vom Anwender, sollen dann die Schalterstellungen auf den jeweiligen Teilnehmern auf den LED's erscheinen.
Also gibt es PRO Teilnehmer 4Schalter für Bedienereingaben (DIP-SChalter) und 4LEDs? Wieviele (glecihe) Teilnehmer gibt es? Die CAN-Adresse soll im Programm festgelegt werden? Sehe ich das richtig? Wenn ja, welche Schalterinformation soll wo hin, bzw, soll das veränderbar sein, durch Bediener (mittels irgendwelcher Nachrichten?) Wenn nein, was hab ich nicht kapiert?
>Also gibt es PRO Teilnehmer 4Schalter für Bedienereingaben (DIP-SChalter) >>und 4LEDs? Ja so ist es! >>Wieviele (gleiche) Teilnehmer gibt es? Insgesamt drei Teilnehmer! >>Die CAN-Adresse soll im Programm festgelegt werden? >>Sehe ich das richtig? Ja exakt! >>Wenn ja, welche Schalterinformation soll wo hin, bzw, soll das >>veränderbar sein, durch Bediener (mittels irgendwelcher Nachrichten?) Ja exakt! Der Bediener soll dann entscheiden können, ob z.B. die Schalterstellung Teilenhmer 2 vom Teilnehmer 3 angezeigt werden soll usw... >>Wenn nein, was hab ich nicht kapiert? Du hast es schon verstanden.
Ok.
>Der Bediener soll dann entscheiden können...
Und wie soll das geschehen? mittels zusätzlicher Nachrichten von PC
(über das Dongle?) ??
PS: Welchen Zweck hat der Aufbau?
Ich soll dies für jeden realisieren. Eigentlich soll der CAN Dongle dann die gewünschte Anforderung senden. Das ganz soll nur ein Test sein. Später soll dann statt Schalter irgend welche Sendoren usw. angeschlossen werden. Die Nachrichten mit den Schalterstellungen soll zuerst auf den BUS gesendet werden und der Bediener entscheidet wer welche Nachricht verarbeiten soll.
Ich soll dies für jemanden realisieren. Eigentlich soll der CAN Dongle dann die gewünschte Anforderung senden. Das ganz soll nur ein Test sein. Später soll dann statt Schalter irgend welche Sendoren usw. angeschlossen werden. Die Nachrichten mit den Schalterstellungen soll zuerst auf den BUS gesendet werden und der Bediener entscheidet wer welche Nachricht verarbeiten soll.
Ich hab mir auch schon sehr viel gedanken darüber gemacht. Wahrscheinlich braucht man dazu schon noch eine zusätzliche Nachricht, die man vom Dongle aus sendet. Wie würdest du jetzt weiter machen?
>der Bediener entscheidet wer welche Nachricht verarbeiten soll. Ok. Aber wie soll das jedem Teilnehmer mitgeteilt werden? Über das CAN-Dongle? Also in etwa so: EIne Meldung vom PC zum Teilnehmer zB. Nr2 sagt dem, das er ab jetzt Informationen von Teilnehmer 1 verarbeiten soll??? Ist das so korrekt? >Eigentlich soll der CAN Dongle dann die gewünschte Anforderung senden. Wozu das? >Die Nachrichten mit den Schalterstellungen soll zuerst auf den BUS >gesendet werden? Wozu das? Oder ist das gedacht, um beim Einschalten die entsprechenden Lampen zu aktualisieren?
>Aber wie soll das jedem Teilnehmer mitgeteilt werden? Über das >CAN-Dongle? Ja genau! >Also in etwa so: Eine Meldung vom PC zum Teilnehmer zB. Nr2 sagt dem, >das er ab jetzt Informationen von Teilnehmer 1 verarbeiten soll??? >Ist das so korrekt? Ja genau! >>Eigentlich soll der CAN Dongle dann die gewünschte Anforderung senden. >Wozu das? Ich muss doch irgendwo den Teilnehmern mitteilen können ob sie jetzt diese Nachricht (z.B. Schalterstellung Teilnehmer 1) auf den LE's anzeigen sollen. >>Die Nachrichten mit den Schalterstellungen soll zuerst auf den BUS >>gesendet werden? >Wozu das? Oder ist das gedacht, um beim Einschalten die entsprechenden >Lampen zu aktualisieren? Das verstehe ich nicht genau. Das ganze hat nix mit dem Einschalten der Teilnehmer zu tun. Ich weiss nicht was ich noch sagen soll. Das ist alles!
Ok. soweit kapiert. Sollen die Informationen permanent aktualisiert werden? Also zB zeigt TLN1 die Schalterstellung von TLN2 an. bsp Alle An. Was passiert, wenn an TLN2 jetzt ein Schalter geändert wird? Soll dann die Anzeige an TLN1 sofort aktualisiert werden? Oder immer nur per Befehl vom PC? Also die Frage ist, ob sich Änderungen an der Schalterstellung sofort an der entsprechenden Anzeige bemerkbar machen soll?
Ja, die Änderungen an der Schalterstellung soll sich schon sofort an den entsprechenden Anzeigen bemerkbar machen. Wenn man es so sieht, dann soll der Bediener entscheiden welche Anzeige gerade aktueliert werden soll.
Ich hätte da ne Idee: Teilenhmer 1: ID: 256 + 1 (transmit) <-- Schalterstellung ID: 256 + 2 (receive) ID: 256 + 3 (receive) Teilenhmer 2: ID: 256 + 2 (transmit) <-- Schalterstellung ID: 256 + 1 (receive) ID: 256 + 3 (receive) Teilenhmer 3: ID: 256 + 3 (transmit) <-- Schalterstellung ID: 256 + 1 (receive) ID: 256 + 2 (receive) Sobald der Bediener z.B. eine Nachricht mit der ID:0x001, Nutzdaten Datenbyte1:0x01, dann soll jeder Teilnehmer diese CAN Nachricht zunächst empfangen. Anschließend muss nich geprüft werden on das Datenbyte1 auf 0x01 steht. Wenn ja dann soll z.B. Teilnehmer 2 die Nachricht 256 + 1 auf den LED's anzeigen.
>ID: 256 + 1 (transmit) <-- Schalterstellung Das ist Murks. >Ja, die Änderungen an der Schalterstellung soll sich schon sofort an den >entsprechenden Anzeigen bemerkbar machen. oder >Wenn man es so sieht, dann soll der Bediener entscheiden welche Anzeige >gerade aktueliert werden soll. Was denn nun??? Sofort oder per "Aktualisieren" Befehl!
Warum Murks? JA GENAU! Der Bediener soll entscheiden, welche Anzeige gerade aktualisiert werden soll.
Teilenhmer 1: Message Objekt mit der ID: 256 + 1 (transmit) <-- Schalterstellung Message Objekt mit der ID: 256 + 2 (receive) Message Objekt mit der ID: 256 + 3 (receive) Teilenhmer 2: Message Objekt mit der ID: 256 + 2 (transmit) <-- Schalterstellung Message Objekt mit der ID: 256 + 1 (receive) Message Objekt mit der ID: 256 + 3 (receive) Teilenhmer 3: Message Objekt mit der ID: 256 + 3 (transmit) <-- Schalterstellung Message Objekt mit der ID: 256 + 1 (receive) Message Objekt mit der ID: 256 + 2 (receive)
Teilnehmer 1: Message Objekt mit der ID: 256 + 1 (transmit) <-- Schalterstellung Message Objekt mit der ID: 256 + 2 (receive) Message Objekt mit der ID: 256 + 3 (receive) Teilnehmer 2: Message Objekt mit der ID: 256 + 2 (transmit) <-- Schalterstellung Message Objekt mit der ID: 256 + 1 (receive) Message Objekt mit der ID: 256 + 3 (receive) Teilnehmer 3: Message Objekt mit der ID: 256 + 3 (transmit) <-- Schalterstellung Message Objekt mit der ID: 256 + 1 (receive) Message Objekt mit der ID: 256 + 2 (receive)
Weil die Schalterstellung Nutzdaten sind. Diese haben in der COB-ID nichts zusuchen! Lösungsvorschlag: Jeder Teilnehmer (TLN) bekommt eine eineindeutige Nummer. hier 1...3 Daten senden: Wann (wann das ist folgt) ein TLNseine Schalterstellungen sendet, dann erfolgt das mit der COB-ID 0x180 + X (X: TLN1..3) Die Schalterstellung wird im ersten Datenbyte gesendet. Aufforderung zum Senden: Senden tut ein TLN immer dann wenn folgende NAchrincht (mittels PC gesendet) empfangen wurde: COB-ID 0x080 (kein plus irgendwas) Als erstes Datenbyte wird jetzt die TLN Nummer versendet, welcher Daten senden soll! Ein Null könnten alle bedeuten. Teilnehmer konfigurieren: Über den PC wird eine Meldung versendet, die einem TLN mitteilt, auf welche Daten er hören soll: COB-ID 0x500 + X (X: TLN1..3) Das erste Datenbyte legt fest, auf welchen Teilnehmer er hören soll. Dieses muss er speichern und ich nenne es mal KD. SOmit muss jeder Teilnehmer senden mit: COB-ID 0x180 + X (X: TLN1..3) und empfangen mit: COB-ID 0x080 (Aufforderung zum Daten senden) COB-ID 0x500 + X (Konfigurationsdaten) COB-ID 0x180 + KD (Daten eines anderen TLN) So würde ichs lösen...
Wie meinst du das mit dem CO-ID 0x180 + KD ? Das verstehe ich nicht.
Zuerst muss ich alle Message Objekte im XC888 erstellen und konfigurieren. Damit ich auch mit jedem Teilnehmer auch die anderen gesendeten Schalterstellungen empfangen kann, brauch ich statt 3 Messaeg Objekte noch zwei weitere zum Empfangen. Das heisst ich bräuchte insgesamt für jeden Teilnehmer 5 Message Objekte. Beispiel für den Teilenhmer 1: Message Objekt mit der ID: 0x180 + 1 zum senden Message Objekt mit der ID: 0x180 + 2 und ID: 0x180 + 3 zum empfangen Message Objekt mit der ID: 0x080 zum empfangen Message Objekt mit der ID: 0x500 + 1 zum empfangen Beispiel für den Teilenhmer 2: Message Objekt mit der ID: 0x180 + 2 zum senden Message Objekt mit der ID: 0x180 + 1 und ID: 0x180 + 3 zum empfangen Message Objekt mit der ID: 0x080 zum empfangen Message Objekt mit der ID: 0x500 + 2 zum empfangen Beispiel für den Teilenhmer 3: Message Objekt mit der ID: 0x180 + 3 zum senden Message Objekt mit der ID: 0x180 + 1 und ID: 0x180 + 2 zum empfangen Message Objekt mit der ID: 0x080 zum empfangen Message Objekt mit der ID: 0x500 + 3 zum empfangen
>jedem Teilnehmer auch die anderen gesendeten >Schalterstellungen empfangen kann, nicht DIE anderen, nur EIN anderes! >essage Objekt mit der ID: 0x180 + 1 und ID: 0x180 + 2 zum empfangen ^^^^ ODER !!!!!!!!
muss es wirklich sein das Teilnehmer 2 die Schalterstellung von Teilnehmer 3 anzeigen kann und Teilnehmer 1 die von Teilnehmer 3? Ich würde das zentral aufbauen. Also Teilnehmer 1, 2 und 3 senden ihre Daten auf den Bus und Teilnehmer 4 empfängt diese, dort kann man das auch auswählen welcher Wert aktualisiert werden soll und welcher nicht. Mit dem CAN Protokoll kenne ich mich nicht so aus. Im großen und ganzen kann ich aber sagen das jeder Sender seine Daten mit einem bestimmten oder mehreren Identifier kennzeichnet, es ist also nicht nötig mitzuübertragen wer den Temperaturwert1 gesendet hat, da nur ein Teilnehmer diesen Wert versenden darf. Andere Teilnehmer dürfen dann z.b. nur Temperaturwert2-4 usw. verschicken, so ist also bekannt wo das ganze herkommt und kein Teilnehmer kann/darf/sollte einen Wert mit einem fremden ID verschicken. Was der jeweilige Empfänger damit macht ist also auch egal jeder kann den Wert empfängen und ihn nach seinen Wünschen weiterverarbeiten. Auch dein PC verschickt jetzt Daten mit einem bestimmten ID Wert der von den anderen Teilnehmers als Befehl verstanden wird oder ignoriert wird. Wenn du von CAN sprichst solltest du dich an diese Norm halten, wenn du jetzt wieder was eigenes machen willst übertrage es im Datenpaket hier kannst du dann dein eigenes Protokol innerhalb von CAN verwirklichen, aber die CAN Nachrichten entsprechen der Norm.
Guten Morgen Matthias, was meinst du damit? >jedem Teilnehmer auch die anderen gesendeten >Schalterstellungen empfangen kann, >>nicht DIE anderen, nur EIN anderes! >essage Objekt mit der ID: 0x180 + 1 und ID: 0x180 + 2 zum empfangen ^^^^ >>ODER !!!!!!!!
Damit z.B. der Teilnehmer 1 bei entsprechender Anforderung die Schalterstellungen von Teilnehmer 2 oder Teilnehmer 3 empfangen werden kann, muss der XC888 noch zwei weitere Empfangsmessage-Objekte besitzen. Ich möchte nicht das Message Objekt 0 verwenden. Damit kann ich alle Nachrichten abfragen. Besser ist es wenn man die Message Objekte gleich einstellt und konfiguriert.
Also ich habe keine Ahnung von diesem XC888 und deren EInstellungen. Ich meine Damit, dass es notwendig ist eine dieser beiden IDs zu empfangen. Somit muss zB Teilnehmer folgende IDs empfangen können: 0x080 Anforderung 0x501 Konfigdaten vom PC 0x182 ODER 0x183 Daten von TLN2 ODER TLN3 (abh. von Konfigdaten) senden muss seine Daten immer mit 0x181. selbes bsp für TLN2: empfangen: 0x080 Anforderung 0x502 Konfigdaten vom PC 0x181 ODER 0x183 Daten von TLN1 ODER TLN3 (abh. von Konfigdaten) senden muss seine Daten immer mit 0x182. selbes bsp für TLN3: empfangen: 0x080 Anforderung 0x503 Konfigdaten vom PC 0x181 ODER 0x182 Daten von TLN1 ODER TLN2 (abh. von Konfigdaten) senden muss seine Daten immer mit 0x183. das ODER bedeutet, dass nur eine von beiden empfangen werden braucht. Wie du das mit dem XC888 umsetzen musst, weiß ich nicht. So meine ich das. alles klar?
Achso, so hab ichs auch gemeint. Vielen vielen Dank für deine Hilfe! So wie es jetzt aussieht, werde ich dies auch so umsetzen. Wird dein vorgeschlagenes Prinzip auch wo anders bei CAN eingesetzt? Bei weiteren Fragen werde ich mein Problem in diesem Thread reinsetzen.
Naja, CANopen funktioniert ähnlich: Dort senden (aufgeforderte) Teilnehmer auf 0x180+X. Eine Synchronisationsmessage läuft auf 0x080 und geht an alle. Daten zum Konfigurieren der Teilnehmer werden auf, oh ich sehs grad, auf 0x600+X und NICHT auf 0x580+X gesendet. das kannst vielleicht noch einbringen.
Als erstes müssen die Message Objekte für jeden XC888 Mikrocontroller angelegt und konfiguriert werden. Somit muss zB Teilnehmer folgende IDs empfangen können: 0x080 Anforderung 0x501 Konfigdaten vom PC 0x182 ODER 0x183 Daten von TLN2 ODER TLN3 (abh. von Konfigdaten) senden muss seine Daten immer mit 0x181. Insgesamt benötigt der Teilnehmer 1 Message Objekt das sendet und 4 Message Objekte die empfangen können.
>1 Message Objekt das sendet Ok >und 4 Message Objekte die empfangen können. Wieso 4?
>> Wieso 4?
1 Message Objekt damit man die Konfigurationsdaten empfangen kann.
1 Message Objekt damti die Anforderungen empfangen werden können.
2 Message Objekte damit die Schalterstellungen der anderen Teilnehmer
empfangen werden können.
Dies ergibt dann eine Anzahl von 4 Message Objekten.
Dazu kommt noch ein Sende Message Objekt.
>2 Message Objekte damit die Schalterstellungen der anderen Teilnehmer >empfangen werden können. Wieso denn DER anderen? DES EINEN anderen!!!!!!!!!!!!!
Ich muss doch z.B. den Teilnehmer 1 so konfigurieren, dass wenn eine Anforderung kommt, dass dann die Schalterstellung vom Teilnehmer 1 oder Teilnehmer 3 empfangen werden können. Dies bedeutet ich muss hier noch zwei weitere Message Objekte anlegen die zum Empfangen verwendet werden. Beispiel: Der Dongle sendet diese Nachricht mit dieser ID: COB-ID 0x500 + 1 (Konfigurationsdaten = 0x02) Der Teilnehmer empfangt diese Nachricht und sieht, dass das erste Datenbyte auf 0x02 steht. Somit weiss dieser, dass er die Daten vom Message Objekt mit der ID 0x180 + 2 benutzen soll. Deshalb muss noch bei Teilnehmer 1 eine Message Objekt mit der ID Nr: 0x180 + 2 zum EMpfang angelegt werden.
>Deshalb muss noch bei Teilnehmer 1 eine Message Objekt mit der ID Nr: 0x180 >+ 2
zum EMpfang angelegt werden.
Richtig. Und somit sind es doch aber nur drei:
0x080 Anforderung
0x501 Konfigdaten
0x182 Prozessdaten (wurde mit PC so konfiguriert)
Das sind bei mir nur drei. Weitere muss dieser nicht empfangen!
Ja weißt du. ich muss es nicht verstehen. Wenn du nur sagst dass dus nicht verstehst, aber nichts fragst... Du willst es bauen, nicht ich. cih würde es so umsetzen und es würde gehen
z.B. Teilnehmer 1: Aufforderung zum Daten senden: COB-ID 0x080; Datenbyte1=0x01 --> Daten werden gesendet mit COB-ID 0x180 + 1 (im DatenByte1 steht dann die Schalterstellung vom Teilnehmer 1 drin) Jetzt kommt eine Nachricht mit COB-ID 0x500 + 1 und Datenbyte1 0x02. Dies bedeutet der Teilnehmer möchte die Schalterstellung vom COB-ID 0x180 + 2 empfangen. Danach wird das Datenbyte 1 ausgelesen und auf den LED's ausgegeben. Das ist doch richtig so oder hab ich noch was vergessen?
... hab was vergsssen... Der Teilnehmer 1 muss noch ein Message Objekt besitzen mit dem COB-ID 0x180 + 2, das allerdings als Empfang dienen soll und nicht zum senden verwendet wird. Das Beispiel kann man auch mit Teilnehmer 2 und 3 machen.
Sorry Matthias, ich hab noch was erledigen müssen, desshalb konnte ich nicht gleich antworten.
>Teilnehmer 1: >Aufforderung zum Daten senden: >COB-ID 0x080; Datenbyte1=0x01 --> Daten werden gesendet mit COB-ID 0x180 >+ 1 >im DatenByte1 steht dann die Schalterstellung vom Teilnehmer 1 drin) Ok. TLN 1 hat seine Daten VERSENDET (wer auch immer hier zuhört!) >Jetzt kommt eine Nachricht mit COB-ID 0x500 + 1 und Datenbyte1 0x02. >Dies bedeutet der Teilnehmer möchte die Schalterstellung vom COB-ID >0x180 + 2 >empfangen. Danach wird das Datenbyte 1 ausgelesen und auf den LED's >ausgegeben. NEIN! Das bedeutet NUR, dass er ab jetzt auf die COB 0x180 + 2 hören soll!! Mehr nicht! Es ist ja noch kein (neues) Datenbyte angekommen! Die Anzeige wird erst mit einem neuen Wert befüllt, wenn der TLN1 eine Meldung von TLN2 erhalten hat. DIESER TLN2 sendet erst, wenn er (TLN2) folgendes empfangen hat: COB 0x080 & Datenbyte 0x02 !!!
Ja das meinte ich auch. Somit soll der TLN 2 dann auf COB 0x180 + 2 hören. Genau wie würdest du dies relaisieren? Entweder ein Message Objekt erzeugen mit dem COB 0x180 + 2 oder ?????
Arbitration Register 0x182 = 110000010 Acceptance Register 0x182 = 110000010 | | --> Nachricht kann empfangenn werden
Die Lösung (oder besser: ein Weg) hab ich dir gezeigt. Die Umsetzung liegt an dir. Da ich diese ganzen Register des XC888 nicht kenne
Wahrscheinlich müsste ich es dann so machen, dass ich mit einem Message Objekt (Beispiel TLN1) permanent prüfe ob Nachricht mit ID 0x182 oder ID 0x183 anliegt. Wenn ja, Datenbyte1 auf LED ausgeben.
Angehängte Dateien:
-
XC888_MO0.PNG
12 KB
Matthias was würdest du mir empfehlen? Mit dem XC888 kann man pro Knoten 16 Message Objekte anlegen und konfigurieren (Arbitration Register, Acceptance Register, Richtung:receive/transmit). Das Message Objekt 0 ist was besonderes.
Das klingt zumindest vernünftig. (Obs über irgendwelche Masken geht, weiß ich nicht)
Also ich habs jetzt mal mit dem Acceptance Filter gelöst. Ich habe bisher noch keinen Interrupt verwendet, alles läuft noch in der while(1) Schleife von main. Hat jemand Erfahrung mit dem umsetzen der Software? Ich glaube, Interrupts wären dafür echt gut oder?
>Erfahrung mit dem umsetzen der Software? Ich glaube, >Interrupts wären dafür echt gut oder? Meist ja. Weil dann der Prozessor nur dann CAN-Meldungen zu sehen bekommt, wenn eine relevante da ist. Und du musst nicht dauernd irgendein Bit pollen. Wobei das bei deiner Anwendung wohl egal ist.
Ich hab das ganze wie gesagt mal ohne Interrupt gelöst. Folgendes ist mir aufgefallen: Anforderung 0x080 & Datenbyte1=0x01 --> TLN1 sendet 0x181 & Datenbyte1 Jetzt sende ich vom CAN Dongle folgende Nachricht: 0x502 & Datenbyte1 = 0x01 Dies bedeutet ja das der TLN2 die Nachricht von TLN mit der ID 0x181 & Datenbyte1 empfängt. Dabei kommt es vor, dass es ein paar Sekunden dauert, bis ich die Daten auf den LED's (TLN2) zu sehen sind. Warum eigentlich? Ich bin noch am überlegen wie dies mit den Konfigurationsdaten lösen könnte. z.B. 0x502 & Datenbyte1 = 0x01 Jeder Teilnehmer soll ja die gleiche Software bekommen.
>Jetzt sende ich vom CAN Dongle folgende Nachricht: 0x502 & Datenbyte1 = >0x01 >Dies bedeutet ja das der TLN2 die Nachricht von TLN mit der ID 0x181 & >Datenbyte1 empfängt. Korrekt. Die Nachricht 0x502.. bedeutet ja nur, dass der TLN2 auf TLN1 hören soll, MEHR NICHT. >Dabei kommt es vor, dass es ein paar Sekunden >dauert, bis ich die Daten auf den LED's (TLN2) zu sehen sind. Warum >eigentlich? Weil eine Aktualisierung erst mit der Meldung 0x080 (Anforderung) erfolgt. Das heißt, es ist ratsam, unmittelbar nach einer 0x500+X Nachricht, eine 0x080 Nachricht zu senden. Also so erkläre ich das mit meinem Konzept. Falls du da etwas anderes programmiert hast, dann kann ichs nicht erklären
Achso stimmt ja, ich habe zuerst eine Nachricht mit der ID 0x080 vom CAN Dongle aus gesendet. Im Anschluss sendete ich dann die Nachricht mit der ID 0x502. Weisst du vielleicht wie ich dies lösen könnte: Alle TLN's besitzen eine Variable mit dem Namen DeviceAddress. Wenn ich zum Beispiel TLN1 starte, dann bekommt die Variable DeviceAddress den Inhalt 0x01 zugeweisen. Jetzt möchte ich es so haben, dass bei Empfang (TLN1) von 0x501 & Datenbyte 1 = 0x01 nicht die ID 0x181 empfangen werden kann, sondern nur 0x182 oder 0x183. Dies soll auch bei TLN2 und TLN3 genauso sein.
Ich weiß nicht was du meinst. Was macht die variable "DeviceAddress" ? Ist das die eigene Knotennummer? Also das X in 0x500+X, 0x180+X Oder was ist das da?? Und was du jetzt genau machen willst, hab ich nicht verstadnen. Also bitte nochmal anders formulieren
Ja das X entspricht der Variable DeviceAddress. Hmmm...mir fehlt da ein Mechanismus mit dem COB-ID: 0x500 + X und dem Datenbyte1 (0x01 ; 0x02 ; 0x03). Ich möchte es so haben, dass ich nicht immer die Software abändern muss. Ok die Zuweisung der Knotennummer muss ich jetzt momentan noch manuell machen.
>Ich möchte es so haben, dass ich nicht immer die Software abändern muss. Ok >die
Zuweisung der Knotennummer muss ich jetzt momentan noch manuell machen.
Also du suchst einen Mechanismus, um diese Knotennummer (X) extern zu
vergeben??? zB beim Einschalten des Systems??
Hab ich das richtig verstanden???
Also da fällt mir pauschal nur ein was ein: Per software bekommt jeder teilnehmer zB X=0. SO und jetzt muss jeder Teilnehmer einzeln!!!! per PC mit einer speziellen CAN-Nachricht auf seine Adresse eingestellt werden. Somit wird dem X ein neuer Wert zugewiesen. Dieser muss dann allerdings nicht flüchtig (EEPROM) abgespeichert werden. und beim Neustart (Spannung zuschalten) wird dieser Wert genommen. Halte ich aber für keine gute Idee, da du dir "merken" musst welche adresse jeder TLN hat (per Aufkleber zB) Ich würde eine Lösung per DIP/Kodierschalter verwenden. Das ist einfach und von aussen (Benutzer) sofort erkennbar.
Wo steht das drin, dass das COB-ID:0x500+X für die Konfiguration zuständig ist? Gibt es irgendwo eine Liste zu den COB-ID's?
Das hab ich in meiner Idee so festgelegt. (aber die Zahlen orientieren sich an CANopen) SO hab ich die COB-IDs hier implementiert.
Weisst du wo ich eine Liste (Beschreibung) finde mit allen COB-ID's?
ja, in dem link, den ich damals gepostet habe. Irgendwo auf der Seite von LENZE. gucke mal weiter oben. Aber ich glaub das war unter hausbus. weiß ne mehr genau. War da aber noch nicht angemeldet, nick war Matthias (gast) bin jetzt mal ne weile weg..
Im Netz habe ich was gefunden:
>>http://www.frenzel-berg.de/download/datasheet/canopenguide_d.pdf
COB-ID:0x80 steht aber für Synchronisation und nicht zum senden von
Nachrichten. Verstehe ich nicht!
Ich verwende ja folgende COB-ID's: 0x180 + X 0x500 + X 0x080 Welche von denen sind SDO oder PDO?
Sagen ganz kann ich diese COB-ID nirgend bei CanOpen zuordnen. 0x080 bedeutet in CanOpen Synchronisation. 0x580 + X bedeutet in CanOpen Transmit SDO. 0x180 + X bedeutet in CanOpen Transmit PDO. Stimmt dies eigentlich?
>0x080 bedeutet in CanOpen Synchronisation. >0x580 + X bedeutet in CanOpen Transmit SDO. >0x180 + X bedeutet in CanOpen Transmit PDO. Ja, die SDO,PDO, Sync Messagezuordnung, die du gefunden hast, sind alle richtig. Deshalb hab ich ja diese Zahlen so gewählt ;-)
Mit Synchronisation soll der jeweilige Teilnehmer seine Daten auf den Bus geben? In der Liste steht noch was von Receive SDO und PDO. Was hat es damit auf sich?
In den Canopen Unterlagen steht was von Receive SDO und Receive PDO. Das bedeutet doch, dass die SDO's und PDO's der Teilnehmer auf Receive eingestellt werden müssen oder? 0x080 Receive 0x580 + X bedeutet in CanOpen Receive SDO. 0x180 + X bedeutet in CanOpen Receive PDO.
Wenn ich ein PDO (z.B. 0x181) von einem Teilnehmer aus, auf den Bus sende, dann kann ich doch auch das Receive PDO verwenden. Dies bedeutet das Receive PDO empfängt dann der Master (Dongle)?
In den Canopen Unterlagen steht was von Receive SDO und Receive PDO. Das bedeutet doch, dass die SDO's und PDO's der Teilnehmer auf Receive eingestellt werden müssen oder? 0x080 Receive 0x580 + X bedeutet in CanOpen Receive SDO. 0x180 + X bedeutet in CanOpen Receive PDO.
Hi Matthias, da nun soweit alles bei mir läuft, möchte ich mein Protokoll ausbauen. Es gibt da ja noch das NMT (netzwerkmanagement, sowie Receive SDO bzw. Receive PDO). Was hat es damit aufsich?
Bin ja wieder da. War doch WE! >>Mit Synchronisation soll der jeweilige Teilnehmer seine Daten auf den >>Bus geben? Naja, bietet sich doch an. >>In der Liste steht noch was von Receive SDO und PDO. Was hat es damit >>auf sich? ----------- --------------- Master | TxPDO ===> | Slave | TxSDO ===> | | | | RxSDO <=== | | RxPDO <=== | ----------- ----------------- Das ist immer vom Master aus gesehen (hier PC-dongle): Tx sendet der Master, Rx empfängt der Master Tx empfängt der Slave, Rx sendet der Slave. SDO: Ist ein ServiceDatenObjekt. Damit werden Informationen übertragen, die zur Konfigurierung/Parametrierung der Slaves dient PDO: Sind Prozess(Nutz)daten. Aufgrund der relativ kleinen COB-ID (kleiner als SDO) werden diese Daten höher-prior übertragen. NMT: Ist ein Netzwerkmanagement-dienst. Damit werden alle Slave "aktiv" geschaltet. Bedeutet: Nach dem Start (PowerUp) sind alle Slave im sogenannten "pre-operational" mode. sie akzeptieren hier KEINE PDOs! ein umschalten in "operational" erfolgt mit einem NMT. irgendwo in dem Lenze Dok. sollte das ganze als State-Maschine beschrieben sein.
Angehängte Dateien:
-
SDO.PNG
24 KB
Hi Matthias, so ganz verstehe ich dies immer noch nicht. Der Teilnehmer 1 sendet z.B. seine Daten mit der COB-ID:0x181. Entspricht dies jetzt einem PDO(TX) oder PDO(RX)? Genauso mit dem COB-ID:0x581. Damit kann ich z.B. sagen, das der Teilnehmer 1 die Daten vom Teilnehmer 2 lesen soll. Entspricht dies jetzt einem SDO (TX) oder SDO(RX)? Wenn ich jetzt irgendwelche anderen Paramter von einem bestimmten Teilnehmer lesen möchte, müsste ich dies mit einem SDO realisieren. Z.B. ich sende vom Master eine Nachricht mit der COB-ID: 0x601. Damit könnte ich doch einen Paramter vom Teilnehmer 1 auslesen oder? In den PDF Dateien steht einmal was von Telegramm zum Antrieb (COB-ID:0x605) und dann Antwort Telegramm (COB-ID:585) vom Antrieb.
Hab mich heute Morgen gleich wieder an den Rechner gesetzt. Mich verwirrt das immer noch bzw. ich weiss noch immer nicht wie ich z.B. veranlassen kann, das ich eine Paramter von einem Teilnehmer auslesen kann.
----------- ---------------
Master | TxPDO 0x200*+X ===> | Slave
| TxSDO 0x600 +X ===> |
| |
| RxSDO 0x580 +X <=== |
| RxPDO 0x180*+X <=== |
----------- -----------------
>>er Teilnehmer 1 sendet z.B. seine Daten mit der COB-ID:0x181.
Entspricht dies jetzt einem PDO(TX) oder PDO(RX)?
Das ist dann ein RxPDO. SOlche Betrachtungen Rx/Tx werden immer vom
Master aus gemacht!
>>Z.B. ich sende vom Master eine Nachricht mit der COB-ID: 0x601. Damit
>>könnte ich doch einen Paramter vom Teilnehmer 1 auslesen oder?
Ja.
>>In den PDF Dateien steht einmal was von Telegramm zum Antrieb
>>(COB-ID:0x605) und dann Antwort Telegramm (COB-ID:585) vom Antrieb.
die 0x601 ist TxSDO: 0x600+X; X=1 (Teilnehmer1)
Antwort wäre ein RxSDO 0x0581: 0x580+X; X=1
Im Beispiel ist das iednetisch mit Teilnehmer (Knotennummernschalter) =
5 dargestellt.
*:
Es können mehrere PDO gesendet/empfangen werden. Aber das soll nur der
Vollständigkeit dienen.
Achso. Ich verwende für die Anforderung das COB-ID:0x580 + X. Dieses sende ich ja vom Dongle an den jeweiligen Teilnehmer. Damit kann ich dann genau sagen welcher Teilnehmer welche Nachricht (COB-ID:0x180 + X) empfangen und auswerten soll. Wie kommt dann das COB-ID:0x600 + X zum Einsatz? Müsste ich laut CanOpen dann wenn ich ein COB-ID:0x580+X vom Master sende auch eine Antwort vom einem Teilnehmer (COB-ID:0x600 + X) bekommen?
Ich sende nun eine Nachricht mit dem COB-ID:COB-ID:0x581 für den Teilnehmer1. Dieser empfangt diese Nachricht und sieht, dass z.B. das 3. Datenbyte den Wert 0x01 besitzt. Daraufhin könnte dieser dann eine Antwort Nachricht mit der COB-ID:0x601 auf den Bus senden oder? Wäre dieses Vorgehen so in etwa wie bei CAnOpen?
>>Ich sende nun eine Nachricht mit dem COB-ID:COB-ID:0x581 für >>Nachricht mit der COB-ID:0x601 Ja das ist so richtig. Nur ich sehe gerade, ich habe die 0x580 und die 0x600 vertauscht: Der Master sendet die 0x600 und der Slave sendet die 0x580 als Antwort.
Ah...jetzt macht es auch Sinn. Es ist aber nicht zwingend notwendig dass der Teilnehmer dann wieder Antwortet oder? Ich kann ja nur eine Anforderung vom Master an den Teilnehmer senden. Gestern Nacht hab ich mir auch noch überlegt, das ganze jetzt per Interrupt zu lösen. Was wäre da sinnvoll? Sollte man nur einen einzigen Interrupt für das Empfangen verwenden?
>>Nur ich sehe gerade, ich habe die 0x580 und die 0x600 vertauscht: >>Der Master sendet die 0x600 und der Slave sendet die 0x580 als Antwort. Die IDs hier sind natürlich nur auf SDOs bezogen. >Es ist aber nicht zwingend notwendig dass >der Teilnehmer dann wieder Antwortet oder? Das sollte korrekt sein. >das ganze jetzt per Interrupt zu lösen. Das macht Sinn. >en einzigen Interrupt für Kommt drauf an, wann der/die Interrupts ausgelöst werden. Naja, da hast ja das Projekt nun doch noch zum Laufen bekommen ;-)
Ich kann z.B. für das COB-ID:0x601, COB-ID:0x181 und COB-ID:0x080 jeweils einen Interrupt einrichten. Macht Sinn mehrere Interrupt zu verwenden? Ich könnte ja auch alles in einem Interrupt tun. Zum Beispiel das Anzeigen der Daten könnte ich ja in der while(1) Schleife im Hauptprogramm tun.
Ich kann auf dem XC888 mehrere Interrupts für den Empfang von CAN Nachrichten aktivieren. Wahrscheinlich ist es sinnvoll nicht alles mit einem Interrupt zu realisieren, oder?
Ich weiß es nicht. ich kenne diesen XC888 nicht. Aber ich glaube, es reicht ein Interrupt (so oft kommt das ja nicht). Dieser Entscheidet dann, abhängig von der Nachricht, was zutun ist..
Die Synchronisationsnachricht 0x080 (vom Dongle), SDO Nachricht 0x600 + X (vom Dongle) sowie PDO Nachricht 0x180 + X (Informationen von einem Teilnehmer) sollte man schon in einer ISR empfangen. Die Auswertung sollte diese dann auch noch in der ISR gemacht werden oder sollte man diesen Teil in dem Hauptprogramm while(1) Schleife tun?
>sollte man schon in einer ISR empfangen Das bestätigte ich ja bereits- >Die Auswertung >sollte diese dann auch noch in der ISR gemacht werden oder sollte man >diesen Teil in dem Hauptprogramm while(1) Schleife tun? Da sich die Auswertung auf das Kopieren eines Datenbytes, (oder so ähnlich) beläuft, also nicht viel passiert. Kannst du das ruhig in der ISR tun. (pseudo code) X: eigene Knotennummer Y: Teilnehmernummer, auf die "gehört" wird ISR (CAN Meldung empfangen) { if (Meldungstyp = 0x080) { SendeDaten (aktuelle Tasten); // Sende Tastenstellung } if (Meldungstyp = 0x600+X) { Setze_NeuenTLN (); // hier wird Y ein neuer Wert zugewiesen } if (Meldungstyp = 0x180+Y) { AnzeigeLED(); // Anzeige der TLN-Daten } }
Danke nochmals Matthias. Also das mit dem Synchronisationsnachricht 0x080. Ist dies echt CanOpen konform? Macht man dies wirklich so? Wenn ich jetzt irgendwelche Daten von einem Teilnehmer auslesen möchte dann kann dies ja wie gesagt mit dem PDO tun. Ich sende z.B. vom Master ein Nachricht mit dem COB-ID: 0x601 Datenbyte3=0x01. Der Teilnehmer 1 empfängt diese Nachricht und sieht dass das Datenbyte3 auf 0x01 steht. Somit kann dieser seine Info (z.B. Schalterstellung) mit einer weiteren Nachricht mit der COB-ID:0x581 Datenbyte3 = Info Schalterstellung an den Master senden.
Eine Synchronisationsnachricht dient meineswissens bei CANopen dazu, die (vorher) gesendeten Prozessdaten (PDOs) zu aktivieren, also diese Daten zu nutzen. zB auf Ausgänge zu schalten. Somit kann garantiert werden, dass alle Ausgänge zeitgleich aktualisiert werden. (Das sit in AT sehr wichtig) >Wenn ich jetzt irgendwelche Daten von einem Teilnehmer auslesen möchte >dann kann dies ja wie gesagt mit dem PDO tun. >Ich sende z.B. vom Master ein Nachricht mit dem COB-ID: 0x601 >Datenbyte3=0x01. >Der Teilnehmer 1 empfängt diese Nachricht und sieht dass das Datenbyte3 >auf 0x01 steht. Somit kann dieser seine Info (z.B. Schalterstellung) mit >einer weiteren Nachricht mit der COB-ID:0x581 Datenbyte3 = Info >Schalterstellung an den Master senden. Die SDOs (0x580+X bzw 0x600+X) sind NICHT für Prozessdaten da! Also daruber sollten keine Schalterstellungen versendet werden. Nur Konfigurationsdaten. Wenn du Prozessdaten anfordern willst, dann solltest du KEIN Tx/RxSDO sondern das TxRxPDO nehmen. Bin aber nicht ganz sicher ob das CANopen konform ist. muss ich mal nachfragen. Aber warum willst du das denn anfordern?
Angehängte Dateien:
Hi Matthias, du hast gemeint, dass 0x581 und 0x601 vertauscht sind. Also laut Doku von CanOpen sieht man, dass COB-ID:0x581 der Master (Dongle) sendet. COB-ID:0x601 empfängt der Master (Dongle). Aber warum steht dann hier COB-ID:0x181 (Tx) ? Das sendet doch der Teilnehmer 1. Das verwirrt mich sehr.
Also ist die sichtweise doch nicht vom Master aus gesehen, sondern vom Teilnehmer (Slave).
Hi lippy, du hast folgendes geschrieben: >Die SDOs (0x580+X bzw 0x600+X) sind NICHT für Prozessdaten da! Also >daruber sollten keine Schalterstellungen versendet werden. Nur >Konfigurationsdaten. Ok stimmt eigentlich. Ich kann aber z.B. die Teilnehmernummer dem SDO übergeben und dann auf den Bus senden. >Wenn du Prozessdaten anfordern willst, dann solltest du KEIN Tx/RxSDO >sondern das TxRxPDO nehmen. Bin aber nicht ganz sicher ob das CANopen >konform ist. muss ich mal nachfragen. >Aber warum willst du das denn anfordern? Achso sende zuerst eine Anforderung mit 0x501. Diese Anforderung ist für den Teilnehmer 1 bestimmt. Dieser soll dann mit einem PDO die Schalterstellung oder auch einen Messwert auf den Bus senden. Dieses PDO kann dann vom Master ausgewertet werden. Genau da hab ich noch Probleme mit der Umsetzung.
Also mich verwirrt das mit den PDO's und SDO's immer noch. SDO senden: sichtweise Master (Dongle) SDO empfangen: sichtweise Master (Dongle) PDO(tx): sichtweise Teilnehmer (Slave) PDO(rx): sichtweise Teilnehmer (Slave)
>Also mich verwirrt das mit den PDO's und SDO's immer noch.
OK. Also:
Prozessdaten werden immer mit PDOs übertragen. Konfigurationen,
Parameter (unwichtig) immer mit SDOs.
Sende der Master ein PDO, dann ist es ein TxPDO mit 0x200+X.
Darauf hat der Slave mit 0x180+X zu antworten. Das ist dann (beim
Master) ein RxPDO.
Sendet der Master ein SDO, dann ist das ein TxSDO mit 0x600+X. EIne
Antwort wird vom Slave mit 0x580+X beantwortet. Dieses heißt beim Master
RxSDO.
Grund:
CAN-Bus wurde entwickelt, um im Auto viele System zu vernetzen. Diese
Systeme haben untereinander Daten ausgetauscht. Die Daten wurden nicht
nach Absender/Empfänger, sondern nach Inhalt der Nachricht adressiert.
CANopen nutzt nur die Physik und erzwingt durch das CANopen Protokoll
einen streng-deterministischen Ablauf. Das bedeutet, Antwortzeiten des
Systems werden berechenbar, da immer nur der Master sendet bzw das
Senden initiieren kann.
So. Bin jetzt im Wochenende
Hi Matthias, letzte oder auch vorletzte Woche hast du mir mitgeteilt, dass ich folgende COB-ID benutzen soll: Sync Message COB-ID: 0x080 SDO Message COB-ID:0x580+X und COB-ID:0x600+X PDO Message COB-ID:0x180+X und COB-ID:0x200+X X soll die Nummer der Teilnehmer sein. Wenn der TLN2 die PDO Message 0x181 von dem TLN1 lesen möchte, dann muss der Master (Dongle) eine SDO Message mit der COB-ID:0x582 und Datenbyte1:0x01 senden. Anschließend muss mit einer Sync. Message COB-ID:0x080 und Datenbyte1:0x01 der TLN1 aufgefordert werden die PDO Message mit dem COB-ID:0x181 und Datenbyte:Schalterstellung auf den Bus zu senden. Wie kann ich das PDO Message COB-ID:0x200+X und SD0 Message COB-ID:0x600+X verwenden/nutzen? Ich möchte z.B. irgendwelche Konfigurationsdaten (Teilnehmernummer) von einem TLN auslesen können und der Master soll die Info dann verarbeiten. Tue ich dies damit, indem z.B. eine SDO Message COB-ID:0x582 und Datenbyte2 auf den Bus vom Master aus gesendet werden soll. Der TLN2 empfangt diese Message und sieht dass das Datenbyte2 auf 0x02 steht. Daraufhin sendet dieser die Konfigurationsdaten (Teilnehmernummer) mit der SDO Message COB:0x602 Datenbyte2:Teilnehmernummer auf den Bus. Somit kann der Master die Message weiter verarbeiten. Schönes Wochenende Matthias.
Durch das Sync Message COB-ID:0x080 wird veranlasst das die Kommunikation synchron abläuft. Um aber Konfigurationsdaten von einem TLN anzufordern, benötigt man nicht unbedingt eine SYNC Message. Dies kann man auch so lösen das der Master ein SDO Message sendet und darauf hin der TLN mit einem SDO Message wieder antwortet. Stimmt dies so?
----------- ---------------
Master | TxPDO 0x200*+X ===> | Slave
| TxSDO 0x600 +X ===> |
| |
| RxSDO 0x580 +X <=== |
| RxPDO 0x180*+X <=== |
----------- -----------------
Mir ist noch immer nicht so ganz klar, wie oder für was ich die
COB-ID's: 0x200+X und 0x580+X verwenden könnte.
Guten Morgen Matthias, letzte oder auch vorletzte Woche hast du mir mitgeteilt, dass ich folgende COB-ID benutzen soll: Sync Message COB-ID: 0x080 SDO Message COB-ID:0x580+X und COB-ID:0x600+X PDO Message COB-ID:0x180+X und COB-ID:0x200+X X soll die Nummer der Teilnehmer sein. Wenn der TLN2 die PDO Message 0x181 von dem TLN1 lesen möchte, dann muss der Master (Dongle) eine SDO Message mit der COB-ID:0x582 und Datenbyte1:0x01 senden. Anschließend muss mit einer Sync. Message COB-ID:0x080 und Datenbyte1:0x01 der TLN1 aufgefordert werden die PDO Message mit dem COB-ID:0x181 und Datenbyte:Schalterstellung auf den Bus zu senden. Wie könnte ich das PDO Message COB-ID:0x200+X und SD0 Message COB-ID:0x600+X verwenden/nutzen? Ich möchte z.B. irgendwelche Konfigurationsdaten (Teilnehmernummer) von einem TLN auslesen können und der Master soll die Info dann verarbeiten. Tue ich dies damit, indem z.B. eine SDO Message COB-ID:0x582 und Datenbyte2 auf den Bus vom Master aus gesendet werden soll. Der TLN2 empfangt diese Message und sieht dass das Datenbyte2 auf 0x02 steht. Daraufhin sendet dieser die Konfigurationsdaten (Teilnehmernummer) mit der SDO Message COB:0x602 Datenbyte2:Teilnehmernummer auf den Bus. Somit kann der Master die Message weiter verarbeiten.
>----------- --------------- >Master | TxPDO 0x200*+X ===> | Slave > | TxSDO 0x600 +X ===> | > | | > | RxSDO 0x580 +X <=== | > | RxPDO 0x180*+X <=== | >----------- ----------------- >Mir ist noch immer nicht so ganz klar, wie oder für was ich die >COB-ID's: 0x200+X und 0x580+X verwenden könnte. >>Ich möchte z.B. irgendwelche Konfigurationsdaten (Teilnehmernummer) von >>einem TLN auslesen können und der Master soll die Info dann verarbeiten. >>Tue ich dies damit, indem z.B. eine SDO Message COB-ID:0x582 und Jein. Wenn du Konfigurationsdaten vom Master zum Slave übertragen willst, dann nimmst du ein TxSDO 0x600+X, der Slave antwortet mit einem RxSDO: 0x580+X (zb Mit seinen Konfigdaten) >Wie kann ich das PDO Message COB-ID:0x200+X Damit kannst du Prozessdaten an einem Teilnehmer senden. Also könnte der Master an einen Teilnehmer irgendwelche Daten senden, die der Teilnehmer dann ausgibt.
Achso aber der TLN muss dann aber nicht zwingend Antworten, indem er ein SDO mit COB-ID:0x580+X sendet oder? Ich kann mir ja das Datenbyte3 verwenden. Wenn dieses auf 0x05 steht, dann soll dieser TLN ein SDo 0x580+X senden. Der Master kann ja diese Info dann auswerten.
>n aber nicht zwingend Antworten richtig. Es gibt bestätigte und unbestätigte Dienst. >a das Datenbyte3 Solltest du dir mal in Ruhe überlegen. So langsam klingts wirr. Am besten mal notieren, was wer wohin schicken können soll. dann weitersehen.
(SDO) COB-ID:0x600+X Datenbyte1=NodeId Datenbyte2=Data Length (SYNC)COB-ID:0x080 Datenbyte1=NodeId Datenbyte2=Data Length (PDo) COB-ID:0x180+X Datenbyte1 - Datenbyte8: Nutzdaten z.B. Schalterst. Nun möchte ich irgendwelche Konfigurationsdaten von einem Teilnehmer anfordern und zwar über den Master (Dongle). Dazu hab ich mir überlegt das SDO auszubauen. Dazu könnte ich doch vom SDO das 3. Datenbyte verwenden. Wenn dieses auf 0x01 steht soll der Teilnehmer anworten mit der SDO 0x580+X. (Konfigurationsdaten: Teilnehmer Nummer, Baudrate, usw.) Beispiel: Master sendet: 0x080 Datenbyte1:0x02 Datenbyte2:0x01 0x601 Datenbyte1:0x02 Datenbyte2:0x01 Der Teilnehmer2 sendet das PDO mit den Nutzdaten Der Teilnehmer1 empfängt die Nachricht 0x0182 und gibt die Info auf den LED's aus. Jetzt könnte man statt 0x601 Datenbyte1:0x02 Datenbyte2:0x01 noch das 3. Datenbyte ins Spiel bringen. Wenn dieses auf 0x01 steht, sendet der Teilnehmer1 seine Konfigurationsdaten mit 0x581 auf den Bus.
Das Handling eines bestätigte und unbestätigte Dienst ist mit noch nicht so geläufig. Wie müsste man dies relaisieren?
(SDO) COB-ID:0x600+X Datenbyte1=NodeId Datenbyte2=Data Length (SYNC)COB-ID:0x080 Datenbyte1=NodeId Datenbyte2=Data Length (PDo) COB-ID:0x180+X Datenbyte1 - Datenbyte8: Nutzdaten z.B. Schalterst. Nun möchte ich irgendwelche Konfigurationsdaten von einem Teilnehmer anfordern und zwar über den Master (Dongle). Dazu hab ich mir überlegt das SDO auszubauen. Dazu könnte ich doch vom SDO das 3. Datenbyte verwenden. Wenn dieses auf 0x01 steht soll der Teilnehmer anworten mit der SDO 0x580+X. (Konfigurationsdaten: Teilnehmer Nummer, Baudrate, usw.) Beispiel: Master sendet: 0x080 Datenbyte1:0x02 Datenbyte2:0x01 0x601 Datenbyte1:0x02 Datenbyte2:0x01 Der Teilnehmer2 sendet das PDO mit den Nutzdaten Der Teilnehmer1 empfängt die Nachricht 0x0182 und gibt die Info auf den LED's aus. Jetzt könnte man statt 0x601 Datenbyte1:0x02 Datenbyte2:0x01 noch das 3. Datenbyte ins Spiel bringen. Wenn dieses auf 0x01 steht, sendet der Teilnehmer1 seine Konfigurationsdaten mit 0x581 auf den Bus.
>Dazu könnte ich doch vom SDO das 3. Datenbyte verwenden
Naja, man könnte auch vorher nochmal über alles nachdenken:
zum Thema SDOs: Konfigurationsdaten, was soll alles so übertragen
werden:
- Teilnehmernummer, auf die gehört werden soll [0x01],
- Abfrage des aktuell zu hörenden Teilnehmers ]0x02],
- ...
(denk dir was aus)
Dann würde ich diese Liste durchnummerieren (siehe Zahlen in [])
Diese Zahl würde ich als ERSTES Datenbyte beim SDO senden mit 0x600+X.
Abhängig davon haben die zweiten..achten Datenbytes eine enstprechende
UNTERSCHIEDLICHE Bedeutung:
bsp:
Datenbyte #1: 0x01 (Konfigdaten: TLN auf den gehört werden soll)
Datenbyte #2: hier ist die TLN-Nummer, auf die gehört werden soll.
Datenbyte #3..8: nicht vorhanden, oder weitere TLN
Der DataLengthCode richtet sich IMMER nach der aktuellen Anzahl Daten
weiteres Bsp:
Datenbyte #1: 0x02 (Konfigdaten: TLN Nummer abfragen)
keine weiteren Datenbytes. Hier folgt eine Antwort mit 0x580+X. Aufbau
der Antwort (hier jetzt) noch offen.
Ich weiß nicht, ob das alles CANopen konform ist, aber so baue ich
Bus-protokolle auf.
PS: Mach mal ruhig! Ist schönes Wetter => BAGGERSEE
Ich verstehe deinen letzten Beitrag nicht. >Dann würde ich diese Liste durchnummerieren (siehe Zahlen in []) Ich weiss nicht wo und welche Nummer. >Diese Zahl würde ich als ERSTES Datenbyte beim SDO senden mit 0x600+X. Das verstehe ich nicht. In dem ersten Datenbyte soll doch nur die Teilnehmernummer stehen oder? >Abhängig davon haben die zweiten..achten Datenbytes eine enstprechende >UNTERSCHIEDLICHE Bedeutung: >bsp: >Datenbyte #1: 0x01 (Konfigdaten: TLN auf den gehört werden soll) >Datenbyte #2: hier ist die TLN-Nummer, auf die gehört werden soll. >Datenbyte #3..8: nicht vorhanden, oder weitere TLN >Der DataLengthCode richtet sich IMMER nach der aktuellen Anzahl Daten Warum sollen Datenbyte1 und Datenbyte2 die gleich Info enthalten? >weiteres Bsp: >Datenbyte #1: 0x02 (Konfigdaten: TLN Nummer abfragen) >keine weiteren Datenbytes. Hier folgt eine Antwort mit 0x580+X. Aufbau >der Antwort (hier jetzt) noch offen. Das verstehe ich auch nicht. Wenn ich ein SDO an einen Teilnehmer sende muss man doch nicht zwangsläufig eine Antwort (z.B. 0x581) senden oder?
>Wenn ich ein SDO an einen Teilnehmer sende muss man doch nicht >zwangsläufig eine Antwort (z.B. 0x581) senden oder? Das ist richtig. Den Rest hast du aber wirklich nicht verstanden.: >>Abhängig davon haben die zweiten..achten Datenbytes eine enstprechende >>UNTERSCHIEDLICHE Bedeutung: >>bsp: >>Datenbyte #1: 0x01 (Konfigdaten: TLN auf den gehört werden soll) >>Datenbyte #2: hier ist die TLN-Nummer, auf die gehört werden soll. >>Datenbyte #3..8: nicht vorhanden, oder weitere TLN >>Der DataLengthCode richtet sich IMMER nach der aktuellen Anzahl Daten >Warum sollen Datenbyte1 und Datenbyte2 die gleich Info enthalten? Stimmt nicht. Meine Idee war folgende (gilt nur für SDOs vom Master): Das erste Datenbyte bestimmt, was das SDO bewirken soll. Also so eine Art Kommando/Befehl: Ist dieses 0x01, dann willst du dem Teilnehmer mitteilen, auf welchen (anderen) Teilnehmer er (ab jetzt) hören soll. Das meinte ich mit >>>"Datenbyte #1: 0x01 (Konfigdaten: TLN auf den gehört werden soll)". Die eigentliche Information selbst befindet sich in Datenbyte2. Deshalb >>>"Datenbyte #2: hier ist die TLN-Nummer, auf die gehört werden soll." Weitere Datenbytes werden hier nicht benötigt. Deshalb DLC(data length code)=2. Möchtest du jetzt allerdings den Teilnehmer nach seiner Konfiguration BEFRAGEN (also auf welchen TLN er gerade hört), so wird das erste Datenbyte, welches ja ein Kommando/Befehl darstellt, auf 0x02 gesetzt. So ist das gemeint.
Achso ok. Beispiel1: Master sendet 0x601 und Datenbyte1:0x02 Datenbyte2:0x02 Daraufhin antwortet der Teilnehmer1 mit 0x581 und Konfigurationsdaten(dieLänge ist abhängig vom Datenbyte2 der Nachricht 0x601) Beispiel2: Master sendet 0x601 und Datenbyte1:0x01 Datenbyte2:0x02 Der Teilnehmer1 antowrtet nun nicht mit 0x581 und Konfigurationsdaten. Der Teilnehmer1 soll jetzt nur auf das PDO 0x181 hören.
Ich muss mich korrigieren: Beispiel1: Master sendet 0x601 und Datenbyte1:0x02 Datenbyte2:0x02 Daraufhin antwortet der Teilnehmer1 mit 0x581 und Konfigurationsdaten(dieLänge ist abhängig vom Datenbyte2 der Nachricht 0x601). Zusätzlich soll noch der Teilnehmer1 auf das PDO 0x181 hören. Beispiel2: Master sendet 0x601 und Datenbyte1:0x01 Datenbyte2:0x02 Der Teilnehmer1 antwortet nun nicht mit 0x581 und Konfigurationsdaten. Der Teilnehmer1 soll jetzt nur auf das PDO 0x181 hören.
Naja, so etwa. aber auch nicht ganz: >Master sendet 0x601 und Datenbyte1:0x02 Datenbyte2:0x02 (Das bsp deckt sich nicht mit meinem bsp, macht aber erstmal nix) Wenn das das bedeuten soll: >Daraufhin antwortet der Teilnehmer1 mit 0x581 und >Konfigurationsdaten(dieLänge ist abhängig vom Datenbyte2 der Nachricht >0x601) was soll dann das Datenbyte2 aussagen?? Datenbyte1 ist das Kommando "sende mir mal deine konfiguration" datenbyte2 trägt keine info und sollte weggelassen werden. >Beispiel2: >Master sendet 0x601 und Datenbyte1:0x01 Datenbyte2:0x02 >Der Teilnehmer1 antowrtet nun nicht mit 0x581 und Konfigurationsdaten. >Der Teilnehmer1 soll jetzt nur auf das PDO 0x181 hören. Es sollte eher PDO 0x182 heißen. dann würde es passen.
Danke. Ich hab voll den Mist geschrieben. Ja ok ich meinte auch 0x182.
Mit dem Kommando (Datenbyte1) kann zum Beispiel festgelegt werden ob
eine Antwort vom Teilnehmer erfolgen soll oder nicht.
Kommando (Datenbyte1):
0x01 = TLN auf den gehört werden soll
0x02 = TLN soll Konfigurationsdaten zum Master (CanBus) senden mit 0x581
0x03 = TLN auf den gehört werden soll +
TLN soll Konfigurationsdaten zum Master (CanBus) senden mit 0x581
Datenbyte2: kann eventuell die Länge der Konfigurationsdaten festgelegt
werden, bzw. wieviel Nutzdaten vom PDO empfangen werden dürfen.
Ja, so in etwa. Das Beispiel mit deinen drei Kommandobytes wäre denkbar. Am besten du machst erstmal eine Liste mit allen möglichen/notwendigen Befehlen die du so brauchst. Ich würde wahrsch deinen 0x03 befehl weglassen, und halt 0x01 und danach 0x02 senden. wäre sonst doppelt gemoppelt.. Oder ein Bit im Datenbyte als "Antwort erwünscht" verwenden... dann könnte nach ausführen des befehls die neue konfiguration zurückgesendet werden.. Aber ob mit 0x581 geantwortet wird, hat erstmal nix mit der SDO nachricht selbst zutun, sondern NUR mit der eigenen Knotennummer!
Wie gesagt, am besten erstmal ne Liste machen, was du für Befehle brauchst. Danach dann für jeden Befehl einzeln überlegen, welche bzw ob "zusätzlichen" Daten benötigt werden
Eigentlich wäre das bei mir schon alles. Mehr Kommandos brächte ich erstmal nicht. Kommando: 0x01 = TLN auf den gehört werden soll 0x02 = TLN soll Konfigurationsdaten zum Master senden mit 0x580+X Das mit der Datenlänge weiss ich nicht wie ich dies mit dem SDO realisieren könnte. Mit der Datenlänge möchte ich festlegen wieviel Nutzdaten die PDO Nachricht beinhaltet.
Dann hast du halt erstmal nur zwei Kommandos. Sowas kann ja bei Bedarf erweitert werden. >Das mit der Datenlänge weiss ich nicht wie ich dies mit dem SDO >realisieren könnte. Mit der Datenlänge möchte ich festlegen wieviel >Nutzdaten die PDO Nachricht beinhaltet. Wieso unterscheidet sich das? gib mal paar Beispiele welche/wieviel Nutzdaten du hast
Die Nutzdaten können unterschiedlich lange sein. Je nachdem was die SYNC Nachricht 0x080 sendet. SYNC Nachricht: Datenbyte1: welche TLN soll die PDO 0x180+X senden Datenbyte2: Datenlänge der Nutzdaten (1 bis 8 Bytes) SDO Nachricht: soll dann die Datenlänge festlegen die dann empfangen werden können.
(SYNC)COB-ID:0x080 Datenbyte1=NodeId Datenbyte2=Data Length (PDO) COB-ID:0x180+X Datenbyte1 ... Datenbyte8: Nutzdaten z.B. TLN Nr. (SDO) COB-ID:0x600+X Datenbyte1=Kommando Datenbyte2=Data Length
>Datenbyte2=Data Length >Datenbyte2: Datenlänge der Nutzdaten (1 bis 8 Bytes) Versteh ich nicht. Warum das???? Es gibt doch einen extra wert, den data-length-code... Komm da grad nicht mit
(SYNC)COB-ID:0x080 DLC=0...8,Datenbyte1=NodeId,Datenbyte2...8=kann für andere Zwecke verwendet werden. (PDO) COB-ID:0x180+X DLC=0...8,Datenbyte1...8=Nutzdaten z.B. TLN Nr. (SDO) COB-ID:0x600+X DLC=0...8,Datenbyte1=Kommando Steht DLC auf 0x05,dann soll 5 Datenbytes vom PDO empfangen werden. Steht DLC auf 0x01,dann soll 1 Datenbyte vom PDO empfangen werden.
>PDO) COB-ID:0x180+X DLC=0...8,Datenbyte1...8=Nutzdaten z.B. TLN Nr. ^^^^^^ Hä??? >Steht DLC auf 0x05,dann soll 5 Datenbytes vom PDO empfangen werden. >Steht DLC auf 0x01,dann soll 1 Datenbyte vom PDO empfangen werden. Das ist schon klar, aber wozu soll DIESE information IN DEN datenbytes SELBST nochmal stehen???
(SYNC)COB-ID:0x080 DLC=0...8,Datenbyte1=NodeId,Datenbyte2...8=kann für andere Zwecke verwendet werden. (PDO) COB-ID:0x180+X DLC=0...8,Datenbyte1...8=Nutzdaten z.B. Schalterstellungen oder andere Daten (SDO) COB-ID:0x600+X DLC=0...8,Datenbyte1=Kommando Steht DLC auf 0x05,dann soll 5 Datenbytes vom PDO empfangen werden. Steht DLC auf 0x01,dann soll 1 Datenbyte vom PDO empfangen werden. >Das ist schon klar, aber wozu soll DIESE information IN DEN datenbytes >SELBST nochmal stehen??? Dies hab ich doch entfernt. Die Länge wird bestimmt durch den data length code (DLC)
Also mit der SYNC Nachricht muss ich doch trotz all dem die Länge der PDO Nutzdaten angeben. Dies muss ich doch mit einem Datenbyte von der SYNC Nachricht tun. (SYNC)COB-ID:0x080 DLC=0...8,Datenbyte1=NodeId,Datenbyte2=DLC für PDO Nutzdaten,Datenbyte3...8=kann für andere Zwecke verwendet werden. Anders kann ich mir dies nicht vorstellen, wie es noch gehen könnte.
>m die Länge der PDO Nutzdaten angeben.
Warum unterscheiden die sich?
Dann soll der PDO immer 8 Datenbytes (Nutzdaten) senden. Mit dem SDO kann ich ja dann auswählen wieviel Nutzdaten der TLN empfangen soll.
>Warum unterscheiden die sich?
Was meinst du damit?
Im SDO muss ich doch die gewünschte Datenlänge vom PDO angeben.
Hi Matthias, ich hoffe du kannst mich verstehe. Wahrscheinlich denke ich immer viel zu kompliziert. Deine Hilfe ist sehr hilfreich für mich, von daher nochmals danke!
>Im SDO muss ich doch die gewünschte Datenlänge vom PDO angeben.
Wozu das?
Der Teilnehmer sendet per PDO seine Nutzdaten alle weg.
Warum soll da irgendeine Länge parametriert werden..?
Ok dann parametriere ich die Datenlänge nicht über das SDO. Ich lasse es ganz weg. In dem SDO gebe ich nur das Kommando sowie die TLN Nr. an, auf welche PDO der TLN reagieren soll. Was kann man eigentlich noch alles mit dem SDO tun? Welche Kommandos könnte man noch ergänzen?
>ch lasse es ganz weg. In dem SDO gebe ich nur das Kommando sowie die >TLN Nr. an, auf welche PDO der TLN reagieren soll. Halte ich so für sinnvoll. >Was kann man eigentlich noch alles mit dem SDO tun? Welche Kommandos >könnte man noch ergänzen? Keine Ahnung was du so alles damit vorhast... Lass dir was einfallen... Ich habe dir jedenfalls Tipps gegeben um das zum Laufen zu Bringen... Sind aber nur Tipps. Ideen was du willst kann ich nicht bringen.. Nur Tipps zum Umsetzen...
Guten Morgen Matthias L., auf jeden Teilnehmer habe ich zuächst mal Variablen festgelegt. Die Variablen sind vom Typ 1 x float, 1 x integer, 2 x char. Diese Daten kann ich über ein PDO senden und empfangen. Die float Variable beinhaltet den AD Wandlerwert, die Integer Variable für sonstiges, eine char Variable ist für die Anzeige der LED's und die andere char Variable soll für Einstellungen/Kommandos sein. Wenn ich Daten nur zwischen Master und Slave(TLN) versenden bzs.empfangen möchte kann ich die PDO(Tx) und PDO(Rx) verwenden. Mit PDO(Rx) kann der Master die Daten an einen Teilnehmer senden. Z.B. Wert für LED Anzeige bzw. Kommando ob der Teilnehmer mit dem PDO(Tx) seine Daten (AD Werte) auf den Bus senden soll oder nicht. Wäre dieses Vorgehen ok so? Wie gesagt die SYNC und SDO Nachrichten lasse ich für diese Betrachtung mal weg.
Für eine reine Master Slave kommunikation kann ich ja zjnächst nur die PDO(Tx) und PDO(Rx) benutzen oder? Die Slaves sollen untereinander nicht kommunizieren.
Hi Matthias L, mit PDO(Tx) 0x180+X sende ich die Nutzdaten von einem Teilnehmer. Was macht dann der PDO(Rx) genau? Soll damit die Nutzdaten des anderen Teilnehmers empfangen werden können? Mit dem PDO(Rx) 0x600+X sende ich zum einen ein sogenanntes Kommando (Datenbyte1) und die anderen Datenbytes2...8 sende ich Nutzdaten. Datenbyte2 = char Datenbyte3..4 = integer Datenbyte5..8 = float Diese Variablen enthält zunächst jeder Teilnehmer. Diese werden entsprechend wie das Datenbyte1(Kommando) aussieht geschrieben bzw. veranlasst dass das PDO(Tx) 0x180+X gesendet wird. Im Datenbyte3..4 beinhaltet den AD Wandlerwert Im Datenbyte5..8 umgerechneter AD Wert in Spannung (Beispiel:2,56V)
>mit PDO(Tx) 0x180+X sende i.. Jein. Das ist aber ein RxPDO (weil vom Master aus gesehen). Sonst korrekt. >Was macht dann der PDO(Rx) genau? Soll damit die Nutzdaten des anderen >Teilnehmers empfangen werden können? Hier ist dann das TxPDO gemeint. COB: 0x200+X. Damit können Nutzdaten (zB Ausgänge) vom Master zu einem Slave (Teilnehmer) gesendet werden...
Mit COB-ID:200+X sende ich eine Nachricht an einen Teilnehmer. Mit dem Datenbyte1 sage ich dann dem Teilnehmer was er tun soll. Zum Beispiel 0x01 bedeutet bei mir, schreibe Datenbyte2...Datenbyte8 in die entsprechenden Variablen. Wenn ich nun vom Teilnehmer den AD Wert usw. auslesen möchte dann sende ich 0x02. Der Teilnehmer sendet dann seine Daten mit der COB-ID:0x180+X. Das wäre jetzt ein reiner MASTER SLAVE Kommunikation.
>Das wäre jetzt ein reiner MASTER SLAVE Kommunikation.
Ja, aber CAN ist eher dazu da, Nachrichten ereignisgesteuert abzusenden.
CANopen funktioniert nach Master-Slave, damit ein deterministisches
Verhalten entsteht.
Wie du es genau löst, ist dir überlassen. Weil du das Projekt eh nicht
KOMPLETT CANopen-konform bekommst. Das sollte aber egal sein..
Also mit meinen Tips hast dus zum Laufen gebracht. Probier weiter, frag
weiter und sammel Erfahrungen...
Guten Morgen Matthias L, was meinst du mit "Nachrichten ereignisgesteuert absenden"? Mit COB-ID:200+X sende ich eine Nachricht an einen Teilnehmer. Mit dem Datenbyte1 sage ich dann dem Teilnehmer was er tun soll. Zum Beispiel Datenbyte1:0x01 bedeutet bei mir, schreibe Datenbyte2...Datenbyte8 in die entsprechenden Variablen. Wenn ich nun vom Teilnehmer den AD Wert usw. auslesen möchte dann sende ich COB-ID:200+X und Datenbyte1:0x02. Der Teilnehmer sendet dann seine Daten mit der COB-ID:0x180+X. Dies ist doch ereignisgesteuert und zwar durch das Datenbyte1. So verstehe ich dies.
>Dies ist doch ereignisgesteuert und zwar durch das Datenbyte1. So >verstehe ich dies. Nein. Mit ereignisgesteuert meine ich, sobald sich der Eingang/die Temperatur.. ändert, sendet der Teilnehmer VON ALLEIN diese neue Information (mit COB-ID:0x180+X).
Zum Beispiel so:
if(ADwert != ADwert)
{
TransmitCANMessage(...);
}
Dies bedeutet doch der jeweilige Teilnehmer prüft ständig die Variablen auf ihre Veränderung. Beispiel:ADwert
>if(ADwert != ADwert)
Naja, das wird NIE wahr!
Eher so:
1 | ADwert = ADC; |
2 | |
3 | if ( ADwert_alt != ADwert ) |
4 | {
|
5 | ADwert_alt = ADwert; |
6 | TransmitCANMessage(...); |
7 | }
|
Bei digitalen Eingängen mag das so gehen, aber bei Analogen nicht: Da Solltest allerdings über eine Filterung, Zeit, etc nachdenken. Weil der ADwert bei Wandlungen immer (um ein zwei LSB) schwankt...
Danke für den Tip. Wie könnte man das eingelesene Signal vom AD Wandler per Software filtern? Ist dies überhaupt möglich?
>Ist dies überhaupt möglich?
Unmöglich ist garnichts ;-)
Du könntest ein IIR Filter nehmen. ALso ein PT1 diskret aufgebaut.
Über die Abtastfrequenz und Zeitkonstante musst du dir Gedanken machen.
Doer einfacher wäre es, nur einen neuen Wert zu übertragen, wenn sich
der neue um ... gegenüber dem alten verändert hat..
Kann dies auch per Software (Ansi C) realisiert werden? Beispiel Notch Filter!
>ann dies auch per Software (Ansi C) realisiert werden?
Na sicher doch. Ist ja nur eine Differenzengleichung:
Stichwort: digitale Filter, mal im DSP-Forum schnüffeln
Noch eine Sache verstehe ich nicht ganz. Verwendet die PDO Botschaft überhaupt das RTR Bit vom Telegramm? Macht dies überhaupt Sinn dieses zu verwenden?
Thread beobachten
Seitenaufteilung abschaltenBitte 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.