PFC200 und e!COCKPIT

Geschätzte Community

Nachdem nun meine Hausverkabelung und Haustechnikinstallation offiziell abgeschlossen ist, wollte ich nun meine SPS Steuerung in IP-Symcon integrieren.

Ich hatte vor längerer Zeit dies schon mal gemacht aber mit Codesys und 750-880. Offensichtlich läuft das etwas anderster mit PFC2000 und e!COCKPIT.

Nachdem ich nun gestern den ganzen Tag gelesen und herumexperimentiert habe, habe nun doch einige geistige Baustellen in meinem Kopf die mir nichts so ganz klar sind. Ich versuche das mal zusammen zu fassen.

Alls 1. Aufgabenstellung will ich über IP Symcon eine digitalen Ausgang der SPS Schalten.

grafik

Es gibt mal zwei Grundlegende Seiten: IP-Symcon und e!COCKPIT

IPSymcon
Instanz Client Socket
Hier scheint mir das eigentlich klar. Ich habe eine Instanz Client Socket eingerichtet. Diese sollte verbunden sein und funktionieren.

grafik

Ist es korrekt, dass ich die IP-Adresse der SPS nehme und nicht die vom Generic_Modbus_Slave?

Instanz Modbus TCP
Weiter habe ich eine Instanz Modbus TCP eingerichtet.

grafik

Das passt für mich im Augenblick soweit auf der Seite IPSymcon. Nächste Schritte sind im e!COCKPIT

e!COCKPIT
Hier sind für mich viele grosse Baustellen.

Merker
Ich lese von Merkern und dann wieder das es diese nicht braucht. (Früher hatte ich die Verbindung auch damit realisiert).
Mein Fazit: Es braucht in der Konstellation PFC200 und e!COCKPIT keine Merker, da Variablen im Generic Modbus Slave angelegt werden. Ist das korrekt?

Generic_Modbus_Slave
Ich muss im e!COCKPIT einen Generic_Modbus_Slave einrichten. Ist das korrekt?

grafik

Generic_Modbus_Slave IP-Adresse
Bekommt der Generich_Modbus_Slave eine eigene IP-Adresse. Ich habe da unterschiedliches gesehen.
Mein Fazit: Ja der Generic_Modbus_Slave bekommt eine eigene Adresse. Ist das korrekt?

Generische Datenpunkte
Ich habe hier eine Boolean angelegt M_DO_088_14.
Weiter folgendes:

grafik

Ich gehe davon aus, dass die Funktionscode passen. Ist das korrekt?

Hingegen bin ich mir bei den Adressen überhaupt nicht sicher. Ich habe da 15838 eingetragen und bin der Ansicht, dass dies die Adresse des Speicherabbildes ist. Ich habe aber auch gelesen, dass man hier eintragen kann, was man will.
Was ist hier richtig?

Verfügbar machen von M_DO_088_14

Ich gehe davon aus das dies so richtig ist und ich diese Variable nun aus IP Symcon schalten kann.

Instanz in IP Symcon

Nächster Schritt in e!Cockpit
SPS aktualisieren.

Problem
Ich bin der Meinung, dass ich nun M_DO_088_14 via IP Symcon schalten kann, was jedoch nicht geht.

Was ist zu tun?
DANKE

Pit

Hallo Pit,

Ich kann dir hier nicht helfen.

Verabschiede dich von eCockpit das wird nicht mehr weiterentwickelt.
Du kannst ohne Probleme auf Codesys Vers 3 kostenlos umsteigen.
Musst leider dich entsprechend informieren.
Die passenden Biliotheken für CodSys 3 bekommst Dau bei WAGO

Ciao Wibo

Danke dir für deine Antwort.
Ok , dass ist doch ne Ansage. Das wäre nämlich eine meiner nächsten Baustellen gewesen, wie es mit eCockpit weiter geht. Wollte mich deswegen heute Morgen schlau machen. Leider funktionieren die Webseiten von Wago im Moment nicht richtig.

Abere dann macht es wahrscheinlich mehr Sinn, dass ich mich zuerst um diese Baustelle kümmere.

