Unterstützung - eigenes CAN Protokoll

Aufbau Telegramm zur Anforderung (CAN Dongle):

11 Bit ID: Nummer 1 bis 5 (Anzahl der Anforderungen vom CAN Dongle)

1 Datenbyte = DLC
2 Datenbyte = Quelle Baugruppenadresse
3 Datenbyte = Quelle Message Objekt Nummer
4 Datenbyte = Ziel Baugruppenadresse
5 Datenbyte = Ziel Message Objekt Nummer

Auf den XC888 Boards müsste ich dann diese Anforderungen vom CAN Dongle 
interpretieren und dementsprechend eine Nachricht senden.

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

nö!

Hi ole!

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

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.

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!

Tja und wie könnte man z.B. dies verwirklichen?
Definitiv muss ich doch von einer Stelle aus sagen, was gemacht wird.
Also jetzt bin ich verwirrt.

Jede CAN Nachricht hat eine ID. Anhand der ID bestimmst du den 
Empfänger.
Wenn du eine Nachricht schicken willst, schreibst du sie auf den Bus. 
Nun liest jeder CAN Teilnehmer die Nachricht und entscheidet dann ob sie 
für ihn ist oder nicht.
Du musst also in jedem Teilnehmer konfigurieren, welche IDs er verwerten 
soll und welche nicht.
Du adressierst mit einer ID also keinen Empfänger in dem Sinne, sondern 
du konfigurierst die Empfänger dahingehend, dass du sagst welche IDs sie 
verabeiten sollen und welche nicht.

Hallo MisterT,
kannst du mir ein konkretes Zahlenbeispiel geben?

Teilnehmer1:  Teilnehmer2:  Teilnehmer3:  CAN-Dongle
LED           LED           LED           gibt Anweisungen was zu tun 
ist
Schalter      Schalter      Schalter

Ich muss doch dem Teilnehmer2 sagen, dass er die Daten von den 
Schalterstellungen auf den Bus schicken soll und das der Teilnehmer 3 
diese Info auf den LEDs ausgeben soll.

So stelle ich mir das ganze vor.

Danke für die Link. Diese kenne ich beriets schon. Ich weiss immer noch 
nicht wie ich mein Protokoll gestallten soll. Also ich stehe voll auf 
dem Schlauch!

Hi Frank, soll jeder Teilnehmer dann die Nachricht mit der ID 0x100 
empfangen können? Wo steckt dann die Info drin welcher teilnehmer diese 
Nachricht auswerten (Daten anzeigen auf LED ) soll?

Ich hab gedacht, das ich den Identifier so definiere:

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

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.

Warum machst du das nicht Event gesteuert?

Wenn ich das richtig verstanden habe, soll zB Schalterplatine1 an 
Lampenplatine senden. Das würde doch reichen, wenn das nur dann 
passiert, wenn wirklich (an den Eingängen) was passiert?

Somit bekommt jede Nachricht eine Nummer (COB-ID) abhängig vom Inhalt 
der Nachricht.
zB
(in hex)
Schalterplatinen: 1 + X

Lampenplatinen:   2 + X    (was auch immer die senden sollten)

Temperaturpl.     3 + X

wasweißich        4 + X
...usw.
X: (0..255) durchnummerierte Teilnehmer, vielleicht per knotenschalter 
einstellbar


Falls auf einer Platine mehreres drauf ist, zB Schalter und Temperatur, 
so wird diejenige COB-ID genommen, die zum Nachrichteninhalt gehört.

Jeder hört jetzt alle Nachrichten immer mit und entscheidet, auf welche 
er hören muss. (ich glaube CAN-empf. können sowas per hardware über 
MAsken filtern). Wenn für ihn interessant, dann wird die nachricht 
umgesetzt. So wäre es auch denkbar, dass mehrere Empfänger auf dieselbe 
Nachricht hören.

>Warum machst du das nicht Event gesteuert?

Wenn man bspw. zyklisch sendet, weiss man, dass der Teilnehmer noch da 
ist, auch wenn kein event auftritt. Kann manchmal für einfache 
Fehlermeldungen recht interessant sein.

Willst du die Verschaltung der unterschiedlichen Funktionen zur Laufzeit 
ändern können? Wenn nicht, dann kannst du in die Knoten ja fest 
programmieren auf welche Nachrichten sie hören sollen und welche sie 
senden.

Ansonsten musst du den Sendern mitteilen welche Nachrichten sie senden 
sollen. Den Empfängern brauchst du es vielleicht nicht mitteilen, wenn 
aus der Adresse klar wird, welche Funktion du darstellen möchtest. Aber 
es muss sichergestellt sein, dass jede ID nur einmal vergeben ist.

>ass der Teilnehmer noch da...

Dafür gibt es die sogenannten Heartbeat-Meldungen, das sind Nachrichten 
mit einer hohen COB-ID (Niedrige Priorität). Diese werden von jedem 
Teilnehmer in regelmäßigen Abständen abgesendet. Nach meinem obigen 
Beispiel zB so:

Heartbeat:   10 + X  (hex)

Danke für die zahlreichen Informationen und Vorschläge.
Gestern bin ich noch bis spät in die Nacht hinein vor meinem PC gehockt.
Ich bin nicht zu einer Lösung gekommen. Seit einigen WOchen mache ich da 
mit dem XC888 Mikrocontroller herum.

Eigentlich will eigentlich nur, dass wenn eine Anforderung vom CAN 
Dongle kommt, dass dann z.B. der Teilnehmer 1 die Daten an Teilnehmer 3 
senden soll oder das Teilnehmer 2 auch seine Daten an Teilnehmer 1 
senden soll.

Gestern hab ich dann mal versucht das ganze mit REMOTE zu realisieren, 
das hat auch nicht funktioniert. Ich bin total verwirrt. Weiss nicht was 
ich da noch tun kann. Ich werde mal immer immer weitermachen.

>Seit einigen WOchen mache ich da
>mit dem XC888 Mikrocontroller herum.

Lies du auch unsere Vorschläge, oder jammerst du nur, dass es nicht 
geht??

Du brauchst erstmal ein Konzept. Das haben hier schon viele beschrieben, 
wie es gehen könnte.

Einfach wild losprogrammieren geht immer schief! (nicht unbedingt 
sofort, aber dann später!)

Auf Papier hab ich mir auch schon sämtliche Konzepte, so wie ich mir 
dies vorstelle aufnotiert.
Ich bekomme dies nicht so umgesetzt.
Wie würdet ihr genau die Anforderung (CAN-Dongle) aufbauen? ID? Daten?
Ich meine die CAN Nachricht, die ich ja benötige damit z.B. ein 
Teilnehmer 1 die Schalterstellung auf den BUS sendet und dann vom 
Teilnehmer 3 verarbeitet wird.

Auf Papier hab ich mir auch schon sämtliche Konzepte, so wie ich mir 
dies vorstelle aufnotiert.
Ich bekomme dies nicht so umgesetzt.
Wie würdet ihr genau die Anforderung (CAN-Dongle) aufbauen? ID? Daten?
Ich meine die CAN Nachricht, die ich ja benötige damit z.B. ein 
Teilnehmer 1 die Schalterstellung auf den BUS sendet und dann vom 
Teilnehmer 3 verarbeitet wird.
Würdet ihr überhaupt die REMOTE Betriebsart vom CAN verwenden?

JEder sendet dann seine Daten, wenn eine Änderung eingetreten ist. DUrch 
die Arbitrierung wird gesorgt, dass es keine Kollisionen gibt. SOmit 
wird immer die wichtigste Nachricht zuerst gesendet.

Und da jeder weiß, auf welchen NAchrichtentyp (SChalterstellung, Temp. - 
ist ja Teil der COB-ID) er hören muss. passt das.

Wo liegt das Problem?

Puhhh....ja macht es jetzt Sinn die REMOTE Betriebsart zu verwenden oder 
nicht? Der XC888 ist so konzipiert, dass man erst die Message Objekte 
konfigurieren muss. Das heisst ich lege als aller erstes fest welche 
Message Objekte mit welche ID.
Ich weiss halt nicht wie ich das ganze jetzt machen soll. Wie könnte man 
die Anforderung definieren?
Matthias Lipinsky was meinst du mit 4 + X usw?

ich schrieb:
>X: (0..255) durchnummerierte Teilnehmer, vielleicht per knotenschalter
einstellbar

Schreib erstmal auf, welche Teilnehmer du hast.
bsP:

Platine mit 8Schaltern.                              2 mal vorhanden
Platine mit 3 Temperatursensoren                     1 mal vorhandne
Platine mit 16 Lampen                                1 mal vorhanden
Platine mit 4Schaltern und zwei Tempsensoren         1 mal vorhanden
..


Dann legst du nach obigem Beispiel von mir (20.07.2007 18:06) für jeden 
Teilnehmer, den (die) COB-IDs fest, die er senden soll, sowie empfangen 
soll.

Und dann sehen wir weiter.

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.

In diesem Bild kann man sehen, wie ein MO mit DAVE konfiguriert wird.

So Matthias meine ID's sollen so aussehen:

DIP-Schalter:  1 + X

LED Block   :  2 + X

x:(0...255) durchnummerrierte Teilnehmer die per Schalter einstellbar 
sind.

Diese ID's müsste man doch nun in jedem Teilnehmer so konfigurieren 
oder?

Teilnehmer1:

DIP-Schalter: 1 + 1
LED-Block   : 2 + 1

Teilnehmer2:

DIP-Schalter: 1 + 2
LED-Block   : 2 + 2

Teilnehmer3:

DIP-Schalter: 1 + 3
LED-Block   : 2 + 3

Diese ID's stehen doch dann fest im XC888 drin, sobald der XC888 mit 
Spannung versorgt wird.

Wie kannn ich dann weiter vorgehen? Ich muss nun mit dem CAN-Dongle eine 
Anforderung senden können.

>Warum willst du immer mit Anforderungen arbeiten?

Eben. Du rufst doch auch nicht deine Mutter jeden Tag an und fragst, obs 
was Neues gibt. Sie wird sich dann schon melden.

Also mach es hier auch so. Neue Daten werden von allein gesendet. 
Fertig.

Kleiner Tip noch: Nimm höhere Zahlen als COB-IDs

>DIP-Schalter:  1 + X
>LED Block   :  2 + X
Das geht nicht. Welche COB-ID hat Teilnehmer 2 mit Lampe, und welche 
COB-ID Teilnehmer 1 mit Ledblock?? Richtig, dieselbe. Und das darf nicht 
sein. Es darf zu keinen Überschneidungen kommen.
Das war in meinem Beispiel schlecht dargestellt und nicht beachtet. 
Sorry.
MIt dem Besipiel kannst du bis 256 Teilnehmer gehen. X ist wieder die 
Teilnehmernummer.

Schalter    :  256 + X (Damit sind irgendwelche EIngänge gemeint.)
                       (nicht die TeilnehmerNr. die wird nicht 
versendet)
LED Block   :  512 + X

Temperatur  :  768 + X

