Wago Netzwerkvariablen

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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
>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.
 
sorry - wer lesen kann ist klar im Vorteil;)

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

Anhänge

  • HomeGarage.zip
    19,1 KB · Aufrufe: 79
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)?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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 :ROFLMAO: ) ;)
 
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.:cool:
 
Zuletzt bearbeitet:
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@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
 
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
Broadcast Adresse.PNG
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.
 
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.
Unbenannt.jpg
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.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
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 ;)
 
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. :)
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Haben wir hier ja ;-)

Trotzdem interessiert es mich wie man Variablen am besten hin und her schicken kann. Deswegen sind solche Diskusionen Gold wert :)
 
@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.
 
@Santacrews

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