PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Busy-Telegramme



Dieter Koch
18.06.01, 09:58
Hallo Leute


Bei dem Thema BJ RS232 schrieb Mike, daß bei ihm mal eine BJ uP-RS232 mit Busy-Telegrammen genervt hat.
Jetzt hatte ich daß gleiche Problem. Es kam aber dadurch zustande, daß ein andere Teilnehmer (Tastsensor 1-fach) abgestürzt war und seinen Objektwert zyklisch gesendet hat (ungefähr 1 Million mal/Sekunde - natürlich nicht, aber der Bus war zu, die LED der Koppler waren ständig an. Dann hat noch der entsprechende Aktor ein Rückmeldetelegramm gesendet - Das muß es dann wohl gewesen sein für die RS232.
Jetzt zu meiner Frage: In diesem Falle war es einfach den "zyklischen" Sender zu finden. Aber bei den den Busy-Telegrammen steht keine Quelladresse dabei. Wie kann ich denn nun einen Teilnehmer identifizieren, der gerade Busy's sendet?
Ich habe mich an das andere Thema erinnert und die BJ RS232 als erstes abgeklemmt - was dann auch sofort an der geringeren Busbelastung zu erkennen war. Es gibt ja (z.B von GIRA) eine RS232 mit dem FT 1.2-Protokoll. Könnte dies evtl. Abhilfe schaffen bei überlasteten Schnittstellen.
Kann ich Busy's künstlich erzeugen? Stirbt eine RS232 immer mit vielen Busy's. In meinem Fall half nichts außer austauschen geholfen.
Kann evtl. der EIB-Doctor von Schlaps helfen?
Danke für Eure Unterstützung.

Gruß aus Lehrte
Dieter Koch

Meudenbach
19.06.01, 14:12
Ja das mit den busy´s ist so ne Sache, glücklicherweise werden sie meist nur von RS232 oder Kopplern ausgelöst. Dies schränkt die Suche nach den entsprechenden Geräten stark ein (bei anderen Geräten ist mir eine deratige Verhaltensweise zumindest noch nicht aufgefallen).

Bei Kopplern ist ein busy nicht immer gleich auf ein Defekt des Gerätes zurückzuführen. Die Koppler können bei einer hohen Busbelastung oder bei Telegrammlawinen schnell mal "überlaufen" und dadurch bedingt ein, busy senden.

Bei der RS232 ist es mir bisher nur bei BJE aufgefallen (UP-Variante). Dies aber auch nur in Verbindung mit einer Hardwarekarte für eine Visualisierungssoftware. Diese Schnittstellen mußten tatsächlich ausgetauscht werden. Normalerweise sollte ein Reset den Fehler beheben.

Ein busy ist wie ein NAK oder ACK eine Quittierung. Diese Quittierung wird von einem Teilnehmer nach einem empfangenem Telegramm gesendet (Länge 1byte). Dieses Quittierungstelegramm kann somit keine weiteren Daten, wie z.B. Quelladresse = physikalische Adresse (2Byte), enthalten. Somit ist dieses Problem systembedingt an dem EIB - Übertragungsprotokoll gebunden.
Wenn aber ein geübtes Auge den Busmonitor betrachtet, kann man den Auslöser des busy´s evtl. erahnen. Hierbei muß man den vorherigen Telegrammverkehr beobachten. Man erkennt das Ziel durch die vom Sender ausgelöste Gruppenadresse. Wenn man dann weiß, welcher Teilnehmer mit dieser Gruppenadresse angesprochen werden kann, kann man die Suche schon ein wenig eingrenzen. :mad: Ist aber ein sehr mühsames verfahren.

Das FTT1.2 Protokoll betrifft lediglich den Datenaustausch zwischen AST und Applikation bzw. Gerätekomponente. Es beinhaltet zus. Überwachungsfunktionen und soll eine verbesserte Kommunikation zwischen BCU und Gerätekomponente bieten. Dies Protokoll betrifft allerdings nur BCU2 Komponenten und da die BCU2 weiterhin mit Problemen behaftet ist halte ich diesen Weg für zweifelhaft.

so, jetzt aber genung......;)

mfg

Mike

a.baurmann
30.07.01, 21:18
ein typische Problem zu hoher Buslast.

Also generell sendet das Busy immmer eine BCU (und ist damit kein Gerätedefekt) und zwar dann, wenn sie noch so beschäftigt ist, dass sie auf der untersten Ebene kein Telegram annehmen kann. Die Applikation(Gerät) ist als Verursacher sekundär.