weiter      : 1024 + X

So hast den Vorteil, du kannst 256 Teilnehmer haben, und hast noch die 
COB-IDs 0..255 frei. Die sind sehr hoch priorisiert und können (später) 
für "Notfall" meldungen nach dem Prinzip verwendet werden:
Notfallmeldung:   0 + X

falls du irgendwann man das Ergebnis hast, kannst du dann hier mal die 
Lösung posten? Mir ist nämlich die Aufgabe noch nicht vollkommen klar 
;-)

Hi  Matthias L., ich habs verstanden. Also alle Teilnehmer sollen 
zunächst alle Infos (DIP-Schalterstellungen) auf den CANBUS senden. Aber 
wie mache ich es jetzt so, dass der Teilnehmer 3 die Schalterstellung 
empfangen und auf die LED's ausgeben soll? Die Teilnehmer 1 und 2 sollen 
die Schalterstellungen nicht auf den LED's anzeigen.Danach möchte der 
Benutzer, dass der Teilnehmer 1 die Schalterstellung von Teilnehmer 2 
empfangen und anzeigen soll.
Der Benutzer soll entscheiden welcher Teilnehmer welche Botschaft 
anzeigen soll oder nicht.

Hä? Was?


>., ich habs verstanden. A
Glaub ich noch nicht.


Das klingt alles sehr komisch! Und durcheinander!

1)
Die DIP SChalterstellungen werden NICHT versendet!

2)
Poste mal, welcher Teilnehmer GENAU was kann und machen soll!

Also, wieviele Teilnehmer gibt es, und was machen diese?
zB. 3x je 8Schalter,
    2x je 2Lampen
    3x je eine 7Segmentanzeig, vierstellig
    1x je 3 Temp-sensoren

oder sowas.

Also, erkläre das mal zuerst

Hi Matthias L.,

es sind insgesamt drei Teilnehmer, diese sind alle gleich aufgebaut.
Jeder Teilnehmer besitzt einen DIP-Schalter mit dem man 16 Zustände 
einstellen kann und jeweils darauf sind 4 LED's die an Port 3 
angeschlossen sind. Zudem besitzt jeder Teilnehmer einen CAN Anschluss.
Die Teilnehmernummer soll zuerst mal in dem Programmcode vergeben 
werden.
(gleich nach main)

Die DIP Schalter sind für die Knotennummer?

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

Ziel der Aufgabe soll es sein, dass die Software auf allen Teilnehmern 
gleich sein soll. Die Teilnehmers sollen sich nur anhand der 
Teilnehmernummer unterscheiden.
Ich Trottel hab noch vergessen zu erwähnen, dass mit dem anderen DIP 
Schalter die LED's gesteuert werden sollen.
Der Benutzer soll dann entscheiden können, ob der Teilnehmer 2 die 
DIP-Schalterstellung von Teilnehmer 1 anzeigen soll. Oder dass der 
Teilnehmer 3 die DIP-Schalterstellung von Teilnehmer 2 anzeigen soll.

Ausgängen: DIP-Schalterstellung
Eingänge: LED Anzeige

Ich hoffe ich hab mich diesmal etwas verständlicher ausgedrückt.

Also wenn du nicht in der Lage bist, Fragen zur Ausstattung eines 
"Teilnehmers" zu beantworten, musst du dir jemand anders suchen"

>Poste mal, welcher Teilnehmer GENAU was kann und machen soll!

1) Was ist auf welchen(jedem?) Teilnehmer drauf?
    - wieviel Tasten zur Bedienung (die dann irgendwie versendet werden)
    - wieviel LEDS zur Anzeige irgendwelcher Tasten
    - wieviel Knotennummernschalter
    - wieviel Temperatursensoren
    - was weiß ich noch...

Ist das so schwer...?

Langsam verlier ich die Geduld

>>Was ist auf welchen(jedem?) Teilnehmer drauf?

Jeder Teilnehmer ist GLEICH aufgebaut:

1) 4 LED's
2) 1 DIP-Schalter (16 Zustände einstellbar)
3) CAN Knoten
4) Mikrocontroller XC888

Zunächst soll die Nummer der Teilnehmer fix im Programmcode vergeben 
werden.
Später möchte ich noch weitere DIp-Schalter dazu verwenden.

Ich hab noch zusätzlich einen CAN-Dongle zur Verfügung.

Das sind alle Angaben. Mehr gibt es nicht.

Zunächst möchte ich NUR die Schalterstellungen von jedem Teilnehmer auf 
den CANBUS senden. Je nach Wunsch vom Anwender, sollen dann die 
Schalterstellungen auf den jeweiligen Teilnehmern auf den LED's 
erscheinen.

Also gibt es PRO Teilnehmer 4Schalter für Bedienereingaben 
(DIP-SChalter)
und 4LEDs?
Wieviele (glecihe) Teilnehmer gibt es?

Die CAN-Adresse soll im Programm festgelegt werden?
Sehe ich das richtig?

Wenn ja, welche Schalterinformation soll wo hin, bzw, soll das 
veränderbar sein, durch Bediener (mittels irgendwelcher Nachrichten?)

Wenn nein, was hab ich nicht kapiert?

>Also gibt es PRO Teilnehmer 4Schalter für Bedienereingaben (DIP-SChalter)
>>und 4LEDs?

Ja so ist es!

>>Wieviele (gleiche) Teilnehmer gibt es?

Insgesamt drei Teilnehmer!

>>Die CAN-Adresse soll im Programm festgelegt werden?
>>Sehe ich das richtig?

Ja exakt!

>>Wenn ja, welche Schalterinformation soll wo hin, bzw, soll das
>>veränderbar sein, durch Bediener (mittels irgendwelcher Nachrichten?)

Ja exakt! Der Bediener soll dann entscheiden können, ob z.B. die 
Schalterstellung Teilenhmer 2 vom Teilnehmer 3 angezeigt werden soll 
usw...

>>Wenn nein, was hab ich nicht kapiert?

Du hast es schon verstanden.

Ok.

>Der Bediener soll dann entscheiden können...

Und wie soll das geschehen? mittels zusätzlicher Nachrichten von PC 
(über das Dongle?) ??


PS: Welchen Zweck hat der Aufbau?

Ich soll dies für jeden realisieren. Eigentlich soll der CAN Dongle dann 
die gewünschte Anforderung senden. Das ganz soll nur ein Test sein. 
Später soll dann statt Schalter irgend welche Sendoren usw. 
angeschlossen werden.
Die Nachrichten mit den Schalterstellungen soll zuerst auf den BUS 
gesendet werden und der Bediener entscheidet wer welche Nachricht 
verarbeiten soll.

Ich soll dies für jemanden realisieren. Eigentlich soll der CAN Dongle 
dann die gewünschte Anforderung senden. Das ganz soll nur ein Test sein. 
Später soll dann statt Schalter irgend welche Sendoren usw. 
angeschlossen werden.
Die Nachrichten mit den Schalterstellungen soll zuerst auf den BUS 
gesendet werden und der Bediener entscheidet wer welche Nachricht 
verarbeiten soll.

Ich hab mir auch schon sehr viel gedanken darüber gemacht. 
Wahrscheinlich braucht man dazu schon noch eine zusätzliche Nachricht, 
die man vom Dongle aus sendet.

Wie würdest du jetzt weiter machen?

>der Bediener entscheidet wer welche Nachricht verarbeiten soll.

Ok.
Aber wie soll das jedem Teilnehmer mitgeteilt werden? Über das 
CAN-Dongle?
Also in etwa so: EIne Meldung vom PC zum Teilnehmer zB. Nr2 sagt dem, 
das er ab jetzt Informationen von Teilnehmer 1 verarbeiten soll???
Ist das so korrekt?

>Eigentlich soll der CAN Dongle dann die gewünschte Anforderung senden.
Wozu das?

>Die Nachrichten mit den Schalterstellungen soll zuerst auf den BUS
>gesendet werden?
Wozu das? Oder ist das gedacht, um beim Einschalten die entsprechenden 
Lampen zu aktualisieren?

>Aber wie soll das jedem Teilnehmer mitgeteilt werden? Über das
>CAN-Dongle?

Ja genau!

>Also in etwa so: Eine Meldung vom PC zum Teilnehmer zB. Nr2 sagt dem,
>das er ab jetzt Informationen von Teilnehmer 1 verarbeiten soll???
>Ist das so korrekt?

Ja genau!

>>Eigentlich soll der CAN Dongle dann die gewünschte Anforderung senden.
>Wozu das?

Ich muss doch irgendwo den Teilnehmern mitteilen können ob sie jetzt 
diese Nachricht (z.B. Schalterstellung Teilnehmer 1) auf den LE's 
anzeigen sollen.

>>Die Nachrichten mit den Schalterstellungen soll zuerst auf den BUS
>>gesendet werden?
>Wozu das? Oder ist das gedacht, um beim Einschalten die entsprechenden
>Lampen zu aktualisieren?

Das verstehe ich nicht genau. Das ganze hat nix mit dem Einschalten der 
Teilnehmer zu tun.

Ich weiss nicht was ich noch sagen soll. Das ist alles!

Ok. soweit kapiert.

Sollen die Informationen permanent aktualisiert werden? Also zB zeigt 
TLN1 die Schalterstellung von TLN2 an. bsp Alle An.
Was passiert, wenn an TLN2 jetzt ein Schalter geändert wird?
Soll dann die Anzeige an TLN1 sofort aktualisiert werden?
Oder immer nur per Befehl vom PC?

Also die Frage ist, ob sich Änderungen an der Schalterstellung sofort an 
der entsprechenden Anzeige bemerkbar machen soll?

Ja, die Änderungen an der Schalterstellung soll sich schon sofort an den 
entsprechenden Anzeigen bemerkbar machen.
Wenn man es so sieht, dann soll der Bediener entscheiden welche Anzeige 
gerade aktueliert werden soll.

Ich hätte da ne Idee:

Teilenhmer 1:

ID: 256 + 1 (transmit) <-- Schalterstellung
ID: 256 + 2 (receive)
ID: 256 + 3 (receive)

Teilenhmer 2:

ID: 256 + 2 (transmit) <-- Schalterstellung
ID: 256 + 1 (receive)
ID: 256 + 3 (receive)

Teilenhmer 3:

ID: 256 + 3 (transmit) <-- Schalterstellung
ID: 256 + 1 (receive)
ID: 256 + 2 (receive)

Sobald der Bediener z.B. eine Nachricht mit der ID:0x001, Nutzdaten 
Datenbyte1:0x01, dann soll jeder Teilnehmer diese CAN Nachricht zunächst 
empfangen. Anschließend muss nich geprüft werden on das Datenbyte1 auf 
0x01 steht. Wenn ja dann soll z.B. Teilnehmer 2 die Nachricht 256 + 1 
auf den LED's anzeigen.

>ID: 256 + 1 (transmit) <-- Schalterstellung
Das ist Murks.

