Announcement: there is an English version of this forum on Hallo Zusammen, ich nutze Arduino Blue Pill & CAN mit SN65HVD230 zur Kommunikation zwischen den einzelnen Blue Pills. Das funktioniert soweit ganz gut nur das niedrig priorisierte Nachrichten sehr lange unterwegs sind. Das Grund dürfte sein, das ich alle Nachrichten im Intervall alle 200 ms sende. Und wenn dann noch einen Nachricht nicht ankommt wird es auf dem Bus voll. final sollen ca 60 Teilnehmer (Blue Pill) auf den CAN Bus zugreifen. Also habe ich umgestellt auf "event gesteuertes versenden" sprich, es wird immer dann gesendet wenn ich ein Eingang am Blue pill ändert. Auch das funktioniert soweit. Mit ist dabei aufgefallen, das wenn der Sender zB Nachricht 0x100011 sendet, sich der Empfänger der Nachricht nicht im CAN befindet, die Nachricht trotzdem als empfangen quittiert wird und somit auch nicht mehr gesendet wird. Mein letzter Versuch Aufbau: 1 Blue Pill als Zentrale versendet Nachricht 0x100011 es ist nur ein Empfänger im CAN Netz. Der Soll aber Nachricht 0x100020 empfangen. nachdem ich die Zentrale eingeschaltet habe wird Nachricht 0x100011 gesendet und zwar immer wieder da das ACK Bit nicht vom Empfänger quittiert wird. Sobald ich den Empfänger für die Nachricht 0x100020 einschalte und dieser im loop ist, wird die Nachricht 0x100011 als empfangen gekennzeichnet. Ich bin bis dato davon aus gegangen das nur der Empfänger die Nachricht quittieren kann, der auch für diese Nachricht vorgesehen ist. Liege ich da falsch? Selbstverständlich habe ich mehrere Blue Pills und auch Transiverbausteine verwendet Im Anhang findet Ihr: Meine CAN programierung in der Zentrale : CANsenden Die Bivliotheken von github : stm32f103.ccp & stm32f103.h Mein Code vom Empfänger: Modul 1 Mein programmcode der Zentrale: Zentrale Kann mal jemand schauen, wo da der Fehler liegt? PS: ich habe die intervallschleife in der Funktion für CAN senden noch nicht entfernt, falls ich die doch noch brauche. PPS noch eine bitte, ich weiß das der Blue Pill kein Arduiono ist, ich weiß das dieser häufig geklont und gefaked wird. Also bitte keine Diskussion über Sinn der Verwendung des STM32 Blue Pill. Danke. Gruß Kay
Kay L. schrieb: > Ich bin bis dato davon aus gegangen das nur der Empfänger die Nachricht > quittieren kann, der auch für diese Nachricht vorgesehen ist. Liege ich > da falsch? Ja das ist falsch. Jeder CAN Empfänger der die Nachricht intakt empfangen hat quittiert via ACK-Bit, auch wenn die Nachricht dann via Filter wieder verworfen wird. Außer man hat dem Empfänger auf "Silent Mode" (oder wie das hieß) gestellt. Das ACK-Bit ist nicht dafür da, den korrekten Empfang durch den gewünschten Empfänger zu signalisieren, sondern nur dazu da, die grundlegende Funktionalität des CAN Bus zu prüfen (Layer 1-2). Kay L. schrieb: > Also bitte keine Diskussion über Sinn der Verwendung des STM32 Blue Pill IMO eine bessere Wahl als ein Arduino mit externem CAN-Controller ...
:
Bearbeitet durch User
Niklas G. schrieb: > Kay L. schrieb: >> Ich bin bis dato davon aus gegangen das nur der Empfänger die Nachricht >> quittieren kann, der auch für diese Nachricht vorgesehen ist. Liege ich >> da falsch? > > Ja das ist falsch. Jeder CAN Empfänger der die Nachricht intakt > empfangen hat quittiert via ACK-Bit, auch wenn die Nachricht dann via > Filter wieder verworfen wird. Außer man hat dem Empfänger auf "Silent > Mode" (oder wie das hieß) gestellt. > > Das ACK-Bit ist nicht dafür da, den korrekten Empfang durch den > gewünschten Empfänger zu signalisieren, sondern nur dazu da, die > grundlegende Funktionalität des CAN Bus zu prüfen (Layer 1-2). > > Kay L. schrieb: >> Also bitte keine Diskussion über Sinn der Verwendung des STM32 Blue Pill > > IMO eine bessere Wahl als ein Arduino mit externem CAN-Controller ... Hallo Niklas, vielen Dank, da hab ich wieder was gelernt! LG Kay
Gern, viel Erfolg 👍 CAN-Nachrichten nur dann zu senden wenn sich was ändert ist eventuell nicht so optimal weil wenn eine Nachricht verloren geht, bekommt der Empfänger die Änderung nie mit. Die simpelste Art der Fehlerkorrektur ist es, die Nachricht immer wieder zu senden. Kay L. schrieb: > alle 200 ms Das ist ja eigentlich ziemlich harmlos. Eine CAN-Nachricht bei 1Mbps braucht unter 1ms IIRC. Wie viele verschiedene Nachrichten senden alle Controller zusammen?
Niklas G. schrieb: > Gern, viel Erfolg 👍 > > CAN-Nachrichten nur dann zu senden wenn sich was ändert ist eventuell > nicht so optimal weil wenn eine Nachricht verloren geht, bekommt der > Empfänger die Änderung nie mit. Die simpelste Art der Fehlerkorrektur > ist es, die Nachricht immer wieder zu senden. > > Kay L. schrieb: >> alle 200 ms > > Das ist ja eigentlich ziemlich harmlos. Eine CAN-Nachricht bei 1Mbps > braucht unter 1ms IIRC. Wie viele verschiedene Nachrichten senden alle > Controller zusammen? Das ist genau mein Problem, das Nachrichten verloren gehen können. Besonders im Einschaltmoment, wenn der Empfänger der Nachricht noch nicht bereit war. Ich steuere dammit meine Modellbahn und alle 200ms zu senden ist bereits zu langsam, weil es passieren kann das Loks eine Lichtschranke fahren aber das vom CAN nicht an die Zentrale gemeldet wird. Ich habe das mit Zählern überprüft, einen am Modul an dem die Lichtschranke hängt und einem in der Zentrale. bei 50 Durchfahrten wurde 3 oder 4 nicht erkannt. Die sind aber essentiell für die weitere Steuerung. Auch werden niedrig priorisierte Nachrichten sehr weit "nach Hinten" verschoben. Die Anzeige auf dem Stellwerk hat teilweise ein oder zwei Sekunden gebraucht um zu wechseln. Dadurch das das Modul "vor ort" den zustand an die Zentrale melde und dann aufgrund der Antwort der zentrale was zu machen ist arbeitet, vergehen im schlimmsten fall 400ms bis der Fahrstrom zb abgeschaltet wird. Ich habe dann mal die maximale Anzahl der Nachrichten ausgerechnet bei 1Kbit passen im Optimalfall ca 7000 Nachrichten pro Sekunde auf den bus. ich arbeite aber mit 500 k bit also nur noch 3500. Bei Übertragung alle 100ms passen rechnerich nur 350 Nachrichten pro Sekunde auf den Bus. Die Anzahl der Teilnehmer auf dem Bus wird am ende knappe 100 sein die hin und her kommunizieren müssen. Also 200 Nachrichten. das wird am ende nicht passen. da muß ich mal überlegen wie ich das löse Gruß kay
Kay L. schrieb: > bei 50 Durchfahrten wurde 3 oder 4 nicht erkannt. Das ist ein ziemlich hoher Verlust. Du hast vermutlich Störungen auf dem Bus. Die sind leider nicht so leicht zu identifizieren. Durch bessere Verdrahtung kann man das verbessern. Also kurze/keine Stichleitungen, korrekte Terminierung, gute Masseführung, Schirmung...
Niklas G. schrieb: > Kay L. schrieb: >> bei 50 Durchfahrten wurde 3 oder 4 nicht erkannt. > > Das ist ein ziemlich hoher Verlust. Du hast vermutlich Störungen auf dem > Bus. Die sind leider nicht so leicht zu identifizieren. Durch bessere > Verdrahtung kann man das verbessern. > > Also kurze/keine Stichleitungen, korrekte Terminierung, gute > Masseführung, Schirmung... Ich denke das die situation eher folgende ist: - CAN Nachricht gesendet - die zu übertragende Variable ist LOW - Lok kommt in Lichtschranke - die zu Übertragende Variable wechselt zu High - Lok fährt aus Lichtschranke wieder auf - die Zu übertragende Variable wechselt wieder zu Low - Nächstes mal CAN senden- dementsprechend wird die Variable als Low gesendet. Das ganze passiert nur bei relativ kurzen und oder schnellen Loks. Ich will Störungen nicht ausschließen. Aber ich denke nicht das die die Hauptursache sind. Terminierung hab ich zwischen 100 und 200 Ohm an beiden Enden probiert. Den bus hab ich verkürzt so das nur die 5 Module für einen Schattenbahnof angeklemmt sind. Die einzelnen Module sind mit geschirmten D-Sub Kabeln verbunden. Auf den Modulen ist die Stichleitung möglichst kurz und die beiden Kabel sind verdrillt. Jegliche Änderung am Bus hat keine Verbesserung gebracht, zumindest soweit ich das beurteilen kann, also keine entscheidende. Die Geschwindigkeit der Loks zu verringern oder Wagon anhängen, damit die Lichtschranke länger geschlossen ist aber schon. Ich überlege gerade das das so löse Wenn Nachricht A vom richtigen Empfänger empfangen wurde, sendet dieser Empfänger eine Nachricht an die Zentrale. Diese wird dann ausgelesen und das senden beendet. Bedeutet zwar pro Nachricht eine Nachricht mehr, da ich aber ereignisabhängig sende sollte das kein Problem sein. Rein theoretisch sollen auf der Anlage später 30 Züge gleichzeitig unterwegs sein. Macht also im schlimmsten fall 60 Nachrichten nahezu gleichzeitig plus ein paar für die Beleuchtung und irgendwelche Aktionen bzw Szenerien in der Landschaft. zumal das nun der absolute theoretisch fall wäre das alle 30 Loks gleichzeitig irgendeine Aktion auslösen
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.