Bekannt ist das Linenkoppler und die RS 232 hier kritisch Partner sein können, da sie eine Flaschenhals bilden. Der Linenkoppler braucht etwas mehr Zeit zur Abarbeitung, da er das empfangene Telegramme erst an eine zweite (interne) BCU weitergibt. Das dauert länger als eine einzelne BCU benötigt ihr Telgramm an z.B eine Tastsensor zu übermittelen. Solche Teilnehmer organisieren sich, dank der kurzen Übermittlungszeit und des Busprotokolls im EIB, selbst.

Der Linienkoppler hat deshalb auch einen Datenpuffer, um hier Abhilfe zu leisten. Dieser ist aber (soviel ich weiß) erst nach Laden der Filtertabelle aktiv. Da diese leider häufig nicht geladen wird, (Linienkoppler steht auf Durchzug)ensteht hier ein Problem. Auch die mehrfache Empfangsbestätigung (Wiederholung bei Datenfehlern) auf Haupt- und Unterlinie (Default) wirkt hier verschlechternd.
Durch entsprechende Parametrierung kann hier Abhilfe geschaffen werden.Es ergibt sich eine Reduzierung der Telegramme, da der sendende Teilnehmer nicht wiederholt.

Die RS 232 hat das generelle Problem, dass sie das "Handschake-Geklappere" mit dem PC noch durchführen muß. Auch dies benötigt Zeit, die man schlecht einschätzen kann, da die Interruptzeit des PC-Prozessors schwankt. Der Hersteller der RS 232 spielt keine Rolle, auch verschlechtert eine zusätzliche Hardwarekarte nicht das Problem, sondern im Gegenteil, sie schafft Abhilfe, da sie unabhängig vom PC-Prozessor, sofort antwortet.
Auch hier ist die Lösung in der Parametrierung zu suchen. Es muß (wenn z.B eine Visualisierung an der RS 232 hängt) eine Dummy-Applikation für diese gesetzt werden (hat so ziemlich jeder Hersteller auf der Datenbank). Diese bewirkt das in der Filtertabelle des Linienkopplers nur relevante Telgramme weiterläßt und nicht jeden Müll an die RS 232 sendet.Vermutlich wäre ein Busy der RS 232 ausgeblieben, da der Linienkoppler das Telegramm des Tastsensors gefiltert hätte, da ich denke, nur die Gruppenadresse der Rückmeldung ist interessantgewesen.


Aber Achtung!
Da läßt sich auch ein GAU erzeugen, wenn ein Zentral Aus gesendet wird und zig Aktoren möchten gleichzeitig über das Rückmeldeobjekt
melden. Einfacher ist es da, dem Visualisierungselement nicht die zig Rückmeldeadressen zuzuordnen, sondern gleich die eine des Zentral Aus. Ist zwar etwas mehr Arbeit bei der Projektierung, verhindert aber dem Stau im Bus, wenn viele Aktoren rückmelden wollen.

Das FT 1.2 Protokoll sichert meines Wissen die Datenübertragung zwischen PC und RS 232 etwas. Ist auch nur für die InterVisu/VTS unter Windows NT gedacht.

Ich hoffe ich konnte euch ein paar Tipps geben.

Gruß, Albert

Meudenbach
31.07.01, 09:49
Hi mein Freund,

schön dich in dieser Gemeinschaft begrüßen zu dürfen *ggg*.
Wünsch Dir nochmals alles Gute auf Deinem neuen Weg....

Bis denn

Mike

Gaston
31.07.01, 16:36
Es stimmt zwar schon dass die BCU die busies generiert aber mann soll das Geraet hier nicht unterschaetzen. Eine BCU besteht im wesentlichen aus einem hardware busankuppler der keine busies generieren kann. Ein Paket das dort empfangen wird wird von dem program im ROM der BCU entgegen genomen und dann speter an die Applikation des gerates (in der BCU) weiter gegeben. Diese applikation bearbeitet dieses Paket und spricht gegebenenfalls das angeschlossene Geraet an. Ist nun aus irgend einem Grund die Applikation nicht in der Lage das Paket schnell genug abzuarbeiten kann die BCU keine weiteren Pakete annehmen. Jedoch kann dies sehr wohl an einem defekten geraet liegen.

Auch hier kann die BCU 2 etwas Abhilfe schaffen da es sich bei dieser um eine "multi-tasking" BCU handelt und somit die Applikation und die BCU internen funktionen virtuel paralel laufen.