>Ja, die Änderungen an der Schalterstellung soll sich schon sofort an den
>entsprechenden Anzeigen bemerkbar machen.
oder
>Wenn man es so sieht, dann soll der Bediener entscheiden welche Anzeige
>gerade aktueliert werden soll.
Was denn nun???

Sofort oder per "Aktualisieren" Befehl!

Warum Murks?

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

Teilenhmer 1:

Message Objekt mit der ID: 256 + 1 (transmit) <-- Schalterstellung
Message Objekt mit der ID: 256 + 2 (receive)
Message Objekt mit der ID: 256 + 3 (receive)

Teilenhmer 2:

Message Objekt mit der ID: 256 + 2 (transmit) <-- Schalterstellung
Message Objekt mit der ID: 256 + 1 (receive)
Message Objekt mit der ID: 256 + 3 (receive)

Teilenhmer 3:

Message Objekt mit der ID: 256 + 3 (transmit) <-- Schalterstellung
Message Objekt mit der ID: 256 + 1 (receive)
Message Objekt mit der ID: 256 + 2 (receive)

Teilnehmer 1:

Message Objekt mit der ID: 256 + 1 (transmit) <-- Schalterstellung
Message Objekt mit der ID: 256 + 2 (receive)
Message Objekt mit der ID: 256 + 3 (receive)

Teilnehmer 2:

Message Objekt mit der ID: 256 + 2 (transmit) <-- Schalterstellung
Message Objekt mit der ID: 256 + 1 (receive)
Message Objekt mit der ID: 256 + 3 (receive)

Teilnehmer 3:

Message Objekt mit der ID: 256 + 3 (transmit) <-- Schalterstellung
Message Objekt mit der ID: 256 + 1 (receive)
Message Objekt mit der ID: 256 + 2 (receive)

Sorry ich meine: per "Aktualisieren" Befehl!

Weil die Schalterstellung Nutzdaten sind. Diese haben in der COB-ID 
nichts zusuchen!

Lösungsvorschlag:
Jeder Teilnehmer (TLN) bekommt eine eineindeutige Nummer. hier 1...3

Daten senden:
Wann (wann das ist folgt) ein TLNseine Schalterstellungen sendet, dann 
erfolgt das mit der
COB-ID 0x180 + X (X: TLN1..3)
Die Schalterstellung wird im ersten Datenbyte gesendet.

Aufforderung zum Senden:
Senden tut ein TLN immer dann wenn folgende NAchrincht (mittels PC 
gesendet) empfangen wurde:
COB-ID 0x080 (kein plus irgendwas)
Als erstes Datenbyte wird jetzt die TLN Nummer versendet, welcher Daten 
senden soll! Ein Null könnten alle bedeuten.

Teilnehmer konfigurieren:
Über den PC wird eine Meldung versendet, die einem TLN mitteilt, auf 
welche Daten er hören soll:
COB-ID 0x500 + X (X: TLN1..3)
Das erste Datenbyte legt fest, auf welchen Teilnehmer er hören soll. 
Dieses muss er speichern und ich nenne es mal KD.


SOmit muss jeder Teilnehmer
senden mit:
COB-ID 0x180 + X (X: TLN1..3)
und empfangen mit:
COB-ID 0x080      (Aufforderung zum Daten senden)
COB-ID 0x500 + X  (Konfigurationsdaten)
COB-ID 0x180 + KD (Daten eines anderen TLN)

So würde ichs lösen...

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

Zuerst muss ich alle Message Objekte im XC888 erstellen und 
konfigurieren.
Damit ich auch mit jedem Teilnehmer auch die anderen gesendeten 
Schalterstellungen empfangen kann, brauch ich statt 3 Messaeg Objekte 
noch zwei weitere zum Empfangen.
Das heisst ich bräuchte insgesamt für jeden Teilnehmer 5 Message 
Objekte.

Beispiel für den Teilenhmer 1:

Message Objekt mit der ID: 0x180 + 1 zum senden
Message Objekt mit der ID: 0x180 + 2 und ID: 0x180 + 3 zum empfangen
Message Objekt mit der ID: 0x080     zum empfangen
Message Objekt mit der ID: 0x500 + 1 zum empfangen

Beispiel für den Teilenhmer 2:

Message Objekt mit der ID: 0x180 + 2 zum senden
Message Objekt mit der ID: 0x180 + 1 und ID: 0x180 + 3 zum empfangen
Message Objekt mit der ID: 0x080     zum empfangen
Message Objekt mit der ID: 0x500 + 2 zum empfangen

Beispiel für den Teilenhmer 3:

Message Objekt mit der ID: 0x180 + 3 zum senden
Message Objekt mit der ID: 0x180 + 1 und ID: 0x180 + 2 zum empfangen
Message Objekt mit der ID: 0x080     zum empfangen
Message Objekt mit der ID: 0x500 + 3 zum empfangen

>jedem Teilnehmer auch die anderen gesendeten
>Schalterstellungen empfangen kann,

nicht DIE anderen, nur EIN anderes!

>essage Objekt mit der ID: 0x180 + 1 und ID: 0x180 + 2 zum empfangen
                                     ^^^^

ODER !!!!!!!!

Guten Morgen Matthias,

was meinst du damit?

>jedem Teilnehmer auch die anderen gesendeten
>Schalterstellungen empfangen kann,

>>nicht DIE anderen, nur EIN anderes!

>essage Objekt mit der ID: 0x180 + 1 und ID: 0x180 + 2 zum empfangen
                                     ^^^^

>>ODER !!!!!!!!

Damit z.B. der Teilnehmer 1 bei entsprechender Anforderung die 
Schalterstellungen von Teilnehmer 2 oder Teilnehmer 3 empfangen werden 
kann, muss der XC888 noch zwei weitere Empfangsmessage-Objekte besitzen.
Ich möchte nicht das Message Objekt 0 verwenden. Damit kann ich alle 
Nachrichten abfragen. Besser ist es wenn man die Message Objekte gleich 
einstellt und konfiguriert.

Also ich habe keine Ahnung von diesem XC888 und deren EInstellungen.
Ich meine Damit, dass es notwendig ist eine dieser beiden IDs zu 
empfangen.

Somit muss zB Teilnehmer folgende IDs empfangen können:
0x080               Anforderung
0x501               Konfigdaten vom PC
0x182 ODER 0x183    Daten von TLN2 ODER TLN3  (abh. von Konfigdaten)
senden muss seine Daten immer mit 0x181.


selbes bsp für TLN2:
empfangen:
0x080               Anforderung
0x502               Konfigdaten vom PC
0x181 ODER 0x183    Daten von TLN1 ODER TLN3  (abh. von Konfigdaten)
senden muss seine Daten immer mit 0x182.


selbes bsp für TLN3:
empfangen:
0x080               Anforderung
0x503               Konfigdaten vom PC
0x181 ODER 0x182    Daten von TLN1 ODER TLN2  (abh. von Konfigdaten)
senden muss seine Daten immer mit 0x183.

das ODER bedeutet, dass nur eine von beiden empfangen werden braucht. 
Wie du das mit dem XC888 umsetzen musst, weiß ich nicht.
So meine ich das. alles klar?

Achso, so hab ichs auch gemeint. Vielen vielen Dank für deine Hilfe!
So wie es jetzt aussieht, werde ich dies auch so umsetzen.
Wird dein vorgeschlagenes Prinzip auch wo anders bei CAN eingesetzt?
Bei weiteren Fragen werde ich mein Problem in diesem Thread reinsetzen.

Naja, CANopen funktioniert ähnlich:
Dort senden (aufgeforderte) Teilnehmer auf 0x180+X. Eine 
Synchronisationsmessage läuft auf 0x080 und geht an alle. Daten zum 
Konfigurieren der Teilnehmer werden auf, oh ich sehs grad, auf 0x600+X 
und NICHT auf 0x580+X gesendet. das kannst vielleicht noch einbringen.

Als erstes müssen die Message Objekte für jeden XC888 Mikrocontroller 
angelegt und konfiguriert werden.

Somit muss zB Teilnehmer folgende IDs empfangen können:
0x080               Anforderung
0x501               Konfigdaten vom PC
0x182 ODER 0x183    Daten von TLN2 ODER TLN3  (abh. von Konfigdaten)
senden muss seine Daten immer mit 0x181.

Insgesamt benötigt der Teilnehmer 1 Message Objekt das sendet und 4 
Message Objekte die empfangen können.

>1 Message Objekt das sendet
Ok

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

>> Wieso 4?

1 Message Objekt damit man die Konfigurationsdaten empfangen kann.
1 Message Objekt damti die Anforderungen empfangen werden können.
2 Message Objekte damit die Schalterstellungen der anderen Teilnehmer 
empfangen werden können.

Dies ergibt dann eine Anzahl von 4 Message Objekten.

Dazu kommt noch ein Sende Message Objekt.

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

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

Ich muss doch z.B. den Teilnehmer 1 so konfigurieren, dass wenn eine 
Anforderung kommt, dass dann die Schalterstellung vom Teilnehmer 1 oder 
Teilnehmer 3 empfangen werden können. Dies bedeutet ich muss hier noch 
zwei weitere Message Objekte anlegen die zum Empfangen verwendet werden.

Beispiel:
Der Dongle sendet diese Nachricht mit dieser ID:
COB-ID 0x500 + 1  (Konfigurationsdaten = 0x02)

Der Teilnehmer empfangt diese Nachricht und sieht, dass das erste 
Datenbyte auf 0x02 steht. Somit weiss dieser, dass er die Daten vom 
Message Objekt mit der ID 0x180 + 2 benutzen soll. Deshalb muss noch bei 
Teilnehmer 1 eine Message Objekt mit der ID Nr: 0x180 + 2 zum EMpfang 
angelegt werden.

>Deshalb muss noch bei Teilnehmer 1 eine Message Objekt mit der ID Nr: 0x180 >+ 2 
zum EMpfang angelegt werden.

Richtig. Und somit sind es doch aber nur drei:
0x080  Anforderung
0x501  Konfigdaten
0x182  Prozessdaten (wurde mit PC so konfiguriert)

Das sind bei mir nur drei. Weitere muss dieser nicht empfangen!

Also das verstehe ich nicht!

Ja weißt du. ich muss es nicht verstehen. Wenn du nur sagst dass dus 
nicht verstehst, aber nichts fragst...

Du willst es bauen, nicht ich.
cih würde es so umsetzen und es würde gehen

z.B. Teilnehmer 1:

Aufforderung zum Daten senden:
COB-ID 0x080; Datenbyte1=0x01 --> Daten werden gesendet mit COB-ID 0x180 
+ 1
(im DatenByte1 steht dann die Schalterstellung vom Teilnehmer 1 drin)
Jetzt kommt eine Nachricht mit COB-ID 0x500 + 1 und Datenbyte1 0x02.
Dies bedeutet der Teilnehmer möchte die Schalterstellung vom COB-ID 
0x180 + 2
empfangen. Danach wird das Datenbyte 1 ausgelesen und auf den LED's 
ausgegeben.

