Hallo, ich habe folgendes theoretisches Problem für die Uni und hänge bei der Erstellung eines CAN-Protokolls an folgender Fragestellung: Ich habe ein Display auf dem mir Meldungen angezeigt werden und von der ich aus verschiedene Nachrichten zu den Steuergeräten in einem Fahrzeug schicken kann. Ich möchte nun sagen wir mal alle 4 Fenster gleichzeitig über das Display schließen. Kein Problem. Ich sende eine Nachricht auf den CAN-Bus und jedes Türsteuergerät weiß was es damit anfangen kann. Das heißt eine Nachricht mit einem Identifier für alle 4 Fenster. Jetzt habe ich aber einen Sensor der mir mitteilt, dass sich das Fenster auch wirklich geschlossen hat. Bei einem der Fenster kommt es aber zu einer Fehlermeldung. (Beispielsweise es hat sich was dazwischen eingeklemmt) Meine Frage: Wie kann ich sicherstellen, dass auf meinem Display angezeigt wird welches Fenster betroffen ist. Klar zum einen kann ich das über den Türknoten machen. ABER und jetzt kommen wir zu meiner wirklichen Frage. Gehen wir davon aus, dass wir nur ein Steuergerät haben für die Fenster. Befehl fensterSchließen() führt dazu, dass alle hochfahren. Einer hat einen Fehler. Ist es möglich im Datenfeld der CAN-Nachricht auch gleichzeitig mitzuteilen welches Fenster stecken geblieben ist? Hmm ich hoffe, dass ich mich einigermaßen verständlich ausgedrückt habe. Vielen Dank :)
Bei 29 Bit für die ID wirst Du ja wohl noch ein paar Bits für die Knotennummer übrig haben. fchk
wenn ich jetzt nicht vom extended sondern vom standard ausgehe habe ich ja nur 11bits. Aber das tut vorerst nichts zur Sache. Mir geht es darum, dass ich gerne mit einer Nachricht alle Fenster schließen möchte, aber dann die Bestätigung von jedem Fenster erhalten möchte, dass es sich auch wirklich geschlossen hat. Ist es überhaupt vorgesehen, dass eine Nachricht an mehrere Steuergeräte versendet wird. Beziehungsweise, dass die selbe Nachricht von mehreren Steuergeräten gelesen und verwendet werden darf. Darf ich im Datenfeld Kennzeichnungen mitteilen? Beispielsweise (es ist das Fenster hinten rechts)
Peter Schneider schrieb: > Ist es überhaupt vorgesehen, dass eine Nachricht an mehrere Steuergeräte > versendet wird. Beziehungsweise, dass die selbe Nachricht von mehreren > Steuergeräten gelesen und verwendet werden darf. > Klar, du adressierst ja die Messages nicht an einen bestimmten Empfänger, sondern die Message-ID steht nur für die Bedeutung der Message. Sie kann von vielen Empfängern gelesen werden. Nur dürfen nicht mehrere Sender die gleiche ID versenden, das ist verboten und führt zu Fehlern. > Darf ich im Datenfeld Kennzeichnungen mitteilen? Beispielsweise (es ist > das Fenster hinten rechts) Im Datenfeld darfs du alles mitteilen, was du möchtest. Du hast pro ID ein Datenfeld mit 8 Byte, wo du reinschreiben kannst, was du willst. Es ist nur sinnvoll, wenn es dann einen Empfänger gibt, der die Bedeutung der 8 Bits kennt. Angenommen, du hast 8 Fenster. Dann kannst du ein Byte deiner Message für den Status der Fenster verwenden und kannst beim Empfänger durch die Auswertung der 8 Bits dieses Bytes erkennen, welches Fenster offen und welches geschlossen ist.
> Klar, du adressierst ja die Messages nicht an einen bestimmten > Empfänger, sondern die Message-ID steht nur für die Bedeutung der > Message. Sie kann von vielen Empfängern gelesen werden. Nur dürfen nicht > mehrere Sender die gleiche ID versenden, das ist verboten und führt zu > Fehlern. Das heißt für mich folgendes: Gehen wir davon aus, ich habe 4 Türsteuergeräte. Jedem schicke ich die Nachricht fenster_schließen(). Dann erhalte ich von 3en die Meldung fenster_ist_geschlossen() mit der ID des jeweligen Knoten im Datenfeld und 1 Meldung mit fenster_fehler() mit der ID des jeweiligen fehlerhaften Türknotens. (ebenfalls im Datenfeld) Die Nachricht ID der ersten 3en ist aber die selbe. Nur kann die Nachricht fenster_ist_geschlossen() nur vom Display-Steuergerät verstanden werden. Dadurch hätte ich aber die selbe Nachricht mit der selben ID aber nur einem Empfänger. Im Datenfeld hätte es dann aber die genaue Kennzeichnung. Oder soll ich die selbe Methode (in dem Fall fenster_ist_geschlossen() ) in jedem Türsteuergerät mit einer unterschiedlichen ID versehen.
Peter Schneider schrieb: > Ist es überhaupt vorgesehen, dass eine Nachricht an mehrere Steuergeräte > versendet wird. Wie viele Steuergeräte glaubst du denn zu haben? Wie definierst du denn ein "Steuergerät"? CAN ist multimasterfähig. Laß das mal etwas sacken. Was hindert dich (generell) daran, daß jedes Fenster seinen aktuellen Status mitteilt? An wen auch immer. CAN ist ein Protokoll. Du nutzt es als Transportschicht. Was du wie transportierst, ist (fast) nur von deiner Phantasie begrenzt.
Peter Schneider schrieb: > Oder soll ich die selbe Methode (in dem Fall fenster_ist_geschlossen() ) > in jedem Türsteuergerät mit einer unterschiedlichen ID versehen. Bingo! Du hast 11 bit, um den Inhalt eines Frames zu codieren. Aber programmiere nicht einfach drauf los: Die Identifier sollten schon vernünftig strukturiert sein. Außer, du brauchst nur ein paar verschiedene Identifier. Grund: Jeder Knoten muß zum Empfangen (eine beschränkte Anzahl von) Bitmasken setzen, welche Identifier er empfangen soll. Bei vielen ID's ist es dann erforderlich, einen Bereich und keine einzelnen Identifier zu codieren. Und das geht nur mit Struktur.
Steuergeräte sind für mich elektronische Bauteile die eine Nachricht empfangen können und sie je nach Nachricht weiterverarbeiten können oder nicht (falls die Nachricht im Falle eines CAN-Busses) nicht für sie war. Ich habe das mit Multimasterbetrieb schon verstanden. Auf jeden Fall bin ich schon einen Schritt weiter. Ich mache das jetzt so. Ich habe 4 Türsteuergeräte mit unterschiedlichen Bezeichnungen. Tür_Fahrer, Tür_Beifahrer... etc... Diese können alle die Nachricht fenster_schließen() empfangen. Jede von denen kann die Nachricht fenster_geschlossen() oder fenster_fehler() senden und diese Nachrichten haben die SELBE NachrichtID aber nur das Display-Steuergerät kann es interpretieren (empfangen tut es ja jedes) und im Datenfeld der Nachricht wird mitgeteilt was genau passiert ist und um welche Tür es sich handelt. Stimmt das so? Mir geht es darum, dass ich nicht genau verstehe wie ich herausfinden kann woher eine Nachricht kommt. In der Nachricht selber steht ja nicht der Empfänger drin oder? edit: Ich will nicht drauflos programmieren. Ich will und muss es nur theoretisch auf Papier erläutern.
:
Bearbeitet durch User
Lutz schrieb: > Bingo! Du hast 11 bit, um den Inhalt eines Frames zu codieren. Da bin ich anderer Meinung. Ein Frame enthält u. a. auch noch Daten. Aufbau CAN-Telegramm siehe hier: http://de.wikipedia.org/wiki/Controller_Area_Network#Frame-Aufbau
Mit 11bit waren wohl die Anzahl an Nachrichten gemeint die ich erstellen kann. Das habe ich schon verstanden. Danke. :)
Lottermann schrieb: > Da bin ich anderer Meinung. Ein Frame enthält u. a. auch noch Daten. Natürlich enthält ein CAN 2.0A Frame mehr als den Identifier. Aber im Identifier ist die Bedeutung enthalten. Peter Schneider schrieb: > Diese können alle die Nachricht fenster_schließen() empfangen. Genau. Definierte z.B. Identifier 1 mit fenscter_schließen. DA sollen alle Fenster drauf reagieren. Dann definiert du aber auch mit ID 2 fenter_1_schließen, mit ID 3 fenster_2_schließen usw. Macht alles viel flexibler; also auch "Gruppenbefehle" über die ID definieren. > Jede von denen kann die Nachricht fenster_geschlossen() oder > fenster_fehler() senden ja, aber wie zuvor: fenster_1_geschlossen, fenster_2_geschlossen usw. > und diese Nachrichten haben die SELBE NachrichtID Nö. > aber nur das Display-Steuergerät kann es interpretieren (empfangen tut > es ja jedes) Und wie/woran kann es das? Wenn man ohne Nutzdaten (die 8 bytes) auskommt, sollte man es aus Performancegründen auch tun.
Peter Schneider schrieb: > Mit 11bit waren wohl die Anzahl an Nachrichten gemeint die ich erstellen > kann. Das habe ich schon verstanden. Danke. :) Mit fehlen Zeit & Geduld darauf näher einzugehen, aber das ist nicht richtig :)
Gut. Vielen lieben Dank an alle die mir geholfen haben. Vor allem an Lutz. Dann werde ich einfach zusätzliche Methoden schreiben das jedes einzelne Fenster separat behandelt. Vielen Dank. Wenn ich noch Fragen habe, werde ich mich auf jeden Fall melden :)
Lutz schrieb: > Wenn man ohne Nutzdaten (die 8 bytes) auskommt, sollte man es aus > Performancegründen auch tun. Letzter Nachtrag: Du wirst natürlich früh genug auch Nutzdaten in den 8 byte befördern müssen. Aber solange es auch irgendwie ohne geht ... Wenn später eine hohe Busbelastung ist und die Arbitrierung greift (gaaaaanz wichtig bei der Vergabe der ID ...), ist Abspecken/Ändern schwerer. Noch ein Beipiel (obwohl du es jetzt schon verstanden hast): Z.B. die Bordspannung ist in einem CAN-Frame über den Identifier codiert. Da brauchst du dann natürlich auch den echten Wert (außer z.B., es wird mit einer allgemeinen Aussage gearbeitet "U ist größer 13 V" oder so): Diser Frame wird vom Laderegler, der elektr. Heizung usw. sicherlich auch emfangen.
Jede Naricht auf einem Bus wird von allen Steuergeräten empfangen, allerdings nur nach identifier verarbeitet. Normalerweise hat ein Steuergerät mind. zwei identifier. Einen für Empfang und einen zum Versandt von Nachrichten. Somit liese sich die Sendeadresse auswerten um das exakte Fenster zu lokalisieren. Allerdings wie oben schon geschrieben ist für Gemeindschaftsbefehle (alle Fenster schließen) ein extra Identifier in den einzelnen Steuergeräten für die Fenster zu hinterlegen. Allerdings ist jedes Sicherheitssystem, Lichter, Motorsteuerung, Kommunikations-, Navi- und Unterhaltungssystem usw. auf ein und dem selben Bus. Deshalb ist es nicht ganz einfach in einem Komplettsystem solch zusätzliche Informationen zu handeln, da nonstop Überwachungsfunktionen des Motors, Passagiere usw gesendet werden, da diese Infos für Gurtstraffer, Airback, Türöffner, Tachoanzeigen und Bordcomputer immer zur verfügung stehen müssen.
Hallo, Mike schrieb: > Normalerweise hat ein Steuergerät mind. zwei identifier. Einen für > Empfang und einen zum Versandt von Nachrichten. zumindest im Auto haben die Steuergeräte in der Regel keinen eigenen Empfangs-Identifier (außer für OBD), dafür durchaus deutlich mehr als einen Versand-Identifier. Das liegt daran, das im Auto in der Regel keine Befehle und Empfangsquittungen ausgetauscht werden, sondern "nur" aktuelle Zustandswerte. Man kann sich das so vorstellen: Jedes Steuergerät sendet die Informationen, die es irgend einem anderen Steuergerät mitteilen möchte in einer oder mehreren Nachrichten (mit entsprechenden Identifiern). Dabei ist es ihm primär egal, ob ein, zwei oder gar kein anderes Steuergerät darauf reagiert. In den allermeisten Fällen wird dabei die Information zyklisch gesendet und nicht erst, wenn ein Ereignis stattfindet. Auf der anderen Seite hören alle Steuergeräte den Bus ab, ob Nachrichten mit Informationen vorbeikommen, die sie interessieren. Diese werden dann ausgewertet und entsprechend verarbeitet. Zu Deinem Beispiel: Das Steuergerät, an dem die Hoch-/Runter-Taster angeschlossen sind, sendet alle 20 Millisekunden eine Nachricht mit der ID "Schalterinfo" auf den Bus, in der die Stellung der Schalter eingetragen sind (sollte in 8 Bytes kein Problem darstellen). Das oder die Fensterheber-Steuergeräte hören den Bus auf die Nachricht "Schalterinfo" ab und betätigen den Fensterheber entsprechend "ihrer" Schalterposition. Zusätzlich senden auch sie den Zustand der Fenster regelmäßig auf den Bus. Dabei kommt es darauf an, ob es ein oder mehrere Steuergeräte sind, ob man die Zustandsinformation in eine oder in mehrere Nachrichten verpacken kann, da ein Identifier nicht von zwei Steuergeräten verwendet werden darf. Werden mehrere Steuergeräte verwendet, die die Statusinfos "Fensterposition 1", "Fensterposition 2",... senden, so muss natürlich die Anzeige alle diese Nachrichten abhören und auswerten. Ansonsten kann (und sollte) man natürlich alle Zustände in eine Nachricht "Fensterposition" packen. Analog muss, wenn mehr als ein Steuergerät die Fenster betätigen können soll, das Fensterhebermodul alle "Schalterinfo 1" bis "Schalterinfo N"-Nachrichten abhören. Klingt jetzt erst einmal blöd, dass man nicht die gleiche Nachricht von verschiedenen Steuergeräten abschicken kann, ist aber dem Multi-Master-Bus geschuldet, da Kollisionen, wenn sie im Identifier stattfinden, dazu führen, dass die höherpriorisierte Nachricht weitergesendet wird, während Kollisionen im Datenfeld dazu führen, dass beide Nachrichten wiederholt werden müssen. Auch kann es - da die Nachrichten nicht Event-Getriggert, sondern regelmäßig gesendet werden - zu Aliasing-Effekten kommen, da das Empfangs-Steuergerät in der Regel seine Aufgaben auch zyklisch abarbeitet. Wird jetzt eine Nachricht mit "Fenster 1 hoch" gesendet, und danach eine von einem anderen Steuergerät mit "Fenster 2 hoch" (welche die Info "Fenster 1 hoch" nicht enthalten kann", so kann es passieren, dass wenn das Fensterhebermodul seine CAN-Mailbox abfragt eben "Fenster 1 hoch" schon durch "Fenster 2 hoch" ersetzt worden ist. Dies liegt wiederum daran, dass zumindest im Automotive-Bereich keine Empfangs-FiFos eingesetzt werden, da die Nachrichten ja sowieso immer wieder kommen. Das ganze kann man natürlich auch komplett anders implementieren (also Event-Getriggert mit Status-Rückmeldung nach Ausführung des Befehls) und dann auch eine Nachricht-ID von verschiedenen Steuergeräten senden lassen (wenn man eben eine FiFo implementiert), allerdings hattest Du ja explizit nach einer Automotive-Umgebung gefragt. Schöne Grüße, Martin P.S.: Der Grund, dass im Automobilbereich nicht Event-Basiert sondern zyklisch gearbeitet wird, liegt einfach daran, dass dann die Busauslastung wesentlich besser bestimmt werden kann, wodurch das Zeitverhalten verbessert wird (auch wenn CAN erst einmal kein Echtzeitbus ist). Bei Event-basierten Bussen kann es zu einer Häufung der Nachrichten (wenn einmal alles gleichzeitig passiert) und dadurch zu einer Verstopfung des Busses kommen(besonders, wenn man gleiche IDs benutzt, da dann Nachrichten auch noch wiederholt werden müssen). Dadurch könnten wichtige Nachrichten zu lange verzögert werden.
:
Bearbeitet durch User
Martin L. schrieb: > so kann es passieren, > dass wenn das Fensterhebermodul seine CAN-Mailbox abfragt eben "Fenster > 1 hoch" schon durch "Fenster 2 hoch" ersetzt worden ist. Dies liegt > wiederum daran, dass zumindest im Automotive-Bereich keine > Empfangs-FiFos eingesetzt werden, da die Nachrichten ja sowieso immer > wieder kommen. Das stimmt so nicht. CAN-Controller haben erstmal Message-Boxen, je nach Controller unterschiedliche viele. Die kann man konfigurieren alles zu empfangen, nur eine bestimmte Botschaft oder alle Botschaften deren ID einem bestimmten Bitmuster entsprechen. Die brauchen sie auch, denn mit dem erfolgreichen Empfang einer Botschaft ist die Message-Box dazu erstmal blockiert und muss von der Software wieder für neuen Empfang freigeschaltet werden. Man könnte also Botschaften verlieren, es wird aber nie eine ältere durch eine neuere ersetzt werden. Wobei CAN im Vergleich zum µC elendig langsam ist. 500kBit/s sind 2µs pro Bit. Ich weiss garnicht aus dem Kopf wie lang so ein minimaler Datenrahmen ist, ist auch zu unwichtig um das gerade mal zu googeln, dürften aber so mindestens 40 Bit sein - ohne Nutzdaten. Also unter 80µs ist eine Botschaft garnicht auf dem CAN unterwegs. Selbst wenn der Bus mit solchen Botschaften zu 100% ausgelastet wäre, das muss man erstmal hinbekommen, dass nicht alle 80µs ein IRQ abgearbeitet werden kann. "Üblich" sind auch Scheduler so im 10ms Raster, die Informationen werden also sowieso nur alle 10ms verarbeitet wenn sie nicht so wichtig waren, dass die direkt im IRQ zu einer Reaktion geführt haben.
Rudolph schrieb: >> so kann es passieren, >> dass wenn das Fensterhebermodul seine CAN-Mailbox abfragt eben "Fenster >> 1 hoch" schon durch "Fenster 2 hoch" ersetzt worden ist. Dies liegt >> wiederum daran, dass zumindest im Automotive-Bereich keine >> Empfangs-FiFos eingesetzt werden, da die Nachrichten ja sowieso immer >> wieder kommen. > > Das stimmt so nicht. > CAN-Controller haben erstmal Message-Boxen, je nach Controller > unterschiedliche viele. > Die kann man konfigurieren alles zu empfangen, nur eine bestimmte > Botschaft oder alle Botschaften deren ID einem bestimmten Bitmuster > entsprechen. > ... Deine Erläuterung ist eine theoretisch-akademische (im negativem Sinne) Betrachtung. Das zeigt, dass du nicht im automotive Bereich oder zumindest nicht in einem produktiven arbeitest. Rudolph schreibt, wie es in Wirklichkeit ist. Er schreibt Sache. Der CAN-Controller MAG Fifos und Buffer haben, die mit neueren Nachrichten nicht überschrieben sein können, aber da die automotive µCs eigentlich immer ein OS haben und eigentlich viel zutun haben (Funktionale Sicherheit, selbstest, Test auf Konsistenz aller möglichen Daten und Peripherie(Hardware)) kopiert ein Stück Software (z.B. ISR, DRM oder durch Pollen) regelmäßig und "BLIND" die Daten aus den Hardware-Buffern des CAN Controller in die entsprechende RAM Variablen. Erst wenn µC Zeit hat, dann werden die Variablen gelesen bzw. Messages interpretiert und Actionen ergriffen. Bis dahin kann und wird (aus eigener Erfahrung) hier ein Überschreiben stattfinden. >Wobei CAN im Vergleich zum µC elendig langsam ist. Wie gesagt, fang mal an in automotive Bereich zu arbeiten, dann wirst du dein Wunder erleben.
ich meinte natürlich: Martin L. schreibt, wie es in Wirklichkeit ist, nicht Rudolph.
reparateur schrieb: > Wie gesagt, fang mal an in automotive Bereich zu arbeiten, dann wirst du > dein Wunder erleben. Schon geil, mir erst nen Fehler vorwerfen, dann mir zustimmen, im Grunde noch das gleiche schreiben und dann noch nen Diss, willkommen im Internet.
Um das nochmal abzuschliessen, das Überschreiben von Botschaften ist keine Eigenschaft der Hardware gegen die man nichts machen kann wie Martin andeutet. Wenn eine Botschaft eingeht wird die dazugehörige Message-Box blockiert. Und nein, da gibt es auch keinen FIFO oder Puffer. Aber es gibt mehrere Message-Boxen, ein ATMega16M1 hat 6, ein 90CAN32 hat 15 und ein MPC5602 oder uPD70F3819 hat 32, mal so als Beispiel im Low-End. Das überschreiben von Daten bevor sie verarbeitet werden passiert alleine durch die implementierte Software. Das muss so aber nicht passieren. Die Botschaft ist wichtig? -> sofort reagieren Die Botschaft interessiert so am Rande? -> Daten wegschreiben, weitermachen Und jetzt widme ich mich wieder meinem gut bezahlten und nicht frustrierenden Automotive Entwickler Job. :-)
Hallo, nur auch noch einmal von mir zur Klarstellung: Man kann natürlich FiFos implementieren. Manchmal wird das auch durch Hardware unterstützt, entweder durch mehrere Messageboxen (in den oben genannten µC) oder tatsächlich als Quasi-FiFo (z.B. MCP2515, bei dem Box 1 in Box 2 "überlaufen" darf). Auch gibt es Hardware, bei der man einstellen kann, ob bei einer vollen Messagebox die neue Nachricht verworfen oder die alte überschrieben werden soll (z.B. bxCAN der STM32-Reihe). Das dachte ich auch oben geschrieben zu haben. Nur ist es wie geschrieben im Automotive-Umfeld eben nicht üblich das entsprechend zu implementieren. Hier wird in der Regel der Inhalt der einkommenden CAN-Nachrichten auf die einzelnen "Signale" verteilt (auf die entweder als globale Variable oder über eine Interface-Funktion zugegriffen werden kann). Dies kann zyklisch oder durch einen Empfangs-Interrupt geschehen. Die einzelnen Signale hingegen werden zyklisch von der Funktionssoftware zur Abarbeitung abgeholt. Damit kann es aber vorkommen,dass zwischen zwei Abarbeitungen der Wert schon wieder überschrieben worden ist. Dabei kann natürlich auch die Priorität der einzelnen Funktionen berücksichtigt werden; normalerweise wird aber einfach sichergestellt, dass die Funktions-Tasks im gleichen Zeitraster oder öfter aufgerufen werden, als die CAN-Nachrichten auf dem Bus vorkommen. Ganz ohne Software-FiFo bekommt man die von Rudolph vorgeschlagene Methode allerdings in der Praxis häufig nicht hin (also wichtige Nachrichten per Interrupt abarbeiten), da im Worst case 55 µs zur Abarbeitung der wichtigen Funktion zur Verfügung stehen, bevor die nächste Nachricht ankommen kann (1 Byte Payload, 1 MBit/s CAN, Standard-Identifier, Kollision mit direkter Nachricht-Wiederholung). Und das ist - zumindest im Automotive-Bereich - für viele Funktionalitäten nicht ausreichend da noch etliche andere zeitkritische Aufgaben wie Drehzahlerfassung, PWM-Generierung/Stromregelung u.ä. parallel laufen - ganz zu schweigen davon, dass natürlich auch etliche "wichtige Funktionen mit CAN-Eingaben" gleichzeitig laufen. Bei komplexeren Steuergeräten kann man deswegen häufig nur maximal zwei, drei Funktionalitäten in einer 0,5ms-Task laufen lassen, während die allermeisten Aufgaben in einer 10ms oder 20ms Task ablaufen. Erschwerend kommt natürlich hinzu, dass in der Regel mehrere CAN-Signale in unterschiedlichen Nachrichten in einer Funktion benötigt werden. Spätestens dann ist die Methode "Abarbeiten wenn sie ankommt" nicht mehr möglich. Dann bleibt dann nur die Variante "Abarbeiten, wenn sie alle angekommen sind" mit FiFo (damit keine Nachrichten verloren gehen). Soll es dann auch noch halbwegs Echtzeitfähig sein, so wird es auch mit FiFo ganz kompliziert (da eventuell Nachrichten unterschiedlichen Alters kombiniert werden könnten). Hier helfen dann Erweiterungen wie TTCAN. Dieser ist aber eher in der Industrie anzutreffen, in Fahrzeugen habe ich so etwas noch nicht gesehen (da wird dann eher direkt auf FlexRay gewechselt). Beide sind dann allerdings wieder Zeitscheiben- und nicht Event-Getriggert und folgen damit der oben von mir beschriebenen Methodik die Status und nicht die Ereignisse zu übertragen. Schöne Grüße, Martin
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.