# Geistermeldungen bei BACNET Rferenzen mit Siemens PX



## sunny22 (22 Juli 2020)

Hallo Zusammen,

wir bauen seit einiger unsere GLT auf Siemens PX um.
Je umfangreicher das System wird, umso mehr treten sporadische Merkwürdigkeiten bei einigen BACNET Referenzen auf.
Einige Controller von zentralen Lüftungsanlagen reichen Abschaltbefehle seitens der BMA über BACNET an Controller nachgeschalteter Zonen weiter.
Die Übertragung erfolgt nicht per Polling sondern per COV.
Ganz sporadisch gehen diese Datenpunkte auf dem Client Controller immer mal wieder für eine Sekunde in Störung was dann einen Ausfall der Zone zur Folge hat.
Auf dem Controller der Hauptanlage gab es aber keine Änderung bei diesem Datenpunkt. Auch andere Zonen, welche auf den selben Datenpunkt zugreifen sind nicht betroffen.
Hat schon mal jemand ähnliche Beobachtungen gemacht?

Grüße Oliver


----------



## SPS-Bitschubser (22 Juli 2020)

Entweder dein Netzwerk ist überlastet.
Oder deine Werte ändern sich zu schnell. Was in komischen Konstellationen teilweise die Controller überlastet. 
Wie viele Abos hast du aktiv? Häufig ist hier das Problem. Analogwerte wo dauerhaft schwanken. Erzeugen ziemlich viel Trafik. Jedes große Bac-Net Netz hat ein paar Controller wo sich das als erstes zeigt. Sporadische Störungen etc.
Wie groß ist dein Netz Aus Bau ? Anzahl Controller, BAWS, BOWS.


----------



## sunny22 (22 Juli 2020)

Das Netz ist ziemlich groß insgesamt sind es mittlerweile ~180 BACNET Geräte wobei natürlich nicht alle untereinander kommunizieren. Jede Zentrale ist für sich mit einem eigenen Switch vernetzt und dann über einen Port an das zentrale Netzwerk angebunden. Daten zwischen Controllern werden meist nur innerhalb einer Zentrale ausgetauscht.
Auf dem Controller der Hauptanlage sind etwa 30 analoge und 40 binäre Datenpunkte durch 12 Controller abonniert.
Die genaue Verteilung im Netz müsste ich schätzen. 110 Controller 70 BOWS und 1 BAWS dazu noch ein SX-Open Server und eine BACNET-KNX Kopplung.


----------



## SPS-Bitschubser (22 Juli 2020)

sunny22 schrieb:


> Das Netz ist ziemlich groß insgesamt sind es mittlerweile ~180 BACNET Geräte wobei natürlich nicht alle untereinander kommunizieren. Jede Zentrale ist für sich mit einem eigenen Switch vernetzt und dann über einen Port an das zentrale Netzwerk angebunden. Daten zwischen Controllern werden meist nur innerhalb einer Zentrale ausgetauscht.
> Auf dem Controller der Hauptanlage sind etwa 30 analoge und 40 binäre Datenpunkte durch 12 Controller abonniert.
> Die genaue Verteilung im Netz müsste ich schätzen. 110 Controller 70 BOWS und 1 BAWS dazu noch ein SX-Open Server und eine BACNET-KNX Kopplung.