Das ist doch richtig so oder hab ich noch was vergessen?

... hab was vergsssen...

Der Teilnehmer 1 muss noch ein Message Objekt besitzen mit dem COB-ID 
0x180 + 2, das allerdings als Empfang dienen soll und nicht zum senden 
verwendet wird.

Das Beispiel kann man auch mit Teilnehmer 2 und 3 machen.

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

>Teilnehmer 1:
>Aufforderung zum Daten senden:
>COB-ID 0x080; Datenbyte1=0x01 --> Daten werden gesendet mit COB-ID 0x180
>+ 1
>im DatenByte1 steht dann die Schalterstellung vom Teilnehmer 1 drin)

Ok. TLN 1 hat seine Daten VERSENDET (wer auch immer hier zuhört!)


>Jetzt kommt eine Nachricht mit COB-ID 0x500 + 1 und Datenbyte1 0x02.
>Dies bedeutet der Teilnehmer möchte die Schalterstellung vom COB-ID
>0x180 + 2
>empfangen. Danach wird das Datenbyte 1 ausgelesen und auf den LED's
>ausgegeben.

NEIN!
Das bedeutet NUR, dass er ab jetzt auf die COB 0x180 + 2 hören soll!!
Mehr nicht!
Es ist ja noch kein (neues) Datenbyte angekommen!

Die Anzeige wird erst mit einem neuen Wert befüllt, wenn der TLN1 eine 
Meldung von TLN2 erhalten hat. DIESER TLN2 sendet erst, wenn er (TLN2) 
folgendes empfangen hat:
COB 0x080 & Datenbyte 0x02 !!!

Ja das meinte ich auch.
Somit soll der TLN 2 dann auf COB 0x180 + 2 hören. Genau wie würdest du 
dies relaisieren?

Entweder ein Message Objekt erzeugen mit dem COB 0x180 + 2 oder ?????

... oder mit dem Acceptance Filter arbeiten?

Arbitration Register 0x182 = 110000010

Acceptance Register  0x182 = 110000010

|
|
--> Nachricht kann empfangenn werden

Die Lösung (oder besser: ein Weg) hab ich dir gezeigt.
Die Umsetzung liegt an dir. Da ich diese ganzen Register des XC888 nicht 
kenne

Wahrscheinlich müsste ich es dann so machen, dass ich mit einem Message 
Objekt (Beispiel TLN1) permanent prüfe ob Nachricht mit ID 0x182 oder ID 
0x183 anliegt. Wenn ja, Datenbyte1 auf LED ausgeben.

Matthias was würdest du mir empfehlen?
Mit dem XC888 kann man pro Knoten 16 Message Objekte anlegen und 
konfigurieren (Arbitration Register, Acceptance Register, 
Richtung:receive/transmit).
Das Message Objekt 0 ist was besonderes.

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

Also ich habs jetzt mal mit dem Acceptance Filter gelöst.
Ich habe bisher noch keinen Interrupt verwendet, alles läuft noch in der 
while(1) Schleife von main.

Hat jemand Erfahrung mit dem umsetzen der Software? Ich glaube, 
Interrupts wären dafür echt gut oder?

>Erfahrung mit dem umsetzen der Software? Ich glaube,
>Interrupts wären dafür echt gut oder?

Meist ja.
Weil dann der Prozessor nur dann CAN-Meldungen zu sehen bekommt, wenn 
eine relevante da ist. Und du musst nicht dauernd irgendein Bit pollen.

Wobei das bei deiner Anwendung wohl egal ist.

Ich hab das ganze wie gesagt mal ohne Interrupt gelöst.
Folgendes ist mir aufgefallen:

Anforderung 0x080 & Datenbyte1=0x01 --> TLN1 sendet 0x181 & Datenbyte1
Jetzt sende ich vom CAN Dongle folgende Nachricht: 0x502 & Datenbyte1 = 
0x01
Dies bedeutet ja das der TLN2 die Nachricht von TLN mit der ID 0x181 & 
Datenbyte1 empfängt. Dabei kommt es vor, dass es ein paar Sekunden 
dauert, bis ich die Daten auf den LED's (TLN2) zu sehen sind. Warum 
eigentlich?

Ich bin noch am überlegen wie dies mit den Konfigurationsdaten lösen 
könnte.
z.B. 0x502 & Datenbyte1 = 0x01
Jeder Teilnehmer soll ja die gleiche Software bekommen.

>Jetzt sende ich vom CAN Dongle folgende Nachricht: 0x502 & Datenbyte1 =
>0x01
>Dies bedeutet ja das der TLN2 die Nachricht von TLN mit der ID 0x181 &
>Datenbyte1 empfängt.

Korrekt.
Die Nachricht 0x502.. bedeutet ja nur, dass der TLN2 auf TLN1 hören 
soll, MEHR NICHT.


>Dabei kommt es vor, dass es ein paar Sekunden
>dauert, bis ich die Daten auf den LED's (TLN2) zu sehen sind. Warum
>eigentlich?

Weil eine Aktualisierung erst mit der Meldung 0x080 (Anforderung) 
erfolgt.
Das heißt, es ist ratsam, unmittelbar nach einer 0x500+X Nachricht, eine 
0x080 Nachricht zu senden.

Also so erkläre ich das mit meinem Konzept. Falls du da etwas anderes 
programmiert hast, dann kann ichs nicht erklären

Achso stimmt ja, ich habe zuerst eine Nachricht mit der ID 0x080 vom CAN 
Dongle aus gesendet. Im Anschluss sendete ich dann die Nachricht mit der 
ID 0x502.

Weisst du vielleicht wie ich dies lösen könnte:

Alle TLN's besitzen eine Variable mit dem Namen DeviceAddress.
Wenn ich zum Beispiel TLN1 starte, dann bekommt die Variable 
DeviceAddress den Inhalt 0x01 zugeweisen.
Jetzt möchte ich es so haben, dass bei Empfang (TLN1) von 0x501 & 
Datenbyte 1 = 0x01 nicht die ID 0x181 empfangen werden kann, sondern nur 
0x182 oder 0x183.
Dies soll auch bei TLN2 und TLN3 genauso sein.

Ich weiß nicht was du meinst. Was macht die variable "DeviceAddress" ?
Ist das die eigene Knotennummer? Also das X in 0x500+X, 0x180+X
Oder was ist das da??

Und was du jetzt genau machen willst, hab ich nicht verstadnen.
Also bitte nochmal anders formulieren

Ja das X entspricht der Variable DeviceAddress.
Hmmm...mir fehlt da ein Mechanismus mit dem COB-ID: 0x500 + X und dem 
Datenbyte1 (0x01 ; 0x02 ; 0x03). Ich möchte es so haben, dass ich nicht 
immer die Software abändern muss. Ok die Zuweisung der Knotennummer muss 
ich jetzt momentan noch manuell machen.

>Ich möchte es so haben, dass ich nicht immer die Software abändern muss. Ok >die 
Zuweisung der Knotennummer muss ich jetzt momentan noch manuell machen.

Also du suchst einen Mechanismus, um diese Knotennummer (X) extern zu 
vergeben??? zB beim Einschalten des Systems??
Hab ich das richtig verstanden???

Ja genau!

Also da fällt mir pauschal nur ein was ein:
Per software bekommt jeder teilnehmer zB X=0.

SO und jetzt muss jeder Teilnehmer einzeln!!!! per PC mit einer 
speziellen CAN-Nachricht auf seine Adresse eingestellt werden. Somit 
wird dem X ein neuer Wert zugewiesen. Dieser muss dann allerdings nicht 
flüchtig (EEPROM) abgespeichert werden. und beim Neustart (Spannung 
zuschalten) wird dieser Wert genommen.
Halte ich aber für keine gute Idee, da du dir "merken" musst welche 
adresse jeder TLN hat (per Aufkleber zB)

Ich würde eine Lösung per DIP/Kodierschalter verwenden. Das ist einfach 
und von aussen (Benutzer) sofort erkennbar.

Wo steht das drin, dass das COB-ID:0x500+X für die Konfiguration 
zuständig ist? Gibt es irgendwo eine Liste zu den COB-ID's?

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

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

ja, in dem link, den ich damals gepostet habe.
Irgendwo auf der Seite von LENZE. gucke mal weiter oben.
Aber ich glaub das war unter hausbus. weiß ne mehr genau.
War da aber noch nicht angemeldet, nick war Matthias (gast)

bin jetzt mal ne weile weg..

Im Netz habe ich was gefunden:

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

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

Ich verwende ja folgende COB-ID's:

0x180 + X
0x500 + X
0x080


Welche von denen sind SDO oder PDO?

Sagen ganz kann ich diese COB-ID nirgend bei CanOpen zuordnen.

0x080 bedeutet in CanOpen Synchronisation.
0x580 + X bedeutet in CanOpen Transmit SDO.
0x180 + X bedeutet in CanOpen Transmit PDO.

Stimmt dies eigentlich?

>0x080 bedeutet in CanOpen Synchronisation.
>0x580 + X bedeutet in CanOpen Transmit SDO.
>0x180 + X bedeutet in CanOpen Transmit PDO.


Ja, die SDO,PDO, Sync Messagezuordnung, die du gefunden hast, sind alle 
richtig. Deshalb hab ich ja diese Zahlen so gewählt ;-)

Mit Synchronisation soll der jeweilige Teilnehmer seine Daten auf den 
Bus geben?

In der Liste steht noch was von Receive SDO und PDO. Was hat es damit 
auf sich?

In den Canopen Unterlagen steht was von Receive SDO und Receive PDO.
Das bedeutet doch, dass die SDO's und PDO's der Teilnehmer auf Receive 
eingestellt werden müssen oder?

0x080 Receive
0x580 + X bedeutet in CanOpen Receive SDO.
0x180 + X bedeutet in CanOpen Receive PDO.

Wenn ich ein PDO (z.B. 0x181) von einem Teilnehmer aus, auf den Bus 
sende, dann kann ich doch auch das Receive PDO verwenden. Dies bedeutet 
das Receive PDO empfängt dann der Master (Dongle)?

In den Canopen Unterlagen steht was von Receive SDO und Receive PDO.
Das bedeutet doch, dass die SDO's und PDO's der Teilnehmer auf Receive
eingestellt werden müssen oder?

0x080 Receive
0x580 + X bedeutet in CanOpen Receive SDO.
0x180 + X bedeutet in CanOpen Receive PDO.

Hi Matthias,

da nun soweit alles bei mir läuft, möchte ich mein Protokoll ausbauen.
Es gibt da ja noch das NMT (netzwerkmanagement, sowie Receive SDO bzw. 
Receive PDO). Was hat es damit aufsich?

Bin ja wieder da. War doch WE!

>>Mit Synchronisation soll der jeweilige Teilnehmer seine Daten auf den
>>Bus geben?

Naja, bietet sich doch an.


>>In der Liste steht noch was von Receive SDO und PDO. Was hat es damit
>>auf sich?