Gruss Pit

Ich empfehle auch den Umstieg.
Ist sehr einfach, ich arbeite beruflich viel mit Wago PFC.

Ich nutze dann auch gern mqtt statt Modbus, das kann die PFC.

Mit freundlichen Grüßen

Salü Paule
Danke dir für deine Antwort.
Das wollte ich auch angehen. Habe mit viel Schweissperlen auf der Stirn FW(22) und e!Cockpit auf den aktuellen Stand gebracht.
Nun habe ich das Problem, dass ich eine PFC200 1. Generation habe und diese nicht mit Codesys 3.5 läuft.
Wahrscheinlich wird es darauf herauslaufen, dass ich eine PFC200 2. Generation kaufe.
Dann ist mein nächster Schritt diese zu tauschen. Dabei bin ich gespannt wie das funktioniert.
Der zweite Schritt ist dann diese in Symcon einzubinden. Da werde ich mich wohl zuerst etwas mit der Thematik auseinander setzen. Danke dir aber für den Hinweis mit MQTT das hatte ich nicht auf dem Radar.
Grüsse
Pit

Also ich arbeite nur mit der 2.Generation, daher wusste ich das nicht.

Das umstellen ist einfacher als man denkt. MqTT läuft auch sehr gut.
Falls du dann noch Hilfe brauchst komme gern auf mich zu.

Mit freundlichen Grüßen
Paul

Achja gleich vorne weg.
MqTT gibt es einmal direkt im wbm der PFC oder aber über die IoT-Lib die du kostenlos herunter laden kannst.

Was jetzt besser ist, da kann man sich streiten.
Die Lib macht mir aber den Eindruck, dass man dort schöner komplexere Angelegenheiten erarbeiten kann.

Ansonsten wenn du bei Modbus TCP bleiben willst kann ich das mal für dich ertesten. Habe eine PFC liegen für solche „Basteleien“.
Dann kann ich dir erklären wie du was genau umsetzt.

Danke Paule für dein Nachtrag.

Ich habe zwischenzeitlich den Kontroller auf Generation 2 gewechselt und die Software auf Codesys 3.5. Das läuft.

Wo ich jetzt genau hin will, sprich MqTT oder Modubus weiss ich noch nicht. Ich werde nun mal, etwas lesen und herumspielen.
Falls dann Fragen auftauchen, die wahrscheinlich auch auftauchen werden, bin ich dir dankbar, wenn ich dann nochmals kommen kann.

Gruss Pit

Sehr gut. Das eCockpit muss bei mir auch noch weg.

Ich würde, falls du bei Modbus bleibst nicht den Konfigurator nehmen sondern es über die Bibliothek WagoAppPlcModbus lösen.

Am besten in ST programmieren.

1 „Gefällt mir“

Ciao goifalracer
Der Wechsel, ausser das es etwas Zeitintensiv war, ging gut.

Aber alles andere ist im Moment eine grosse Baustelle. Da habe noch nicht so wirklich den Überblick über den Vor- und Nachteile der unterschiedlichen Möglichkeiten.
Gruss Pit

Ich habe jetzt auch den PFC 200 G2 hier, mal schauen wie ich das mache.
Am aktuellen PFC 8202 habe ich FW21 drauf.
Hast du wie es Wago empfiehlt die FW 22 installiert und dann auf CS 3.5 migriert?

Erstens habe ich die e!Cockpitseite alles auf den aktuellen Stand gebracht will heissen:

e!COCKPIT-Projekte müssen vor der Konvertierung in e!COCKPIT auf die neueste Version
aktualisiert werden (e!COCKPIT-Version 1.11, Firmwareversion 22 (8202), Compilerversion

Danach habe ich das Projekt im e!Cockpit abgespeichert und ein Kopie davon auf die Seite gelegt.

Von: WAGO Download Center (hoffentlich darf ich das hier posten?) habe ich das Paket CODESYS V3.5 Service Pack 19 Patch 5 heruntergeladen.

Da drin befindet sich auch die Firmware 26 für die 8212. Wichtig angeblich soll nur mit dem Pack 19 und der FW 26 die Modbusfunnktionen korrekt funktionieren.

Dann habe ich Codesys V3.5 installiert. Weiter in Codesys V3.5 habe ich die Komponenten, *.package-Dateien welche sich ebenfalls in dem zuvor heruntergeladenen Datei befinden, installiert:

  1. Klicken Sie im Register „Tools“ auf CODESYS Installer… (über das Register „Tools“
    oder über das Startmenü > „CODESYS“ > „CODESYS Installer“).
  2. Klicken Sie im unteren Bereich auf [Install File].
    Hinweis: Sie müssen in CODESYS als Administrator angemeldet sein, um diese
    Dateien installieren zu können. Ansonsten ist die Schaltfläche ausgegraut.
  3. Wählen Sie die jeweilige *.package-Datei aus und klicken Sie auf [Öffnen].

Nun habe ich die 8212 in einer „Laborumgebung“ in Betrieb genommen und die FW 26 daufgespielt. Dann habe ich die 8202 ausser Betrieb gesetzt. Der 8212 habe ich die IP-Adresse von der 8202 gegeben und ebenfalls ausser Betrieb genommen in der Laborumgebung. Dann habe ich die 8202 physisch mit der 8212 ersetzt und in Betrieb genommen.

Ich hoffe bei folgendem, dass ich das noch alles richtig aus dem Kopf zusammen bekomme.
Starten von Codesys 3.5.
Die zuvor auf die Seite gelegte Projekt Datei umbennen.
Benennen Sie nun die Dateiendung Ihres e!COCKPIT-Projektes von *.ecp in
*.project um.
Diese Datei nun öffnen in Codesys 3.5

Bei der SPS und den Modulen weist nun ein roter Kreis mit Fragzeichen darauf hin, dass die Gerätebeschreibung aktualisiert werden muss.
Achtung nicht sofort machen. Zuerst fertig lesen.
Bei den Modulen habe ich Variablennammen zugewiesen. Diese sind trotz roter Kennzeichnung sichtbar und vorhanden.

Wird nun die Gerätebeschreibung aktualisiert, ist die rote Kennzeichnung weg und das normale Modulzeichen vorhanden. Es sind aber nun die Variablennamen verschwunden.
Also wieder zurück auf Feld 1.

Rechtsclick auf den Kbus und EA-Abbild exportieren auswählen.

EA Abbild exportieren

Nun kann man alle Gerätebeschreibungen aktualisieren und danach das EA-Abbild importieren. Dann sind auch wieder alle Variblenbezeichner da.
Das funktioniert mit den Modulen auch einzeln.

ja und dann noch zur Verbindung die entsprechende IP-Adresse eintragen.

Danke für die ausführliche Antwort.
Ich wäre jetzt einfach von FW22 auf 23 gegangen und gut ist.

Was funktioniert da am Modbus nicht bei kleiner FW 26.?

Benutzt du die Modbusbibliothek oder den Konfigurator?

Was da nicht funktioniert weiss ich nicht. Ich hatte Kontakt mit Wago und man sagte mir, dass ich die FW26 verwenden soll, da dort jetzt auch die Modbusfunktionen unterstütz würden. So in etwa war die Aussage sinngemäss. Ich habe da nicht weiter nachgefragt.

Was ich verwende, dass ist eben noch die Challenge. Ich habe gefühlt vor 10 Jahren die SPS probeweise mit Codesys 2 mit Symcon verbunden. Damals habe ich das auch hingekriegt.

Im Moment habe ich einen Teil des Hauses (alt) mit Symcon und Hue, Shelly, Enocean am laufen. Ein anderer Teil (neu) wird durch die SPS versorgt. Dort habe ich mittels FUP einfache Lichtssteurungen, Dalibus und Rolladen am laufen. Nun wollte ich da Symcon „darüberstülpen“ und die beiden Installationen so zusammen bringen.

Wie ich nun die Verbindung von der SPS und Symcon mache, weiss ich noch nicht. Es gibt da ja offensichtlich auch diverse Möglichkeiten.

Modbusbibliothek oder Konfigurator und dann welche Programmiersprache.
Aber auch Paule hat die Möglichkeit der Anbindung mittels MqTT erwähnt und dort gibt es offensichtlich auch unterschiedliche Möglichkeiten.

Hier gibts es noch sehr viele Bäume und den Wald sehe ich noch nicht.

Gruss Pit

Hallo zusammen

Ich muss das Thema nochmals aufgreifen.
Ich habe eine PFC200 2. Generation und Codesys 3.5.

Nun habe ich unter Gerät eine Ethernet-Schnittestelle eingereichtet und daran einen ModbusTCP_Slave gehängt.

grafik

Über ein Client Socket kann ich offensichtlich auch eine Verbindung herstellen was auch auf dem Register Status ersichtlich ist.

Als erste möchte ich gerne einen Digitalen Ausgang der SPS schalten. Ich probiere das nun schon seit zwei Tagen und schaffte das nicht ansatzweise. Ich bekomme immer wieder Fehlermeldungen.

Früher habe ich einfach einen Merker angelegt und diesen dann über die Adresse angesprochen. Das geht nicht.

Wo und wie muss ich welche Variablen definieren damit ich sie dann ansprechen kann?

Ich habe auch schon mal versucht einen Modbus über die Bibliotheke einzurichten aber da scheitere ich schon daran die Anleitung zu lesen. Beim Doppelklick auf das PDF:

grafik

Würde mich freuen über einen Hinweis in welche Richtung ich gehen muss.

Grüsse Pit

Ich würde es nicht mit dem Konfigurator machen, ausser die hast blos 10 bis 20 Adressen.
Nachteile, feste Adressräume, Modbus ist im SPS Zyklus nicht beinflussbar.

Nimm die Bibliothek WagoAppPlcModbus.

So sieht mein ModbusPRG aus, IPS ist hier der Master.

Deklaration:

Programm:


Den WagoAppPlcModbus.FbMbSimpleServerTcp; habe ich einmal für flüchtige und einmal für nichtflüchtige Vars aufgerufen.

Hier dann eine GVL mit den Adressen:
Die können mit der Bibliothek fast frei gewählt werden, mit dem Konfigurator geht das nicht.

Die Kommentare nutze ich dazu um die Adressen zu dokumentieren, was besseres ist mir damals nicht eingefallen.

Beispiel:
awHolding_Registers_Re: ARRAY [2050…2400] OF WORD;
Bedeutet das die Registeradressen bei Adresse 2050 beginnen und bei 2400 enden.
Die sind hardcodiert, dass gibst du dann in IPS in die Instanz ein.

Falls du die Retain Vars benötigst muss du natürlich noch in die „PersistentVars“ liste eintragen.
grafik

Der Abruf erfolgt beim initialisieren im ersten Zyklus im Netzwerk 1


Hier habe ich z.B. Vorgabewerte z.B. Sollvorgaben für Rollopositionen drin.
Alternativ kannst du das auch über IPS machen indem du bei der Modbusinstanz die gleiche Lese und Schreibadresse einträgst, dann holt sich die SPS die Werte über IPS.
Das habe ich bewusst vermieden, weil meine Automatiken auch ohne IPS funktionieren sollen.
Muss jeder selber wissen.

In den PRGs kannst du dan die Variablen wie folgt ansprechen:
Beispiel mit der Adresse 2050 in FUP


Das wäre ein schreibender Zugriff vom Retain array

Lesend aus dem nicht Retain array

IPS:
Beispiel Verbindung zum Retain Array:
grafik
Achte auf den Port.
Das nicht retain Array
grafik

Beispiel Instanz mit der Adresse 2050 ansprechen.

Und wichtig, verwende das Blockweise abfragen unter Expertenopionen
Je nach Anzahl der Variablen steigt ohne Blockabfrage die Netzwerklast erheblich

Noch was wichtiges:
Da Modbus Wordweise arbeitet und du z.B. Real Werte z.B. Raumtemperatur in IPS integrieren möchtest, musst du 1x Real mit 2 Words behandeln, in der SPS muss du das Real mit einer Union in zwei Words zerlegen und in IPS in der Modbusinstanz Real auswählen und das niedrigste der beiden Wörter eintragen. Dazu kann ich dir aber noch Quellcode für Bausteine geben.

Also ziemlich viel Futter, lies dich ein das mit der Bibliothek ist super, läuft bei mir seit 5 Jahren.
Hab 3 SPSn an IPS und die kommunizieren untereinader auch noch über Modbus, hatte früher auch mal den Konfigurator, da wirdt aber nicht froh.

Uuuiii, da hast du aber viel zusammengestellt.
Danke dir!
Da werde ich wohl etwas Zeit brauchen, bis ich alles mal durchgedacht und nachvollzogen habe und da werden wahrscheinlich auch noch Fragen auftauchen.

Ich habe nun 2 Modbus Slave am laufen. Ich kann auch eine Verbindung mit IPSymcon herstellen.

Es gibt nun einen Modbus für flüchtige und nicht flüchtige Variblen. Das man in den nicht flüchtigen Variablen Einstellungen, Konfiguration speichert kann ich nachvollziehen und möchte ich auch gerne in der SPS haben aus dem gleichen Grund welchen du erwähnt hast.

Nun beginnen für mich die ersten Verständnisprobleme. Ich hatte im Kopf, dass zwischen Retain (Warmstart) und Persistent (Kaltstart) Variablen unterschieden wird.

In GVL_IP_Symcon hast einmal den Abschnitt Retain Array und normale Vars. Müsste man dann die Retain Variablen nicht als Retain Variablen konfigurieren?

VAR_GLOBAL RETAIN
       z.B. ax_Re: Array [0..0] of Bool;
END_VAR

Hier bin ich mir nicht sicher was du mit der PersistentVars Liste meinst.
Ich habe unter Application hinzufügen eine PersistenVars Liste hinzugefügt und entsprechend die Variable deklariert. Ist das so richtig?

Nun ja, mit diesen Adressen stehe ich vollständig auf dem Schlauch. Ich habe da keine Idee wo der Bezug zu meinen Modulen ist.

So wie du es jetzt gemacht hast, sollte es passen…

Ich müsste jetzt selbst nachlesen, aber bei mir ist es so:
Wenn ich ein FW Update mache sind die Vars natürlich alle auf 0, oder wenn ich auf „Alles bereinigen“ drücke sind die auch alle weg.
Aber bei Kaltstart und Warmstart sind die trotzdem noch da.

Ich glaube wenn du die extra nochmal in der POU als retain persitent deklarierst, kannst du den Instanzpfad in der Persistent Var Liste durch drücken auf „Deklarationen“ " alle Instanzpfade hinzufügen" automatisch mappen.
Ich bin mir aber nicht 100% sicher.
Vielleicht kannst du es mal ausprobieren, wenn du ja eh grad Änderungen machst!!

Noch ein Tipp:
Da du ja mir der Bibliothek arbeiteset, deklariere dir deine Adresssen gut, sonst kommt es schnell vor, dass die Adressen doppelt vergibst, hatte ich schon mal.
Da muss man aufpassen.
Geil wäre es wenn man die Adressen für IPS im Array im Klartext über eine DUT ansprechen könnte, somit müsste ,man nicht immer nachschauen, was z.b. Adresse 22289 ist?
Dafür hatte ich aber noch keinen Nerv mich mit sowas zu beschäftigen, sollte aber technisch möglich sein.
Vielleicht meldet sich hier noch ein Codesys Spezi, ich bin auch nur Hobby Tüftler:).

Randinfo

Modbus ist beeinflussbar, einfach Trigger anpassen und man kann auch gezielt die Kanäle auslesen.

Alternativ zum Union reicht es oft schon aus ein INT16 draus zu machen mit einer Kommastelle. Der Wert wird dann in Symcon einfach durch 10 geteilt