Ist aber alles ein Bac-Net Netz oder hast du einen bacnet device als Router eingesetzt.
Das Problem sind die ganzen WHO are etc. Welche die Bows und so weiter senden in regelmäßigen Abständen. Du kannst die erreichbaren Device für  die einzelnen Steuerungen.  Einschränken in der Konfiguration. 
Mit netzwerkuberlast ist nicht der physische Geschwindigkeit gemeint sondern eher das BAC-Net Netzwerk. Gerade bei schwachen device. 
Ein großer BacNet Controller macht weniger Probleme als viele kleine... 
Was hast du bei Temperaturen für aktualisierungswert eingestellt ? 0,1 ? Hier nie weniger als 0,25 Ventile Rückmeldung 2bis 3% usw. Die Masse aller Controller macht das Problem. Dann kommt es noch auf die Programmierung der BOWS wie sie Daten von Controller holen manche Hersteller  lesen die BACNet daten dierekt bei manchen musst man die daten importieren.
Selbst große GLT verwenden für ihre Steuerung kein bacnet sondern denn Hausbus.  Fällt  auch keinen auf da beide Geräte ja Bacnet fähig sind. Aber die komunikation läuft anders ab.
Am besten wird es sein mal das Netz untersuchen lassen. Und dann den Traffic zu optimieren.
Mbs hat so ein Tool baceye dann gehst damit online auf den controller. In den Moment überlastet du schon kurzzeitig die Controller,  da die ganze config angezeigt wird. Kurz drauf ist alles wieder oke.


----------



## GLT (24 Juli 2020)

sunny22 schrieb:


> bauen seit einiger unsere GLT auf Siemens PX um


Von welchem System aus? Welche MBE kommt zum Einsatz?
Wer projektiert/programmiert das Ganze?




sunny22 schrieb:


> Ganz sporadisch gehen diese Datenpunkte auf dem Client Controller immer  mal wieder für eine Sekunde in Störung was dann einen Ausfall der Zone  zur Folge hat.


Was sind das für Controller u. wer hat sie projektiert?
Welches Medium wird für die Anbindung verwendet bzw. befinden sich im Übertragungsweg Router?

Wenn sich ein DP nicht ändert u. somit kein COV auslöst, dann liegt es eher am "Empfänger".

COV hält die Buslast klein, allerdings muss, wie bereits erwähnt, den Auslöseschwellen der jeweiligen Werte entsprechend Aufmerksamkeit geschenkt werden.
Falls IP, ist das geshared oder exklusiv für die GLT?


----------



## sunny22 (31 Juli 2020)

Im Moment ist es noch ein Netz. Wir bereiten gerade eine Trennung in mehrere Netze vor.
Die  COV Aktualisierung steht auf 0,2. Die Temperaturen sind  Lufttemperaturen der großen Hauptanlage. Also nichts was jetzt irgendwie  dolle schwankt.
Der Umbau erfolgt von Visonik auf Siemens PX  (PXC100-E.D usw.). Die Leittechnik ist eine Desigo. Projektieren und  programmieren tut das Siemens selbst. Sowohl die Leittechnik als auch  die Controller.
Die Übertragung erfolgt über unsere zentrale IP  Netzwerk Infrastruktur. Dort nutzen wir ein virtuelles Netzwerk welches  uns unser Rechenzentrum zur Verfügung stellt.
Das nutzen wir aber nur auf der globalen Ebene und zur Anbindung an die Leittechnik 
Lokal zwischen den problematischen Controllern befindet sich immer nur ein kleiner industrial Switch.
Das Netz ist nur für die GLT. Es laufen da auch noch andere Dienste wie Profinet und die Server-Server Kommunikation.
Wir sind gerade dabei Brodcastende Geräte zu identifizieren und soweit möglich ruhig zu stellen. Mal sehen ob das was bringt.


----------



## sunny22 (31 Januar 2021)

Hallo Zusammen,
ich wollte mal noch über die Ergebnisse unserer Bemühungen berichten. 
Das interessante gleich vorweg, die Geistermeldungen sind verschwunden. 
Es lag offenbar tatsächlich an den vielen Brodcasts. Die Hauptursache dafür waren offenbar diverse Trendobjekte in den Controllern mit in der Realität nicht vorhandenen Datenpunkten. Diese Controller fragten ständig im Netz nach diesen Datenpunkten und erzeugten so eine hohe Zahl von Brodcasts im Netz.
Danke an alle die geholfen haben!
Grüße Oliver


----------