-----------                    ---------------
Master    |      TxPDO ===>    |  Slave
          |      TxSDO ===>    |
          |                    |
          |      RxSDO <===    |
          |      RxPDO <===    |
-----------                    -----------------

Das ist immer vom Master aus gesehen (hier PC-dongle):
Tx sendet der Master, Rx empfängt der Master
Tx empfängt der Slave, Rx sendet der Slave.

SDO: Ist ein ServiceDatenObjekt. Damit werden Informationen übertragen, 
die zur Konfigurierung/Parametrierung der Slaves dient
PDO: Sind Prozess(Nutz)daten. Aufgrund der relativ kleinen COB-ID 
(kleiner als SDO) werden diese Daten höher-prior übertragen.

NMT: Ist ein Netzwerkmanagement-dienst. Damit werden alle Slave "aktiv" 
geschaltet. Bedeutet: Nach dem Start (PowerUp) sind alle Slave im 
sogenannten "pre-operational" mode. sie akzeptieren hier KEINE PDOs! ein 
umschalten in "operational" erfolgt mit einem NMT.
irgendwo in dem Lenze Dok. sollte das ganze als State-Maschine 
beschrieben sein.

Hi Matthias,

so ganz verstehe ich dies immer noch nicht.
Der Teilnehmer 1 sendet z.B. seine Daten mit der COB-ID:0x181.
Entspricht dies jetzt einem PDO(TX) oder PDO(RX)?

Genauso mit dem COB-ID:0x581. Damit kann ich z.B. sagen, das der 
Teilnehmer 1 die Daten vom Teilnehmer 2 lesen soll. Entspricht dies 
jetzt einem SDO (TX) oder SDO(RX)?

Wenn ich jetzt irgendwelche anderen Paramter von einem bestimmten 
Teilnehmer lesen möchte, müsste ich dies mit einem SDO realisieren.
Z.B. ich sende vom Master eine Nachricht mit der COB-ID: 0x601. Damit 
könnte ich doch einen Paramter vom Teilnehmer 1 auslesen oder?
In den PDF Dateien steht einmal was von Telegramm zum Antrieb 
(COB-ID:0x605) und dann Antwort Telegramm (COB-ID:585) vom Antrieb.

Hab mich heute Morgen gleich wieder an den Rechner gesetzt.
Mich verwirrt das immer noch bzw. ich weiss noch immer nicht wie ich 
z.B. veranlassen kann, das ich eine Paramter von einem Teilnehmer 
auslesen kann.

-----------                             ---------------
Master    |      TxPDO 0x200*+X ===>    |  Slave
          |      TxSDO 0x600 +X ===>    |
          |                             |
          |      RxSDO 0x580 +X <===    |
          |      RxPDO 0x180*+X <===    |
-----------                             -----------------

>>er Teilnehmer 1 sendet z.B. seine Daten mit der COB-ID:0x181.
Entspricht dies jetzt einem PDO(TX) oder PDO(RX)?

Das ist dann ein RxPDO. SOlche Betrachtungen Rx/Tx werden immer vom 
Master aus gemacht!

>>Z.B. ich sende vom Master eine Nachricht mit der COB-ID: 0x601. Damit
>>könnte ich doch einen Paramter vom Teilnehmer 1 auslesen oder?

Ja.


>>In den PDF Dateien steht einmal was von Telegramm zum Antrieb
>>(COB-ID:0x605) und dann Antwort Telegramm (COB-ID:585) vom Antrieb.

die 0x601 ist TxSDO: 0x600+X;  X=1 (Teilnehmer1)
Antwort wäre ein RxSDO 0x0581:  0x580+X; X=1

Im Beispiel ist das iednetisch mit Teilnehmer (Knotennummernschalter) = 
5 dargestellt.


*:
Es können mehrere PDO gesendet/empfangen werden. Aber das soll nur der 
Vollständigkeit dienen.

Achso. Ich verwende für die Anforderung das COB-ID:0x580 + X.
Dieses sende ich ja vom Dongle an den jeweiligen Teilnehmer. Damit kann 
ich dann genau sagen welcher Teilnehmer welche Nachricht (COB-ID:0x180 + 
X) empfangen und auswerten soll. Wie kommt dann das COB-ID:0x600 + X zum 
Einsatz? Müsste ich laut CanOpen dann wenn ich ein COB-ID:0x580+X vom 
Master sende auch eine Antwort vom einem Teilnehmer (COB-ID:0x600 + X) 
bekommen?

Ich sende nun eine Nachricht mit dem COB-ID:COB-ID:0x581 für den 
Teilnehmer1. Dieser empfangt diese Nachricht und sieht, dass z.B. das 3. 
Datenbyte den Wert 0x01 besitzt. Daraufhin könnte dieser dann eine 
Antwort Nachricht mit der COB-ID:0x601 auf den Bus senden oder?
Wäre dieses Vorgehen so in etwa wie bei CAnOpen?

>>Ich sende nun eine Nachricht mit dem COB-ID:COB-ID:0x581 für
>>Nachricht mit der COB-ID:0x601

Ja das ist so richtig.

Nur ich sehe gerade, ich habe die 0x580 und die 0x600 vertauscht:
Der Master sendet die 0x600 und der Slave sendet die 0x580 als Antwort.

Ah...jetzt macht es auch Sinn. Es ist aber nicht zwingend notwendig dass 
der Teilnehmer dann wieder Antwortet oder?
Ich kann ja nur eine Anforderung vom Master an den Teilnehmer senden.

Gestern Nacht hab ich mir auch noch überlegt, das ganze jetzt per 
Interrupt zu lösen.
Was wäre da sinnvoll? Sollte man nur einen einzigen Interrupt für das 
Empfangen verwenden?

>>Nur ich sehe gerade, ich habe die 0x580 und die 0x600 vertauscht:
>>Der Master sendet die 0x600 und der Slave sendet die 0x580 als Antwort.

Die IDs hier sind natürlich nur auf SDOs bezogen.


>Es ist aber nicht zwingend notwendig dass
>der Teilnehmer dann wieder Antwortet oder?

Das sollte korrekt sein.


>das ganze jetzt per Interrupt zu lösen.

Das macht Sinn.

>en einzigen Interrupt für

Kommt drauf an, wann der/die Interrupts ausgelöst werden.


Naja, da hast ja das Projekt nun doch noch zum Laufen bekommen ;-)

Ich kann z.B. für das COB-ID:0x601, COB-ID:0x181 und COB-ID:0x080 
jeweils einen Interrupt einrichten. Macht Sinn mehrere Interrupt zu 
verwenden?
Ich könnte ja auch alles in einem Interrupt tun.
Zum Beispiel das Anzeigen der Daten könnte ich ja in der while(1) 
Schleife im Hauptprogramm tun.

Was ist eigentlich die übliche Vorgehensweise?

Ich kann auf dem XC888 mehrere Interrupts für den Empfang von CAN 
Nachrichten aktivieren. Wahrscheinlich ist es sinnvoll nicht alles mit 
einem Interrupt zu realisieren, oder?

Ich weiß es nicht. ich kenne diesen XC888 nicht. Aber ich glaube, es 
reicht ein Interrupt (so oft kommt das ja nicht). Dieser Entscheidet 
dann, abhängig von der Nachricht, was zutun ist..

Die Synchronisationsnachricht 0x080 (vom Dongle), SDO Nachricht 0x600 + 
X (vom Dongle) sowie PDO Nachricht 0x180 + X (Informationen von einem 
Teilnehmer) sollte man schon in einer ISR empfangen. Die Auswertung 
sollte diese dann auch noch in der ISR gemacht werden oder sollte man 
diesen Teil in dem Hauptprogramm while(1) Schleife tun?

>sollte man schon in einer ISR empfangen

Das bestätigte ich ja bereits-


>Die Auswertung
>sollte diese dann auch noch in der ISR gemacht werden oder sollte man
>diesen Teil in dem Hauptprogramm while(1) Schleife tun?

Da sich die Auswertung auf das Kopieren eines Datenbytes, (oder so 
ähnlich) beläuft, also nicht viel passiert. Kannst du das ruhig in der 
ISR tun.


(pseudo code)
X: eigene Knotennummer
Y: Teilnehmernummer, auf die "gehört" wird

ISR (CAN Meldung empfangen)
{
 if (Meldungstyp = 0x080)
  {
    SendeDaten (aktuelle Tasten);  // Sende Tastenstellung
  }
 if (Meldungstyp = 0x600+X)
  {
    Setze_NeuenTLN ();            // hier wird Y ein neuer Wert 
zugewiesen
  }
 if (Meldungstyp = 0x180+Y)
  {
    AnzeigeLED();                 // Anzeige der TLN-Daten
  }
}

Danke nochmals Matthias.
Also das mit dem Synchronisationsnachricht 0x080. Ist dies echt CanOpen 
konform? Macht man dies wirklich so?
Wenn ich jetzt irgendwelche Daten von einem Teilnehmer auslesen möchte 
dann kann dies ja wie gesagt mit dem PDO tun.
Ich sende z.B. vom Master ein Nachricht mit dem COB-ID: 0x601 
Datenbyte3=0x01.
Der Teilnehmer 1 empfängt diese Nachricht und sieht dass das Datenbyte3 
auf 0x01 steht. Somit kann dieser seine Info (z.B. Schalterstellung) mit 
einer weiteren Nachricht mit der COB-ID:0x581 Datenbyte3 = Info 
Schalterstellung an den Master senden.

Eine Synchronisationsnachricht dient meineswissens bei CANopen dazu, die 
(vorher) gesendeten Prozessdaten (PDOs) zu aktivieren, also diese Daten 
zu nutzen. zB auf Ausgänge zu schalten. Somit kann garantiert werden, 
dass alle Ausgänge zeitgleich aktualisiert werden. (Das sit in AT sehr 
wichtig)

>Wenn ich jetzt irgendwelche Daten von einem Teilnehmer auslesen möchte
>dann kann dies ja wie gesagt mit dem PDO tun.
>Ich sende z.B. vom Master ein Nachricht mit dem COB-ID: 0x601
>Datenbyte3=0x01.
>Der Teilnehmer 1 empfängt diese Nachricht und sieht dass das Datenbyte3
>auf 0x01 steht. Somit kann dieser seine Info (z.B. Schalterstellung) mit
>einer weiteren Nachricht mit der COB-ID:0x581 Datenbyte3 = Info
>Schalterstellung an den Master senden.

Die SDOs (0x580+X bzw 0x600+X) sind NICHT für Prozessdaten da! Also 
daruber sollten keine Schalterstellungen versendet werden. Nur 
Konfigurationsdaten.

Wenn du Prozessdaten anfordern willst, dann solltest du KEIN Tx/RxSDO 
sondern das TxRxPDO nehmen. Bin aber nicht ganz sicher ob das CANopen 
konform ist. muss ich mal nachfragen.
Aber warum willst du das denn anfordern?

