# Wago Netzwerkvariablen



## Matze001 (20 August 2010)

Aufgrund der großen Nachfrage stelle ich es auch hier rein.

Eine PDF Datei die schnell und einfach erklärt wie man mind. 2 Wago 750-841 mittels Netzvariablen verbinden kann.

MfG

Marcel


----------



## IBFS (20 August 2010)

Matze001 schrieb:


> Aufgrund der großen Nachfrage stelle ich es auch hier rein.
> Eine PDF Datei die schnell und einfach erklärt wie man mind. 2 Wago 750-841 mittels Netzvariablen verbinden kann.
> MfG
> Marcel


 
Auch  wenn ich es in absehbarer Zeit nicht brauchen werden:

Danke!


----------



## Matze001 (20 August 2010)

Dafür nicht 

Dann drück doch den "Danke"-Button 

Wenn ihr wünsche habt, ich schreibe gern solche Sachen mal fix zusammen.

MfG

Marcel


----------



## ebt'ler (21 August 2010)

Ich hab dir mal gedankt, obwohl man das auch im Codesys-Handbuch unter den Punkt "6.2 Globale Variablen, Variablenkonfiguration, Dokumentvorlage" nachlesen kann.


----------



## Wühlmaus (22 August 2010)

Nachdem auch ich dir nun ebenso pflichtschuldig wie freudig gedankt habe, traue ich mich mal, eine Frage dazu zu stellen.

Sind diese Netzwerkvariablen etwas, was nur zwei Wago's untereinander verstehen, oder kann man auf diese Größen auch anderweitig zugreifen, sagen wir mal durch ein C# oder VB.net Programm auf 'nem Lapttop (d.h. unter .NET) ? Ich plane in meiner SPS umfangreiche Daten (Messwerte, Ereignisse, Aktionen, Alarme etc.) zu sammeln und bin noch am Überlegen, wie ich die Daten am besten in den Laptop bekomme. Anfangs nur übers LAN, aber später auch mal mal über's Internet. Klar, kann man auch über Dateitransfers machen, aber es interessiert mich halt, ob's auch anders geht.


----------



## ebt'ler (24 August 2010)

Hi,

soweit ich weiß sind die Netzwerkvariablen nur für Codesys-Steuerungen. 
Wenn du via PC / Laptop zugreifen willst und die Steuerung Modbus unterstützt wäre die Verbindung mittels DLL + C# / VB / usw. möglich.

Hier ein Beispiel der Firma Wago: http://www.wago.com/wagoweb_china/public/759/ger_manu/312/m931200d.pdf


----------



## Wühlmaus (24 August 2010)

danke, werd's bei Gelegenheit mal ausprobieren und berichten. Da ich mit C# und VB nur vor 4 oder 5 Jahren mal etwas herumgespielt habe, wäre das sicher eine ganz neue Baustelle.


----------



## bastian c (17 Februar 2011)

Vielen Dank für das kleine Tutorial hat mir sehr geholfen.
Jedoch hab ich noch ne kleine Frage dazu.
Wie kann ich Überwachen ob die Kommunikation läuft?
Es gibt ja irgendwo einen Haken für Bestätigungen jedoch habe ich keine ahnung wo man diese auslesen kann, da ich im grunde keine Doku für diese Lib gefunden habe worauf diese Kommunikation basiert.
gruß


----------



## Matze001 (17 Februar 2011)

Du kannst es ganz simpel lösen indem du ein Lebensbit hin und her schickst.


Steuerung 1 invertiert das Lebensbit von Steuerung 2 und umgekehrt, passiert eine Zeit X keine Wertänderung passt irgendwas mit der Kommunikation nicht!

Grüße

Marcel


----------



## bastian c (17 Februar 2011)

jo klar das würde in jedem fall gehen
dachte aber einfach nen bit abfragen welches von ner funktion dieser lib abgegeben wird


----------



## mfreye (8 November 2014)

Danke für die Anleitung, aber ich bekomme eine Meldung siehe Anhang.

