mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Unterstützung - eigenes CAN Protokoll


Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für jede Anregung bin ich sehr dankbar! Hat jemand vielleicht eine 
bessere Lösung?

Autor: ole (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nö!

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi ole!

Was meinst du mit "nö" ? Ist meine vorgeschlagene Lösung sinnvoll?

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Hardy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Boris H. (eddi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_Verb...

Gruß,
eddi

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MisterT (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo MisterT,
kannst du mir ein konkretes Zahlenbeispiel geben?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So stelle ich mir das ganze vor.

Autor: Frank Erdrich (erdi-soft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab gedacht, das ich den Identifier so definiere:

ID: Teilnehmernrummer + Message Objekt Nr
8 Daten Bytes: Nutzdaten z.B. Schalterstellung

Autor: Frank Erdrich (erdi-soft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Frank Erdrich (erdi-soft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...)

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank Erdrich (erdi-soft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
- 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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Frank Erdrich (erdi-soft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joa, stimmt. Aber der Einfachheit halber erstmal nur die ID. :)

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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)

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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!)

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
In diesem Bild kann man sehen, wie ein MO mit DAVE konfiguriert wird.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Teilnehmer1: LED-Block   : 2 + 1 = 3
Teilnehmer2: DIP-Schalter: 1 + 2 = 3
?

Autor: Frank Erdrich (erdi-soft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Meyer L. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 
;-)

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die DIP Schalter sind für die Knotennummer?

Welche Eingänge, Ausgänge, das ist doch das interessante
Ja, und weiter?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hoffe ich hab mich diesmal etwas verständlicher ausgedrückt.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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!

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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!

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum Murks?

JA GENAU! Der Bediener soll entscheiden, welche Anzeige gerade 
aktualisiert werden soll.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry ich meine: per "Aktualisieren" Befehl!

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie meinst du das mit dem CO-ID 0x180 + KD ?
Das verstehe ich nicht.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 !!!!!!!!

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 !!!!!!!!

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>1 Message Objekt das sendet
Ok

>und 4 Message Objekte die empfangen können.
Wieso 4?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>2 Message Objekte damit die Schalterstellungen der anderen Teilnehmer
>empfangen werden können.

Wieso denn DER anderen?  DES EINEN anderen!!!!!!!!!!!!!

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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!

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also das verstehe ich nicht!

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry Matthias, ich hab noch was erledigen müssen, desshalb konnte ich 
nicht gleich antworten.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 !!!

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?????

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... oder mit dem Acceptance Filter arbeiten?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arbitration Register 0x182 = 110000010

Acceptance Register  0x182 = 110000010

|
|
--> Nachricht kann empfangenn werden

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das klingt zumindest vernünftig. (Obs über irgendwelche Masken geht, 
weiß ich nicht)

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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???

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja genau!

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hab ich in meiner Idee so festgelegt. (aber die Zahlen orientieren 
sich an CANopen) SO hab ich die COB-IDs hier implementiert.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weisst du wo ich eine Liste (Beschreibung) finde mit allen COB-ID's?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Netz habe ich was gefunden:

>>http://www.frenzel-berg.de/download/datasheet/cano...

COB-ID:0x80 steht aber für Synchronisation und nicht zum senden von 
Nachrichten. Verstehe ich nicht!

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich verwende ja folgende COB-ID's:

0x180 + X
0x500 + X
0x080


Welche von denen sind SDO oder PDO?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 ;-)

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-----------                             ---------------
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>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 ;-)

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist eigentlich die übliche Vorgehensweise?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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
  }
}

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Patrick (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ist die sichtweise doch nicht vom Master aus gesehen, sondern vom 
Teilnehmer (Slave).

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-----------                             ---------------
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Matthias, bist du gerade im Urlaub?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>-----------                             ---------------
>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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist meine Beschreibung verständlich?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Handling eines bestätigte und unbestätigte Dienst ist mit noch nicht 
so geläufig. Wie müsste man dies relaisieren?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(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

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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???

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(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)

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie würdest du genau das mit dem DLC lösen?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>m die Länge der PDO Nutzdaten angeben.

Warum unterscheiden die sich?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann soll der PDO immer 8 Datenbytes (Nutzdaten) senden.
Mit dem SDO kann ich ja dann auswählen wieviel Nutzdaten der TLN 
empfangen soll.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Warum unterscheiden die sich?

Was meinst du damit?

Im SDO muss ich doch die gewünschte Datenlänge vom PDO angeben.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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..?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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...

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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...

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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...

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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).

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso! Ja und wie realisiert man dies genau?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum Beispiel so:

if(ADwert != ADwert)
    {
        TransmitCANMessage(...);
    }

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dies bedeutet doch der jeweilige Teilnehmer prüft ständig die Variablen 
auf ihre Veränderung. Beispiel:ADwert

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>if(ADwert != ADwert)

Naja, das wird NIE wahr!

Eher so:
ADwert = ADC;

if ( ADwert_alt != ADwert )
{
    ADwert_alt = ADwert;
    TransmitCANMessage(...);
}


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...

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Tip. Wie könnte man das eingelesene Signal vom AD Wandler 
per Software filtern? Ist dies überhaupt möglich?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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..

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann dies auch per Software (Ansi C) realisiert werden?
Beispiel Notch Filter!

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch eine Sache verstehe ich nicht ganz.
Verwendet die PDO Botschaft überhaupt das RTR Bit vom Telegramm?
Macht dies überhaupt Sinn dieses zu verwenden?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das weiß ich nicht.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habs nur mal wo gelesen. Also ich vergesse dies mal.
Wertest du eigentlich auch Fehler von den jeweiligen Teilnehmern aus?
Zum Beispiel: CAN Bus off usw, Telegramm fehlerhaft usw.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da ja nun über 150 Posts nur Zwiegespräch sind, wärs nicht einfacher, 
sich per E-Mail weiter zu unterhalten ?

Dann braucht ihr nicht immer so weit runter zu scrollen.


Lesen tut diesen Monsterthread eh keiner mehr außer euch beiden.


Peter

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok ich werde mal meine E-Mail Adresse hier angeben:

>>patrick_elektronik@web.de

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oder icq. 254269548

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schade, ich hab leider kein ICQ!
Könntest du mir nicht deine E-Mail Adresse geben?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.