Hi Matthias, du hast gemeint, dass 0x581 und 0x601 vertauscht sind.
Also laut Doku von CanOpen sieht man, dass COB-ID:0x581 der Master 
(Dongle) sendet. COB-ID:0x601 empfängt der Master (Dongle).
Aber warum steht dann hier COB-ID:0x181 (Tx) ? Das sendet doch der 
Teilnehmer 1. Das verwirrt mich sehr.

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

Hi lippy,

du hast folgendes geschrieben:
>Die SDOs (0x580+X bzw 0x600+X) sind NICHT für Prozessdaten da! Also
>daruber sollten keine Schalterstellungen versendet werden. Nur
>Konfigurationsdaten.

Ok stimmt eigentlich. Ich kann aber z.B. die Teilnehmernummer dem SDO 
übergeben und dann auf den Bus senden.

>Wenn du Prozessdaten anfordern willst, dann solltest du KEIN Tx/RxSDO
>sondern das TxRxPDO nehmen. Bin aber nicht ganz sicher ob das CANopen
>konform ist. muss ich mal nachfragen.
>Aber warum willst du das denn anfordern?

Achso sende zuerst eine Anforderung mit 0x501. Diese Anforderung ist für 
den Teilnehmer 1 bestimmt. Dieser soll dann mit einem PDO die 
Schalterstellung oder auch einen Messwert auf den Bus senden. Dieses PDO 
kann dann vom Master ausgewertet werden. Genau da hab ich noch Probleme 
mit der Umsetzung.

Also mich verwirrt das mit den PDO's und SDO's immer noch.

SDO senden: sichtweise Master (Dongle)
SDO empfangen: sichtweise Master (Dongle)

PDO(tx): sichtweise Teilnehmer (Slave)
PDO(rx): sichtweise Teilnehmer (Slave)

>Also mich verwirrt das mit den PDO's und SDO's immer noch.

OK. Also:

Prozessdaten werden immer mit PDOs übertragen. Konfigurationen, 
Parameter (unwichtig) immer mit SDOs.

Sende der Master ein PDO, dann ist es ein TxPDO mit 0x200+X.
Darauf hat der Slave mit 0x180+X zu antworten. Das ist dann (beim 
Master) ein RxPDO.

Sendet der Master ein SDO, dann ist das ein TxSDO mit 0x600+X. EIne 
Antwort wird vom Slave mit 0x580+X beantwortet. Dieses heißt beim Master 
RxSDO.

Grund:
CAN-Bus wurde entwickelt, um im Auto viele System zu vernetzen. Diese 
Systeme haben untereinander Daten ausgetauscht. Die Daten wurden nicht 
nach Absender/Empfänger, sondern nach Inhalt der Nachricht adressiert.
CANopen nutzt nur die Physik und erzwingt durch das CANopen Protokoll 
einen streng-deterministischen Ablauf. Das bedeutet, Antwortzeiten des 
Systems werden berechenbar, da immer nur der Master sendet bzw das 
Senden initiieren kann.

So. Bin jetzt im Wochenende

Hi Matthias,

letzte oder auch vorletzte Woche hast du mir mitgeteilt, dass ich 
folgende COB-ID benutzen soll:

Sync Message COB-ID: 0x080
SDO Message COB-ID:0x580+X und COB-ID:0x600+X
PDO Message COB-ID:0x180+X und COB-ID:0x200+X

X soll die Nummer der Teilnehmer sein.

Wenn der TLN2 die PDO Message 0x181 von dem TLN1 lesen möchte,
dann muss der Master (Dongle) eine SDO Message mit der COB-ID:0x582 und 
Datenbyte1:0x01 senden.
Anschließend muss mit einer Sync. Message COB-ID:0x080 und 
Datenbyte1:0x01
der TLN1 aufgefordert werden die PDO Message mit dem COB-ID:0x181 und 
Datenbyte:Schalterstellung auf den Bus zu senden.
Wie kann ich das PDO Message COB-ID:0x200+X und SD0 Message 
COB-ID:0x600+X verwenden/nutzen?
Ich möchte z.B. irgendwelche Konfigurationsdaten (Teilnehmernummer) von 
einem TLN auslesen können und der Master soll die Info dann verarbeiten.
Tue ich dies damit, indem z.B. eine SDO Message COB-ID:0x582 und 
Datenbyte2 auf den Bus vom Master aus gesendet werden soll. Der TLN2 
empfangt diese Message und sieht dass das Datenbyte2 auf 0x02 steht. 
Daraufhin sendet dieser die Konfigurationsdaten (Teilnehmernummer) mit 
der SDO Message COB:0x602 Datenbyte2:Teilnehmernummer auf den Bus. Somit 
kann der Master die Message weiter verarbeiten.

Schönes Wochenende Matthias.

Durch das Sync Message COB-ID:0x080 wird veranlasst das die 
Kommunikation synchron abläuft. Um aber Konfigurationsdaten von einem 
TLN anzufordern, benötigt man nicht unbedingt eine SYNC Message. Dies 
kann man auch so lösen das der Master ein SDO Message sendet und darauf 
hin der TLN mit einem SDO Message wieder antwortet. Stimmt dies so?

-----------                             ---------------
Master    |      TxPDO 0x200*+X ===>    |  Slave
          |      TxSDO 0x600 +X ===>    |
          |                             |
          |      RxSDO 0x580 +X <===    |
          |      RxPDO 0x180*+X <===    |
-----------                             -----------------

Mir ist noch immer nicht so ganz klar, wie oder für was ich die 
COB-ID's: 0x200+X und 0x580+X verwenden könnte.

Guten Morgen Matthias,

letzte oder auch vorletzte Woche hast du mir mitgeteilt, dass ich
folgende COB-ID benutzen soll:

Sync Message COB-ID: 0x080
SDO Message COB-ID:0x580+X und COB-ID:0x600+X
PDO Message COB-ID:0x180+X und COB-ID:0x200+X

X soll die Nummer der Teilnehmer sein.

Wenn der TLN2 die PDO Message 0x181 von dem TLN1 lesen möchte,
dann muss der Master (Dongle) eine SDO Message mit der COB-ID:0x582 und
Datenbyte1:0x01 senden.
Anschließend muss mit einer Sync. Message COB-ID:0x080 und
Datenbyte1:0x01 der TLN1 aufgefordert werden die PDO Message mit dem 
COB-ID:0x181 und Datenbyte:Schalterstellung auf den Bus zu senden.

Wie könnte ich das PDO Message COB-ID:0x200+X und SD0 Message
COB-ID:0x600+X verwenden/nutzen?
Ich möchte z.B. irgendwelche Konfigurationsdaten (Teilnehmernummer) von
einem TLN auslesen können und der Master soll die Info dann verarbeiten.
Tue ich dies damit, indem z.B. eine SDO Message COB-ID:0x582 und
Datenbyte2 auf den Bus vom Master aus gesendet werden soll. Der TLN2
empfangt diese Message und sieht dass das Datenbyte2 auf 0x02 steht.
Daraufhin sendet dieser die Konfigurationsdaten (Teilnehmernummer) mit
der SDO Message COB:0x602 Datenbyte2:Teilnehmernummer auf den Bus. Somit
kann der Master die Message weiter verarbeiten.

Hi Matthias, bist du gerade im Urlaub?

>-----------                             ---------------
>Master    |      TxPDO 0x200*+X ===>    |  Slave
>          |      TxSDO 0x600 +X ===>    |
>          |                             |
>          |      RxSDO 0x580 +X <===    |
>          |      RxPDO 0x180*+X <===    |
>-----------                             -----------------

>Mir ist noch immer nicht so ganz klar, wie oder für was ich die
>COB-ID's: 0x200+X und 0x580+X verwenden könnte.
>>Ich möchte z.B. irgendwelche Konfigurationsdaten (Teilnehmernummer) von
>>einem TLN auslesen können und der Master soll die Info dann verarbeiten.
>>Tue ich dies damit, indem z.B. eine SDO Message COB-ID:0x582 und

Jein.
Wenn du Konfigurationsdaten vom Master zum Slave übertragen willst, dann 
nimmst du ein TxSDO 0x600+X, der Slave antwortet mit einem RxSDO: 
0x580+X (zb Mit seinen Konfigdaten)

>Wie kann ich das PDO Message COB-ID:0x200+X
Damit kannst du Prozessdaten an einem Teilnehmer senden. Also könnte der 
Master an einen Teilnehmer irgendwelche Daten senden, die der Teilnehmer 
dann ausgibt.

Achso aber der TLN muss dann aber nicht zwingend Antworten, indem er ein 
SDO mit COB-ID:0x580+X sendet oder? Ich kann mir ja das Datenbyte3 
verwenden. Wenn dieses auf 0x05 steht, dann soll dieser TLN ein SDo 
0x580+X senden. Der Master kann ja diese Info dann auswerten.

>n aber nicht zwingend Antworten

richtig. Es gibt bestätigte und unbestätigte Dienst.

>a das Datenbyte3

Solltest du dir mal in Ruhe überlegen. So langsam klingts wirr.
Am besten mal notieren, was wer wohin schicken können soll. dann 
weitersehen.

(SDO) COB-ID:0x600+X Datenbyte1=NodeId Datenbyte2=Data Length
(SYNC)COB-ID:0x080   Datenbyte1=NodeId Datenbyte2=Data Length
(PDo) COB-ID:0x180+X Datenbyte1 - Datenbyte8: Nutzdaten z.B. Schalterst.

Nun möchte ich irgendwelche Konfigurationsdaten von einem Teilnehmer 
anfordern und zwar über den Master (Dongle).
Dazu hab ich mir überlegt das SDO auszubauen. Dazu könnte ich doch vom 
SDO das 3. Datenbyte verwenden. Wenn dieses auf 0x01 steht soll der 
Teilnehmer anworten mit der SDO 0x580+X.
(Konfigurationsdaten: Teilnehmer Nummer, Baudrate, usw.)

Beispiel:

Master sendet:
0x080 Datenbyte1:0x02 Datenbyte2:0x01
0x601 Datenbyte1:0x02 Datenbyte2:0x01

Der Teilnehmer2 sendet das PDO mit den Nutzdaten
Der Teilnehmer1 empfängt die Nachricht 0x0182 und gibt die Info auf den 
LED's aus.

Jetzt könnte man statt 0x601 Datenbyte1:0x02 Datenbyte2:0x01 noch das 3. 
Datenbyte ins Spiel bringen. Wenn dieses auf 0x01 steht, sendet der 
Teilnehmer1 seine Konfigurationsdaten mit 0x581 auf den Bus.

Ist meine Beschreibung verständlich?

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

(SDO) COB-ID:0x600+X Datenbyte1=NodeId Datenbyte2=Data Length
(SYNC)COB-ID:0x080   Datenbyte1=NodeId Datenbyte2=Data Length
(PDo) COB-ID:0x180+X Datenbyte1 - Datenbyte8: Nutzdaten z.B. Schalterst.