Wie muss ich das einbinden? Finde keine Möglichkeit.

Das Projekt habe ich mal mit hoch geladen.

Danke für die Hilfe.

Maik


----------



## wolfi-sps (9 November 2014)

Hallo Matze001,

Deine Beschreibung ist sehr gut erklärt.
nur eins fehlt noch - Auf Seite zwei bei  " Einstellungen " muss noch der Port i.d.R. 1202 und die IP angegeben werden. Immer die Gegenstelle.
Ich verwende auch Netzwerkvariablen bei meinen Steuerungen - allerdings habe ich "schreiben" und "lesen" getrennt. Ist aber   Geschmacksache .

wolfi-sps


----------



## mfreye (9 November 2014)

Eine IP brauche ich doch nicht angeben. Wenn ich 255.255.255.255 einstelle, dann lauschen doch alle SPS. Die IP gebe ich nur fest an, wenn ich eine bestimme SPS ansprechen möchte.

mmmh wolfi-sps weiter helfen kannst Du mir auch nicht?

oder hast Du ein Beispielprojekt, welches ich mir mal ansehen kann. Es schein bei Dir ja zu laufen.


----------



## gravieren (9 November 2014)

mfreye schrieb:


> Eine IP brauche ich doch nicht angeben. Wenn ich 255.255.255.255 einstelle, dann lauschen doch alle SPS.


Bei mir ist 255.255.255.0  eingestellt.
Da kann ich mich so um die 254  SPSen unterhalten.

Bei 255.255.255.255   dachte ich immer mit 0   SPSen   ?


----------



## mfreye (9 November 2014)

Ok, das verstehe ich.

Aber leider komme ich nicht weiter, so lange meine Frage oben noch offen ist. Ich kann mich so ja nicht ein loggen.

Gruß


----------



## Nost (9 November 2014)

Wenn die ip nicht eingestellt ist sorgt die sps in netzwerken fuer massiven traffic.Von daher ist das zielgerichtete lesen und schreiben zu empfehlen.


----------



## mfreye (9 November 2014)

Hat keiner einer Idee bzgl. der Fehlermeldung?


----------



## wolfi-sps (9 November 2014)

Hallo mfreye,

habe mal meine Einstellungen rauskopiert.
siehe PDF


----------



## mfreye (9 November 2014)

Danke. Habe ich auch so eingestellt, halt nur mit einer anderen IP.

Beide SPS melden den gleichen Fehler beim versuch sich einzuloggen.
Kann jemand die Fehlerbeschreibung den deuten?


----------



## wolfi-sps (9 November 2014)

Welcher Fehler kommt denn??


----------



## mfreye (9 November 2014)

siehe Beitrag 11 von mir.


----------



## wolfi-sps (9 November 2014)

nur mal ne Frage - wieso rufst Du das PLC_PRG in einem Task auf??? Brauchst Du doch nicht!
In Deinem Beitrag 11 sehe ich aber keine Fehlermeldung.


----------



## mfreye (9 November 2014)

>nur mal ne Frage - wieso rufst Du das PLC_PRG in einem Task auf??? Brauchst Du doch nicht!
-->wie denn dann?

>In Deinem Beitrag 11 sehe ich aber keine Fehlermeldung.
-->Im Meldungfenster unten, die markierte Zeile. In der angehängten Grafik.


----------



## wolfi-sps (9 November 2014)

sorry - wer lesen kann ist klar im Vorteil

Hab mal kurz umgeschrieben - LIB´s und IP vom Controller habe ich nicht eingebunden.


----------



## mfreye (9 November 2014)

Danke, jetzt geht es. Lag am Taskaufruf den ich gemacht habe.

Aber warum muss ich das Programm nicht im Task aufrufen (läuft PLC_PRG automatisch)?


----------



## wolfi-sps (9 November 2014)

Hallo mfreye,

