Hallo, Ich übertrage meine Daten per RS485 von Master nach Slave und umgekehrt. Wenn jetzt vom Slave aktuelle Daten zum Master gesendet worden sind, kurz eine Rückmeldung, Master hat verstanden oder unnötig? Wenn nicht verstanden, bitte Slave sende erneut. vielen Dank im Voraus schönen Abend
Kommt drauf an, wie sicher die Verbindung ist und wie schlimm Datenverlust ist. Wenn es wichtig ist, dass die Daten richtig ankommen, sollte man sowas machen, sonst kann man sich das sparen.
Hallo, Der Slave setzt nur "einmal" das Paket ab. Danach killt er den Event bis zum nächsten Event. Nachtrag: Verbindung ist seht stabil, soweit ich das nachvollziehen kann. schönen Abend
Bei einem Master Slave System macht man's ueblicherweise umgekehrt. Der Slave macht nichts von selbst. Der Master sendet eine Arfrage oder ein Command. Der Slave antwortet immer. zB mit Daten, oder mit einem ACK. Wenn der Master nicht versteht, macht der Master einen Retry. Wenn der Slave nicht versteht antwortet er nicht und der Master macht auch einen Retry.
Nartürlich, der Slave antwortet erst auf Kommando vom Master. Nur wenn der Master den Slave nicht verstanden hat, und dann?
Siegfried S. schrieb: > Nur wenn der Master den Slave nicht verstanden hat, und dann? Nochmal Kommando senden - oder ein NACK, wenn dein Slave sowas versteht.
Siegfried S. schrieb: > Nur wenn der Master den Slave nicht verstanden hat, und dann? Dann wiederholt der Master die Anfrage, oder nimmt nach einer gewissen Anzahl von Wiederholungen den Slave in seine "Gestört"-Liste auf.
Das Protokoll muss natuerlich zustandsfrei sin, sonst geht's schief... Was nicht geht ist "GetNexRecord", weil das einen impliziten Index weiterzaehlt. Die bessere Loesung hier ist GetRecord(i). Das Erste darf man nicht wiederholen, das Zweite schon.
Siegfried S. schrieb: > Wenn nicht verstanden, bitte Slave sende erneut. Logisches Problem: woher weiss dann der Master, dass das eine Eventmeldung war, und von welchem Slave? Eigentlich kann nur der Slave von sich aus wiederholen, wenn er keine Bestätigung bekommt. Dazu muss also der Master nichts tun. Ob so ein Multimaster-Konzept die beste Lösung ist ist eine ganz andere Frage. Georg
Bei einem Master Slave System kommuniziert ein Master im einfachen Fall nur mit einem Slave aufs Mal. Die Meldung ist Adressiert, alle Slave horchen mit und nur der Adressierte antwortet. Wenn er's denn verstanden hat. Und sonst nicht. Die Befehle muesen so aufgebaut sein, dass sie keine Laufzeit beanspruchen. Das bedeutet Prozess werden gestartet, und spaeter ausgelesen. Dh benoetigen 2 commands. Falls man allen Befehlen eine Laufzeit zubilligt.. kann man machen. Wuerd man's so machen : Master Slave SpannungMessen ACK GibSpannung 2.123 So koennte man auch mehrere Befehle "draussen" haben, bei verschiedenen Slaves. Die Verwaltung wird dann etwas aufwendiger.
georg schrieb: > Logisches Problem: woher weiss dann der Master, dass das eine > Eventmeldung war, und von welchem Slave? Mehrere Slaves? Und wieso Eventmeldung? Entweder ein Slave antwortet auf eine Frage, oder halt soundso lange nicht. Dann wird die Frage wiederholt. Wenn die Info vom Slave (oder von allen Slaves) da ist, dann ggf. die nächste Frage > Eigentlich kann nur der Slave von sich aus wiederholen, wenn er keine > Bestätigung bekommt. Dazu muss also der Master nichts tun. Einfacher ist es, wenn ein Slave nur auf Anfrage antwortet, ggf. auf ein dediziertes NACK. Gerade bei mehreren Slaves müsste sonst auch noch die Antwort des Master vom Slave bestätigt werden, sonst sendet der munter weiter, weil er das ACK nicht gehört hat...
Hallo, ist doch ganz einfach, Chef ruft Azubi an, der antwortet nicht, dann muß Chef es nochmals probieren. schönen Abend
Siegfried S. schrieb: > Chef ruft Azubi an, der antwortet nicht, dann muß Chef es nochmals > probieren. Äh, ... wollte in diesem Deinem Beispiel der Azubi nicht von sich aus nochmal den Chef anrufen? I
Achim S. schrieb: > Mehrere Slaves? > Und wieso Eventmeldung? Entweder ein Slave antwortet auf eine Frage, > oder halt soundso lange nicht Siegfried S. schrieb: > Der Slave setzt nur "einmal" das Paket ab. > Danach killt er den Event bis zum nächsten Event. Hört sich so an, als ob der Slave von sich aus den Master anspricht, sonst wäre es ja kein Event. Aber wahrscheinlich kann der TO das nicht nur nicht eindeutig formulieren, vermutlich hat er den Unterschied überhaupt nicht verstanden. Achim S. schrieb: > Einfacher ist es, wenn ein Slave nur auf Anfrage antwortet Wo du recht hast hast du recht, dann muss der Master auf angeforderte und richtig empfangene Daten ja nicht mehr antworten, der Fall ist erledigt, wenn nicht fordert er eben die Daten neu an. So mache ich das auch. Aber: Siegfried S. schrieb: > Chef ruft Azubi an, der antwortet nicht, dann muß Chef es nochmals > probieren. Vorher ist mehr oder weniger deutlich davon die Rede, dass der Azubi den Chef anruft (siehe Achim). Da ist wohl alles durcheinander, Master-Slave und Multimaster. Ich werfe daher das Handtuch. Georg
Wenn der Slave einen Event rausplaerren soll, sind wir beim Multimaster Betrieb. Der ist sehr viel schwieriger zu implementieren, speziell wenn die Hardware dies nicht unterstuetzt. Und RS485 unterstuetzt es nicht. RS485 ist Richtungsumgeschaltet. Bedeutet alle Empfangen, ausser derwelche, der sendet. Woher weiss derwelche der sendet, dass er senden darf ? Wenn zwei senden gehen die Packete verloren. Dazu gibt es zwei Ansaetze : Probieren und Retry, und Tokenpassing. Das Zweite performt besser bei hoher Buslast, sollte aber per Hardware implementiert sein. Also bleib beim Master-Slave, wo nur der Master senden darf, und der Slave nur antworten darf. Falls Events gewuenscht werden, muss der Master die Slaves eben zyklisch abfragen. Was fuer eine Antwortzeit, resp Event-Responsetime ist denn gewuenscht ? Wie schnell muss ein Event propagieren ?
Zwölf M. schrieb: > Also bleib beim Master-Slave, wo nur der Master senden darf, und der > Slave nur antworten darf. Falls RS485 gesetzt ist, ist dies der beste Ratschlag. Multimaster unter RS485 ist zwar grundsätzlich möglich - dafür sind aber viel Wissen und Erfahrungen in solche Systemen von Nöten. Die Ausgangsfrage zeigt eher das Gegenteil an. Falls die RS485 Verbindung zur Diskussion steht, wäre CAN eine nachdenkenswerte Alternative.
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.