Nun möchte ich irgendwelche Konfigurationsdaten von einem Teilnehmer
anfordern und zwar über den Master (Dongle).
Dazu hab ich mir überlegt das SDO auszubauen. Dazu könnte ich doch vom
SDO das 3. Datenbyte verwenden. Wenn dieses auf 0x01 steht soll der
Teilnehmer anworten mit der SDO 0x580+X.
(Konfigurationsdaten: Teilnehmer Nummer, Baudrate, usw.)

Beispiel:

Master sendet:
0x080 Datenbyte1:0x02 Datenbyte2:0x01
0x601 Datenbyte1:0x02 Datenbyte2:0x01

Der Teilnehmer2 sendet das PDO mit den Nutzdaten
Der Teilnehmer1 empfängt die Nachricht 0x0182 und gibt die Info auf den
LED's aus.

Jetzt könnte man statt 0x601 Datenbyte1:0x02 Datenbyte2:0x01 noch das 3.
Datenbyte ins Spiel bringen. Wenn dieses auf 0x01 steht, sendet der
Teilnehmer1 seine Konfigurationsdaten mit 0x581 auf den Bus.

>Dazu könnte ich doch vom SDO das 3. Datenbyte verwenden

Naja, man könnte auch vorher nochmal über alles nachdenken:
zum Thema SDOs: Konfigurationsdaten, was soll alles so übertragen 
werden:
- Teilnehmernummer, auf die gehört werden soll   [0x01],
- Abfrage des aktuell zu hörenden Teilnehmers    ]0x02],
- ...

(denk dir was aus)

Dann würde ich diese Liste durchnummerieren (siehe Zahlen in [])
Diese Zahl würde ich als ERSTES Datenbyte beim SDO senden mit 0x600+X. 
Abhängig davon haben die zweiten..achten Datenbytes eine enstprechende 
UNTERSCHIEDLICHE Bedeutung:
bsp:
Datenbyte #1: 0x01   (Konfigdaten: TLN auf den gehört werden soll)
Datenbyte #2: hier ist die TLN-Nummer, auf die gehört werden soll.
Datenbyte #3..8: nicht vorhanden, oder weitere TLN
Der DataLengthCode richtet sich IMMER nach der aktuellen Anzahl Daten

weiteres Bsp:
Datenbyte #1: 0x02   (Konfigdaten: TLN Nummer abfragen)
keine weiteren Datenbytes. Hier folgt eine Antwort mit 0x580+X. Aufbau 
der Antwort (hier jetzt) noch offen.

Ich weiß nicht, ob das alles CANopen konform ist, aber so baue ich 
Bus-protokolle auf.


PS: Mach mal ruhig! Ist schönes Wetter => BAGGERSEE

Ich verstehe deinen letzten Beitrag nicht.

>Dann würde ich diese Liste durchnummerieren (siehe Zahlen in [])

Ich weiss nicht wo und welche Nummer.

>Diese Zahl würde ich als ERSTES Datenbyte beim SDO senden mit 0x600+X.

Das verstehe ich nicht. In dem ersten Datenbyte soll doch nur die 
Teilnehmernummer stehen oder?

>Abhängig davon haben die zweiten..achten Datenbytes eine enstprechende
>UNTERSCHIEDLICHE Bedeutung:
>bsp:
>Datenbyte #1: 0x01   (Konfigdaten: TLN auf den gehört werden soll)
>Datenbyte #2: hier ist die TLN-Nummer, auf die gehört werden soll.
>Datenbyte #3..8: nicht vorhanden, oder weitere TLN
>Der DataLengthCode richtet sich IMMER nach der aktuellen Anzahl Daten

Warum sollen Datenbyte1 und Datenbyte2 die gleich Info enthalten?

>weiteres Bsp:
>Datenbyte #1: 0x02   (Konfigdaten: TLN Nummer abfragen)
>keine weiteren Datenbytes. Hier folgt eine Antwort mit 0x580+X. Aufbau
>der Antwort (hier jetzt) noch offen.

Das verstehe ich auch nicht.

Wenn ich ein SDO an einen Teilnehmer sende muss man doch nicht 
zwangsläufig eine Antwort (z.B. 0x581) senden oder?

>Wenn ich ein SDO an einen Teilnehmer sende muss man doch nicht
>zwangsläufig eine Antwort (z.B. 0x581) senden oder?

Das ist richtig. Den Rest hast du aber wirklich nicht verstanden.:


>>Abhängig davon haben die zweiten..achten Datenbytes eine enstprechende
>>UNTERSCHIEDLICHE Bedeutung:
>>bsp:
>>Datenbyte #1: 0x01   (Konfigdaten: TLN auf den gehört werden soll)
>>Datenbyte #2: hier ist die TLN-Nummer, auf die gehört werden soll.
>>Datenbyte #3..8: nicht vorhanden, oder weitere TLN
>>Der DataLengthCode richtet sich IMMER nach der aktuellen Anzahl Daten

>Warum sollen Datenbyte1 und Datenbyte2 die gleich Info enthalten?

Stimmt nicht. Meine Idee war folgende (gilt nur für SDOs vom Master):
Das erste Datenbyte bestimmt, was das SDO bewirken soll. Also so eine 
Art Kommando/Befehl:
Ist dieses 0x01, dann willst du dem Teilnehmer mitteilen, auf welchen 
(anderen) Teilnehmer er (ab jetzt) hören soll. Das meinte ich mit 
>>>"Datenbyte #1: 0x01   (Konfigdaten: TLN auf den gehört werden soll)".
Die eigentliche Information selbst befindet sich in Datenbyte2. Deshalb 
>>>"Datenbyte #2: hier ist die TLN-Nummer, auf die gehört werden soll."
Weitere Datenbytes werden hier nicht benötigt. Deshalb DLC(data length 
code)=2.


Möchtest du jetzt allerdings den Teilnehmer nach seiner Konfiguration 
BEFRAGEN (also auf welchen TLN er gerade hört), so wird das erste 
Datenbyte, welches ja ein Kommando/Befehl darstellt, auf 0x02 gesetzt.

So ist das gemeint.

Achso ok.

Beispiel1:
Master sendet 0x601 und Datenbyte1:0x02 Datenbyte2:0x02
Daraufhin antwortet der Teilnehmer1 mit 0x581 und 
Konfigurationsdaten(dieLänge ist abhängig vom Datenbyte2 der Nachricht 
0x601)

Beispiel2:
Master sendet 0x601 und Datenbyte1:0x01 Datenbyte2:0x02
Der Teilnehmer1 antowrtet nun nicht mit 0x581 und Konfigurationsdaten.
Der Teilnehmer1 soll jetzt nur auf das PDO 0x181 hören.

Ich muss mich korrigieren:

Beispiel1:
Master sendet 0x601 und Datenbyte1:0x02 Datenbyte2:0x02
Daraufhin antwortet der Teilnehmer1 mit 0x581 und
Konfigurationsdaten(dieLänge ist abhängig vom Datenbyte2 der Nachricht
0x601). Zusätzlich soll noch der Teilnehmer1 auf das PDO 0x181 hören.

Beispiel2:
Master sendet 0x601 und Datenbyte1:0x01 Datenbyte2:0x02
Der Teilnehmer1 antwortet nun nicht mit 0x581 und Konfigurationsdaten.
Der Teilnehmer1 soll jetzt nur auf das PDO 0x181 hören.

Naja, so etwa. aber auch nicht ganz:

>Master sendet 0x601 und Datenbyte1:0x02 Datenbyte2:0x02
(Das bsp deckt sich nicht mit meinem bsp, macht aber erstmal nix)
Wenn das das bedeuten soll:
>Daraufhin antwortet der Teilnehmer1 mit 0x581 und
>Konfigurationsdaten(dieLänge ist abhängig vom Datenbyte2 der Nachricht
>0x601)
was soll dann das Datenbyte2 aussagen?? Datenbyte1 ist das Kommando 
"sende mir mal deine konfiguration" datenbyte2 trägt keine info und 
sollte weggelassen werden.

>Beispiel2:
>Master sendet 0x601 und Datenbyte1:0x01 Datenbyte2:0x02
>Der Teilnehmer1 antowrtet nun nicht mit 0x581 und Konfigurationsdaten.
>Der Teilnehmer1 soll jetzt nur auf das PDO 0x181 hören.

Es sollte eher PDO 0x182 heißen. dann würde es passen.

Danke. Ich hab voll den Mist geschrieben. Ja ok ich meinte auch 0x182.
Mit dem Kommando (Datenbyte1) kann zum Beispiel festgelegt werden ob 
eine Antwort vom Teilnehmer erfolgen soll oder nicht.

Kommando (Datenbyte1):
0x01 = TLN auf den gehört werden soll
0x02 = TLN soll Konfigurationsdaten zum Master (CanBus) senden mit 0x581
0x03 = TLN auf den gehört werden soll +
       TLN soll Konfigurationsdaten zum Master (CanBus) senden mit 0x581

Datenbyte2: kann eventuell die Länge der Konfigurationsdaten festgelegt 
werden, bzw. wieviel Nutzdaten vom PDO empfangen werden dürfen.

Ja, so in etwa. Das Beispiel mit deinen drei Kommandobytes wäre denkbar.
Am besten du machst erstmal eine Liste mit allen möglichen/notwendigen 
Befehlen die du so brauchst.
Ich würde wahrsch deinen 0x03 befehl weglassen, und halt 0x01 und danach 
0x02 senden. wäre sonst doppelt gemoppelt..
Oder ein Bit im Datenbyte als "Antwort erwünscht" verwenden... dann 
könnte nach ausführen des befehls die neue konfiguration zurückgesendet 
werden..


Aber ob mit 0x581 geantwortet wird, hat erstmal nix mit der SDO 
nachricht selbst zutun, sondern NUR mit der eigenen Knotennummer!

Wie gesagt, am besten erstmal ne Liste machen, was du für Befehle 
brauchst.
Danach dann für jeden Befehl einzeln überlegen, welche bzw ob 
"zusätzlichen" Daten benötigt werden

Eigentlich wäre das bei mir schon alles.
Mehr Kommandos brächte ich erstmal nicht.

Kommando:
0x01 = TLN auf den gehört werden soll
0x02 = TLN soll Konfigurationsdaten zum Master senden mit 0x580+X

Das mit der Datenlänge weiss ich nicht wie ich dies mit dem SDO 
realisieren könnte. Mit der Datenlänge möchte ich festlegen wieviel 
Nutzdaten die PDO Nachricht beinhaltet.

Dann hast du halt erstmal nur zwei Kommandos. Sowas kann ja bei Bedarf 
erweitert werden.

>Das mit der Datenlänge weiss ich nicht wie ich dies mit dem SDO
>realisieren könnte. Mit der Datenlänge möchte ich festlegen wieviel
>Nutzdaten die PDO Nachricht beinhaltet.

Wieso unterscheidet sich das? gib mal paar Beispiele welche/wieviel 
Nutzdaten du hast

Die Nutzdaten können unterschiedlich lange sein.
Je nachdem was die SYNC Nachricht 0x080 sendet.

SYNC Nachricht:
Datenbyte1: welche TLN soll die PDO 0x180+X senden
Datenbyte2: Datenlänge der Nutzdaten (1 bis 8 Bytes)