Ich glaube auch nicht dass ein Linienkoppler mehr Zeit mit der bearbeitung eines Pakets braucht als ein Schalter aber hier gibt eis ein anderes Problem. Ein Linienkoppler ist an zwei linien angeschlossen und jede hat ihr eigenes "Leben". Das heiss dass wenn beide Busse stark belastet sind und der Linienkoppler auf "Durchzug" steht, kann die Linienkoppler die Pakete nicht von einem Bus zum anderen uebertragen. Im extremfall sind beide Busse voll ausgelastet und somit kein transfer ueberhaupt mehr moeglich. Denn das wuerde ja (theoretisch) heissen dass auf beiden Bussen 9600 bits/Sekunde Zirkulieren. Wenn nun aber die 9600 b/sek von dem einen Bus auf den anderen Bus aufgeshaltet werden sollen dan ergaebe dies also 19200 bits/sekunde. Hier sendet der Linienkopplert dann busies.

Hier ist meiner Meinung nach die EIBA gefordert da die Busies von den Linienkopplern ueberfluessig sind.

Achtung aber bei dem Tip um das Rueckmelde objekt zu eliminieren. Die visualisierung auf ein sSchalttelegram zu legen Anstatt auf das Rueckmeldeobjekt stellyt nicht sicher dass die Anzeige akurat ist ! Dies muss man bedenken.

FT1.2 muesste einen besseren durchsatz erlauben da eine Wartezeit zwischen senden und empfangen entfaellt.

Gaston

a.baurmann
01.08.01, 18:33
Also ich bleibe dabei, bei großen Anlagen, die mit Zentralfunktionen arbeiten nicht mit Rückmeldeobjekten vorzugehen.

Einfache Rechnung:

Zentral aus für 40 Kanäle, d.h. die jeweilige Statuslampe der Visualisierung wird mit der einzelnen Rückmeldeobjekten verküpft(40 Lampen in der Visu).
Die Gruppenadresse 10/0 sendet Zentral AUS.
10 Stück der 4-fach Aktoren senden die Rückmeldung 5/0 bis 5/39 .
Schlagartig werden 41 Telegramme gesendet.

1*10/0 und 40*5/xx.

Das Schaltobjekt im Aktor wird, neben der Einzeladresse, mit der Gruppenadresse 10/0 verküpft. Ebenso die Statuslampen in der Visu.

10/0 wird gesendet....das wars. Die Aktoren schalten aus und die Visualisierung aktualisiert.

Somit 1 Telegramm bei Zentral Aus auf dem Bus.

Meudenbach
01.08.01, 23:08
Original geschrieben von a.baurmann
Also ich bleibe dabei, bei großen Anlagen, die mit Zentralfunktionen arbeiten nicht mit Rückmeldeobjekten vorzugehen.

... dem stimm ich voll und ganz zu. In Großanlagen gibt es sonst entsprechende Probleme. Das EIB - Protokoll ist extrem sicher und man kann mit an Sicherheit grenzender Wahrscheinlichkeit davon ausgehen, daß die Bustelegramme auch Ihren entsprechend Empfänger erreichen. Bei erhöter Anforderng kann man das entsprechende Objekt ja auch pollen um sich somit über den tatsächlichen Zustand des Objektes in Kenntnis zu setzen. Weiterhin erlebe ich mehr Schwächen bei den Aktoren selbst (klebende Kontakte etc.) da nützen einem auch Rückmeldungen gar nichts.

Einfache Rechnung:

Zentral aus für 40 Kanäle, d.h. die jeweilige Statuslampe der Visualisierung wird mit der einzelnen Rückmeldeobjekten verküpft(40 Lampen in der Visu).
Die Gruppenadresse 10/0 sendet Zentral AUS.
10 Stück der 4-fach Aktoren senden die Rückmeldung 5/0 bis 5/39 .
Schlagartig werden 41 Telegramme gesendet.

1*10/0 und 40*5/xx.

Das Schaltobjekt im Aktor wird, neben der Einzeladresse, mit der Gruppenadresse 10/0 verküpft. Ebenso die Statuslampen in der Visu.

10/0 wird gesendet....das wars. Die Aktoren schalten aus und die Visualisierung aktualisiert.

Bei einer Visu, die mit einem OPC - Server arbeitet werden diese Assoziationen über sog, Link - Adressen selbständig berechnet. Vorrausetzung hierfür ist das Einlesen der Gruppenadressen aus der ETS. Dann brauchen nur noch die jeweiligen Schaltadressen und nicht mehr die Übergeordneten Adressen behandelt zu werden, da dies vollständig die Datenbank des OPC - Servers übernimmt.