Das PLC_PRG läuft immer. In dem rufst Du alle anderen PRG´s auf - außer Du hast ein PRG wo Du nur ausführen willst wenn ein Ereignis usw. auftritt.
Ein Tipp noch: Trenne die Netzwerk Var`s von lesen und schreiben - Habe selber 3 Steuerungen (kommt noch eine für eine Solaranlage dazu) und 1 Panel im Haus. Wenn Du die trennst ist es übersichtlicher.
Vor allem wenn Du nachrüstest - das passiert immer - man hat immer neue Ideen (oder Pfürze im Hirn  )


----------



## Münchnerjunge (9 März 2017)

Liebe Community,

kann mir jemand sagen, ob der Austausch auch zwischen zwei 750-880 funktioniert? Habe das entsprechende konfiguriert, bekomme aber keinen Austausch hin.

Weiß jmd. ob die 880er das überhaupt unterstützen?

!!!!___________________________________________________________!!!!



Antwort:  Ja klar, das geht. Man muss es nur richtig machen, und dann findet der Datenaustausch statt.


----------



## Rewe2000 (9 März 2017)

Hallo,

zum Thema Netzwerkvariablen möchte ich auch noch kurz meinen "Senf" dazugeben. Ich betreue bei uns im Betrieb mehrere 750-880, 750-849, und 758-876/000-111 IPC, welche größtenteils die Informationen untereinander über CodeSys Netzwerkvariablen austauschen.

Da der Austausch hier über UDP efolgt (ohne Bestätigung, Quittierung oder Prüfung) sendet die eine Seite, ohne wirklich geprüft zu haben, ob die Empfängerseite die Änderung auch mitbekommen hat. Auch müssen immer alle Controller zwingend neu übersetzt und neu geladen werden, wenn an einem Controller an den Netzwerkvariablen etwas geändert wird und andere Controller diese Variablen lesen. Dies ist bei einem Verbund von mehr als 10 Controllern schon ein wenig Zeitafwändig. Ohne Zyklisches senden kann es schon mal vorkommen, dass Sender und Empfänger unterschiedliche Variablenzustände aufweisen, besonders wenn in der Netzwerkvariablentabelle nur Binärwerte enthalten sind, welche sich nur sehr wenig ändern.

Nicht umsonst werden diese vonn Wago nur unterstützt, weil sie in CodeSysy enthalten sind, eine Emfehlung diese zu verwenden habe ich noch nie bekommen. Das Problem hier liegt eindeutig nicht bei WAGO sondern in der unsicheren UDP Kommunikation.

Für den sicheren Variablenaustausch unter den Controllern würde ich zukünftig nur auf MODBUS setzten, hier sind mir keinerlei Nachteile bekannt.
Will man wegen der Einfachheit unbedingt Netzwerkvariablen verwenden, so würde ich zwingend zusätzlich noch den zyklischen Datenaustausch mit aktivieren. Somit werden wenigstens die Tabelle in regelmäßigen Abständen neu gesendet und die Change ist deutlich größer, dass diese beim Empfänger auch korrekt ankommen.

Gruß Reinhard


----------



## Kayle (29 April 2017)

Rewe2000 schrieb:


> Für den sicheren Variablenaustausch unter den Controllern würde ich zukünftig nur auf MODBUS setzten, hier sind mir keinerlei Nachteile bekannt.



Hallo Reinhard,

wie überträgst Du mit Modbus Strings? Ich habe z.B. das Problem das ich mehrere Strings wie z.B. Uhrzeiten, Meldetexte usw. übertragen muss. Da bieten sich Netzwerkvariablen halt an. Für "einfache" IO oder auch INT oder REAL gebe ich Dir recht, hier ist MODBUS ein bewährtes Protokoll.

Gruß Kay


----------



## Rewe2000 (1 Mai 2017)

Hallo Kayle,

da hast du Recht, mit Stringvariablen wird es bei MODBUS schwierig, ich denk dies geht überhaupt nicht. 
Aber wenn eine Sichere Übertragung gewünscht wird, solltest du nicht unbedingt auf Netzwerkvariablen setzen.

Wenn es denn sein muss, so würde ich unbedingt den Hacken beim zyklischen Senden zusätzlich noch empfehlen, die Zeit hierfür kann ja auf eine Minute gestellt werden, damit die Datenlast nicht ins unermessliche geht. 

Gruß Reinhard


----------



## santacrews (8 Mai 2017)

Noch ein Nachtrag von mir:

Modbus UDP ist genau so unsicher wie Netzwerkvariablen. Wenn eine gesicherte Datenübertragung gewünscht ist, dann muss hier Modbus *TCP *gewählt werden (Modbus ist nicht gleich Modbus).
Und was die Netzlast betrifft, hier sind die Netzwerkvariablen ein richtig fetter Klotz, da diese als Broadcast ins Netz gestreut werden und somit an jeden Ethernet Teilnehmer am Netz gelangen.


----------



## Tiktal (8 Mai 2017)

@Santacrews: Danke für den Hinweis.Allerdings kann man die Netzwerkvariablen doch auch einer IP-Adresse zuweisen. Dann sollte es doch nicht ganz so schlimm mit dem Netzwerkmüll sein?!

Gruß

Onno


----------



## santacrews (8 Mai 2017)

Hallo Onno,

das müsste funktionieren. Jedoch steht da, wo man die IP Adresse einstellen kann "Broadcast Adresse". Das macht mich dann an der Stelle etwas stutzig


Aber sollte wie gesagt vermutlich funktionieren, hab ich allerdings noch nicht ausprobiert.
Hast Du das mal ausprobiert? Wäre interessant zu wissen!

Bei mehreren Controllern müsste man dann weitere Netzwerkverbindungen hinzufügen.


----------



## Tiktal (8 Mai 2017)

Probiert hab ich das noch nicht.
Hab das mal irgendwo gelsen als ich mich etwas in die Thematik eingelesen hab.
Bin wirklich nicht sattelfest in der Materie.
Hab Dir mal einen Ausschnitt aus einer PDf angehangen. Das müsste das sein.


Ich such aber nochmal weiter.

Nachtrag: in unserem Gebäudenetzwerk wurde ein Controller so eingebunden. Dieser schreibt an eine bestimmte die Werte eine Energiemessklemme. Funktionieren tuts also. Kann allerdings nicht sagen ob das das Netz "sauberer" hält.


----------



## Morymmus (8 Mai 2017)

Hallo,

so ganz schlüssig ist das mit der Adresse für mich nicht.
Die Standard-Adresse 255.255.255.255 funktioniert demnach wie eine Subnetzmaske mit umgekehrter Logik. D.h. die 255 gibt die Anzahl der möglichen Teilnehmer an und sperrt den Wert nicht wie bei einer Subnetzmaske. Eine Kommunikation zwischen nur zwei Teilnehmern wäre also nach dem Textschnipsel von oben nur zwischen den Adressen 1.1.1.1 und 1.1.1.2 möglich.
Daher denke ich nicht, das sich der Broadcast-Traffic damit in der Praxis massiv eindämmen lässt.

Ich habe früher bei Anlagen Netzwerkvariablen auf Eaton-Steuerungen eingesetzt - mit eigenem Switch im Schaltschrank. Mussten diese doch einmal ans Firmennetzwerk, so habe ich mit der IT noch einen entsprechenden Router in den Schaltschrank eingebaut. 
Die ersten Versuche, mit zwölf Teilnehmern über das Standard-Büro-LAN zu kommunizieren fanden die Kollegen gar nicht mal so witzig


----------



## Tiktal (8 Mai 2017)

Bin selber nicht die Netzwerk-Leuchte, deswegen interessiert mich schon sehr die Meinung der Leute die es besser wissen.
Ich möchte nämlich auch irgendwann mal unsere Firmen-GLT neu machen. 
Bisher sind das 14x 750-881 die über Netzwerkvariablen die Sachen "wild streuen". Es funktioniert und bisher hat die IT nicht gemeckert, es geht aber auch besser.


----------



## Morymmus (8 Mai 2017)

Wenn Du die Möglichkeit hast, bau Dir für die GLT ein eigenes Netzwerk auf. Ohne jetzt in eine Grundsatzdiskussion abgleiten zu wollen hier kurz das Konzept, das ich in meiner alten Firma umgesetzt hatte:

Produktion:
Selbstgebaute Maschienen mit autarkem lokal-LAN (wie oben schon mal beschrieben), wenn Vernetzung nötig über Router ins Produktionsnetzwerk, 50-60 Teilnehmer 

Prüffeld:
Selbstgebaute Prüfanlagen mit autarkem lokal-LAN (wie oben schon mal beschrieben), wenn Vernetzung nötig über Router ins Prüffeldnetzwerk, 20 Teilnehmer die Messdaten zu einer übergeordenten Aufzeichnungseinheit pollen - alle 10 sek 15-30 Prüflinge, jeweils 4 REAL-Messwerte pro Prüfling.

Büro:
Büroarbeitsplätze mit den üblichen Teilnehmern: Rechner, Laptops, Drucker, NSA, Telefonanlage, Tablets, Router zum Internet, Mobiltelefone - Teilnehmerzahl unbekannt

GLT:
Eigenes Netzwerk für die Teilnehmer

Diese vier Netzwerke sind komplett von einander getrennt und können daher den Anforderungen entsprechend USV-gepuffert und abgesichert werden. Wir hatten damals einen Farb-Standard für die LAN-Kabel (z.B. GLT in Blau, Fertigung in Rot) eingeführt, so daß man direkt sieht, in welchem Netzwerk man sich befindet. Ist zugegeben ein etwas erhöhter Aufwand, aber unser Geschäftsführer war ein strikter Vertreter der Ansicht, die Fertigung nicht von zuhause erreichbar zu machen.



Das alles in enger Zusammenarbeit/Planung mit der IT - hat richtig gut funktioniert.


----------



## Tiktal (8 Mai 2017)

Haben wir hier ja ;-)

Trotzdem interessiert es mich wie man Variablen am besten hin und her schicken kann. Deswegen sind solche Diskusionen Gold wert


----------



## santacrews (8 Mai 2017)

@Morymmus

.255 ist ein sonderfall und beschreibt immer die  Broadcast Adresse des Netzes. Ich kann zum Beispiel einem  Netzwerkteilnehmer nicht die 192.168.10.255 zuweisen, da die 255 per  Definition für den Broadcast reserviert ist. Ich kann etwas an  192.168.10.255 senden, dann empfangen es alle Teilnehmer, die am Subnetz  192.168.10.xxx angeschlossen sind. 
Im Falle Wago, wo die Broadcast  Adresse 255.255.255.255 lautet, werden damit rein theoretisch brutal alle 4,x  Milliarden Adressen angesprochen. Sprich, hier wird absolut  Subnetzübergreifend gestreut. Man könnte die Wagos in ein Subnetz von z.B. 192.168.20.xxx packen und die Broadcast Adresse auf 192.168.20.255 stellen. Dann wären alle anderen Teilnehmer im Unternehmen, die nicht im Subnetz 192.168.20.xxx liegen außen vor. Der Broadcast wird also von theoretischen 4,3 Milliarden auf theoretische 255 begrenzt.
Wenn Du es so wie in dem Bild von Tiktal machst, so hast Du keinen Broadcast mehr sondern einen Unicast. Das ist die Datenmüll freundlichste Variante.


----------



## Morymmus (8 Mai 2017)

@Santacrews

Danke, das macht absolut Sinn - ich muss aber gestehen, das ich das aus dem oben gezeigten Text so nicht herausgelesen habe.


----------



## Tiktal (9 Mai 2017)

Kann man das denn irgendwie testen, welche Variante das Netz nicht so "zumüllt" bzw. irgendwie darstellen? 
Sonst sind es ja nur Vermutungen...


----------



## santacrews (9 Mai 2017)

Mit Wireshark kann man dem ganzen ganz gut auf den Grund gehen.


----------