SDO Nachricht:
soll dann die Datenlänge festlegen die dann empfangen werden können.

(SYNC)COB-ID:0x080   Datenbyte1=NodeId Datenbyte2=Data Length
(PDO) COB-ID:0x180+X Datenbyte1 ... Datenbyte8: Nutzdaten z.B. TLN Nr.
(SDO) COB-ID:0x600+X Datenbyte1=Kommando Datenbyte2=Data Length

>Datenbyte2=Data Length
>Datenbyte2: Datenlänge der Nutzdaten (1 bis 8 Bytes)

Versteh ich nicht. Warum das????

Es gibt doch einen extra wert, den data-length-code...

Komm da grad nicht mit

(SYNC)COB-ID:0x080   DLC=0...8,Datenbyte1=NodeId,Datenbyte2...8=kann für 
andere Zwecke verwendet werden.
(PDO) COB-ID:0x180+X DLC=0...8,Datenbyte1...8=Nutzdaten z.B. TLN Nr.
(SDO) COB-ID:0x600+X DLC=0...8,Datenbyte1=Kommando
Steht DLC auf 0x05,dann soll 5 Datenbytes vom PDO empfangen werden.
Steht DLC auf 0x01,dann soll 1 Datenbyte vom PDO empfangen werden.

>PDO) COB-ID:0x180+X DLC=0...8,Datenbyte1...8=Nutzdaten z.B. TLN Nr.
                                                             ^^^^^^ 
Hä???

>Steht DLC auf 0x05,dann soll 5 Datenbytes vom PDO empfangen werden.
>Steht DLC auf 0x01,dann soll 1 Datenbyte vom PDO empfangen werden.

Das ist schon klar, aber wozu soll DIESE information IN DEN datenbytes 
SELBST nochmal stehen???

(SYNC)COB-ID:0x080   DLC=0...8,Datenbyte1=NodeId,Datenbyte2...8=kann für
andere Zwecke verwendet werden.
(PDO) COB-ID:0x180+X DLC=0...8,Datenbyte1...8=Nutzdaten z.B. 
Schalterstellungen oder andere Daten
(SDO) COB-ID:0x600+X DLC=0...8,Datenbyte1=Kommando
Steht DLC auf 0x05,dann soll 5 Datenbytes vom PDO empfangen werden.
Steht DLC auf 0x01,dann soll 1 Datenbyte vom PDO empfangen werden.

>Das ist schon klar, aber wozu soll DIESE information IN DEN datenbytes
>SELBST nochmal stehen???

Dies hab ich doch entfernt. Die Länge wird bestimmt durch den data 
length code (DLC)

Also mit der SYNC Nachricht muss ich doch trotz all dem die Länge der 
PDO Nutzdaten angeben. Dies muss ich doch mit einem Datenbyte von der 
SYNC Nachricht tun.

(SYNC)COB-ID:0x080   DLC=0...8,Datenbyte1=NodeId,Datenbyte2=DLC für PDO 
Nutzdaten,Datenbyte3...8=kann für andere Zwecke verwendet werden.

Anders kann ich mir dies nicht vorstellen, wie es noch gehen könnte.

Wie würdest du genau das mit dem DLC lösen?

>m die Länge der PDO Nutzdaten angeben.

Warum unterscheiden die sich?

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

>Warum unterscheiden die sich?

Was meinst du damit?

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

Hi Matthias, ich hoffe du kannst mich verstehe.
Wahrscheinlich denke ich immer viel zu kompliziert.
Deine Hilfe ist sehr hilfreich für mich, von daher nochmals danke!

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

Wozu das?

Der Teilnehmer sendet per PDO seine Nutzdaten alle weg.
Warum soll da irgendeine Länge parametriert werden..?

Ok dann parametriere ich die Datenlänge nicht über das SDO.
Ich lasse es ganz weg. In dem SDO gebe ich nur das Kommando sowie die 
TLN Nr. an, auf welche PDO der TLN reagieren soll.

Was kann man eigentlich noch alles mit dem SDO tun? Welche Kommandos 
könnte man noch ergänzen?

>ch lasse es ganz weg. In dem SDO gebe ich nur das Kommando sowie die
>TLN Nr. an, auf welche PDO der TLN reagieren soll.

Halte ich so für sinnvoll.


>Was kann man eigentlich noch alles mit dem SDO tun? Welche Kommandos
>könnte man noch ergänzen?

Keine Ahnung was du so alles damit vorhast...
Lass dir was einfallen...

Ich habe dir jedenfalls Tipps gegeben um das zum Laufen zu Bringen...
Sind aber nur Tipps. Ideen was du willst kann ich nicht bringen.. Nur 
Tipps zum Umsetzen...

Guten Morgen Matthias L.,

auf jeden Teilnehmer habe ich zuächst mal Variablen festgelegt.
Die Variablen sind vom Typ 1 x float, 1 x integer, 2 x char.
Diese Daten kann ich über ein PDO senden und empfangen.
Die float Variable beinhaltet den AD Wandlerwert, die Integer Variable 
für sonstiges, eine char Variable ist für die Anzeige der LED's und die 
andere char Variable soll für Einstellungen/Kommandos sein.
Wenn ich Daten nur zwischen Master und Slave(TLN) versenden 
bzs.empfangen möchte kann ich die PDO(Tx) und PDO(Rx) verwenden.
Mit PDO(Rx) kann der Master die Daten an einen Teilnehmer senden.
Z.B. Wert für LED Anzeige bzw. Kommando ob der Teilnehmer mit dem 
PDO(Tx) seine Daten (AD Werte) auf den Bus senden soll oder nicht.
Wäre dieses Vorgehen ok so?
Wie gesagt die SYNC und SDO Nachrichten lasse ich für diese Betrachtung 
mal weg.

Für eine reine Master Slave kommunikation kann ich ja zjnächst nur die 
PDO(Tx) und PDO(Rx) benutzen oder? Die Slaves sollen untereinander nicht 
kommunizieren.

Hi Matthias L,

mit PDO(Tx) 0x180+X sende ich die Nutzdaten von einem Teilnehmer.
Was macht dann der PDO(Rx) genau? Soll damit die Nutzdaten des anderen 
Teilnehmers empfangen werden können?

Mit dem PDO(Rx) 0x600+X sende ich zum einen ein sogenanntes Kommando 
(Datenbyte1) und die anderen Datenbytes2...8 sende ich Nutzdaten.
Datenbyte2 = char
Datenbyte3..4 = integer
Datenbyte5..8 = float

Diese Variablen enthält zunächst jeder Teilnehmer. Diese werden 
entsprechend wie das Datenbyte1(Kommando) aussieht geschrieben bzw. 
veranlasst dass das PDO(Tx) 0x180+X gesendet wird.

Im Datenbyte3..4 beinhaltet den AD Wandlerwert
Im Datenbyte5..8 umgerechneter AD Wert in Spannung (Beispiel:2,56V)

>mit PDO(Tx) 0x180+X sende i..

Jein. Das ist aber ein RxPDO (weil vom Master aus gesehen). Sonst 
korrekt.


>Was macht dann der PDO(Rx) genau? Soll damit die Nutzdaten des anderen
>Teilnehmers empfangen werden können?

Hier ist dann das TxPDO gemeint. COB: 0x200+X. Damit können Nutzdaten 
(zB Ausgänge) vom Master zu einem Slave (Teilnehmer) gesendet werden...

Mit COB-ID:200+X sende ich eine Nachricht an einen Teilnehmer.
Mit dem Datenbyte1 sage ich dann dem Teilnehmer was er tun soll.
Zum Beispiel 0x01 bedeutet bei mir, schreibe Datenbyte2...Datenbyte8 in 
die entsprechenden Variablen.
Wenn ich nun vom Teilnehmer den AD Wert usw. auslesen möchte dann sende 
ich 0x02. Der Teilnehmer sendet dann seine Daten mit der COB-ID:0x180+X.
Das wäre jetzt ein reiner MASTER SLAVE Kommunikation.

>Das wäre jetzt ein reiner MASTER SLAVE Kommunikation.

Ja, aber CAN ist eher dazu da, Nachrichten ereignisgesteuert abzusenden.
CANopen funktioniert nach Master-Slave, damit ein deterministisches 
Verhalten entsteht.

Wie du es genau löst, ist dir überlassen. Weil du das Projekt eh nicht 
KOMPLETT CANopen-konform bekommst. Das sollte aber egal sein..

Also mit meinen Tips hast dus zum Laufen gebracht. Probier weiter, frag 
weiter und sammel Erfahrungen...

Guten Morgen Matthias L,

was meinst du mit "Nachrichten ereignisgesteuert absenden"?

Mit COB-ID:200+X sende ich eine Nachricht an einen Teilnehmer.
Mit dem Datenbyte1 sage ich dann dem Teilnehmer was er tun soll.
Zum Beispiel Datenbyte1:0x01 bedeutet bei mir, schreibe 
Datenbyte2...Datenbyte8 in die entsprechenden Variablen.
Wenn ich nun vom Teilnehmer den AD Wert usw. auslesen möchte dann sende
ich COB-ID:200+X und Datenbyte1:0x02. Der Teilnehmer sendet dann seine 
Daten mit der COB-ID:0x180+X.

Dies ist doch ereignisgesteuert und zwar durch das Datenbyte1. So 
verstehe ich dies.

>Dies ist doch ereignisgesteuert und zwar durch das Datenbyte1. So
>verstehe ich dies.

Nein. Mit ereignisgesteuert meine ich, sobald sich der Eingang/die 
Temperatur.. ändert, sendet der Teilnehmer VON ALLEIN diese neue 
Information (mit COB-ID:0x180+X).

Achso! Ja und wie realisiert man dies genau?

Zum Beispiel so:

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

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

>if(ADwert != ADwert)

Naja, das wird NIE wahr!

Eher so:

1

ADwert = ADC;

2

3

if ( ADwert_alt != ADwert )

4

{

5

    ADwert_alt = ADwert;

6

    TransmitCANMessage(...);

7

}

Bei digitalen Eingängen mag das so gehen, aber bei Analogen nicht: Da 
Solltest allerdings über eine Filterung, Zeit, etc nachdenken. Weil der 
ADwert bei Wandlungen immer (um ein zwei LSB) schwankt...

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

>Ist dies überhaupt möglich?

Unmöglich ist garnichts ;-)

Du könntest ein IIR Filter nehmen. ALso ein PT1 diskret aufgebaut.
Über die Abtastfrequenz und Zeitkonstante musst du dir Gedanken machen.

Doer einfacher wäre es, nur einen neuen Wert zu übertragen, wenn sich 
der neue um ... gegenüber dem alten verändert hat..

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

>ann dies auch per Software (Ansi C) realisiert werden?

Na sicher doch. Ist ja nur eine Differenzengleichung:
Stichwort: digitale Filter, mal im DSP-Forum schnüffeln

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

Das weiß ich nicht.