Somit 1 Telegramm bei Zentral Aus auf dem Bus.

Gaston
02.08.01, 15:29
Ich habe keine Ahnung wieso, aber irgendwie habe ich das gefuehl dass sich Dirk von meinem Beitrag angegriffen gefuehlt hat. "Also ich bleibe dabei..."

Meine Bemerkung mit den Rueckmeldeobjekten war ja nicht so gemeint dass Dirks Variante schlecht ist. Ich wollte nur zu bedenken geben dass bei beiden Methoden dieses passieren soll:

Zentral aus -> Alles aus -> Visu alles aus

Nun kann es aber sein dass bei Dirks Vorschlag:

Zentral Aus -> Fast alles aus -> Visu alles aus

Weil der Bus ueberlastet ist, oder ein Aktor-Buskoppler defekt ist.
In diesem Fall wird die Visu nicht akurat den Zustand anzeigen.

Ich wollte nur dies zu bedenken geben so dass jeder selbst entscheiden kann was der richtige Weg fuer seine Applikation ist.
Auf jeden Fall wenn die akurat-richtige Visualisierung nicht "Lebenswichtig" ist dann ist Dirks Vorschlag der richtige.

In disem Fall gibt es also nicht eine Musterloesung, sonder eine Wahl zwischen zei Varianten mit Vor- und Nachteilen. Wobei jeder entscheiden kann welche fuert Ihn die geeignetere ist, und es gibt kein "Ich bleibe dabei, meine Loesung ist DIE richtige."

Gruesse,
Gaston

Dirk Beyer
03.08.01, 08:39
Hallo gaston.....

irgendwas läuft schief.... Also falls Du mich meinst, so muß ich Dir zu Deinem Beitrag sagen, daß ich zu diesem Thema bisher nichts gesagt hatte und mich erst Recht nicht von Dir angegriffen fühlte...

Aber wenn hier schon reingezogen werde, dann will ich auch meinen Senf dazugeben!

1) Ich bin ein Verfechter der Rückmeldetelegramme und ein Aktor der das nicht als Option zulässt ist fehl am Platze.

2)Wer den EIB programmiert sollte sich Gedanken darum machen, wie er Zentralbefehle organisiert. Größere Anlagen haben normalerweise intelligente Kontroller, so daß ich z.B. die zentralbefehle gern in serielle Einzelbefehle (z.B. 5 Sekunden - Takt) teile.

3) Ich denke daß die Entscheidung über die Abarbeitungsstrategie genauso wie die Topologie oder sonstige Strukturen eines EIB - Systems anlagenspezifisch entschieden werden müssen...
Den "Glaubenskrieg" der hier gerade ausgetragen wird ist mir völlig unverständlich.

Dirk Beyer

Meudenbach
03.08.01, 10:58
:D letztendlich siegt doch immer die Praxis. Theoretisch läßt sich das ja alles "schönreden" jedoch wird man i.d.R schnell erkennen, daß sich das Schöngeredete schnell zum Nachteil auswirkt.

Ich schließe mich den Meinungen von Albert und Dirk vollendst an und kann nur jeden empfehlen sich mit dieser Thematik auch einmal in der Praxis auseinander zu setzen.

MfG

Mike

Gaston
03.08.01, 15:45
Zuallererst einmal muss ich mich bei Dirk entschuldigen, in meier letzten Antwort meinte ich naturlich Albert. Es ging auch nur darum dass ich klar machen wollte dass es keinen Grund gibt zu sagen (nach dem Motto) "Ich bleibe dabei, meine Loesung ist die richtige".

Glaubenskrieg ?

Also ich nicht. Denn immerhin habe ich die zweite Alternative vorgestellt und vor und nachteile beider aufgezeigt.

Ich gehe immer davon aus dass jeder hier im Forum die Intelligenz zum verstehen und waehlen besitzt und somit sollte man jedem alle Elemente geben und nicht einfach nur die persoenlich beste Loesung, denn genau diese im Regelfall beste kann in einem anderen Fall unzulaessig sein.

Shoenreden ?

War das auf mich bezogen ? Falls ja, dann lies noch einmal meine Mails, von schoenreden kann keine rede sein, oder ist mein Deutsch so schlecht ? Ich draenge niemand in eine Richtung sondern biete nur die Wahl mit Nach- und Vorteilen.

Und damit ist fuer mich das Thema erledigt.

Gruesse,
Gaston