MODBUS-Master-Konfigurator, Generischer Slave, Generische Variablen nicht änderbar

[Thruser]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

das sehe ich mir tagsüber genauer an. Das Hauptproblem auf dem ersten Blick ist die Konfiguration der Node Red Knoten.

Begriffserklärung:
Master == Client
Slave == Server

Master und Slave sind sehr verbreitet im Automatisierungsumfeld, bei Modbus wird standardmäßig aber Client und Server verwendet.

Du hast also auch die Node Red Knoten als Master (client) konfiguriert.

Gruß

 

[tomrey]

Du hast also auch die Node Red Knoten als Master (client) konfiguriert.

Aha, soso, das ist mir nichtbewußt, denn ich bin ja vom Wago Modbus-Master-Konfigurator ausgegangen und damit war die Rollenverteilung für mich eigentlich klar:
Wago=Master, Rest=slaves.
Schaun wir mal, was Du sonst noch rausbringst - DANKE!

 

[tomrey]

Zuviel Werbung?
-> Hier kostenlos registrieren

Zwischendurch nachgefragt:
Kann es sein, daß ein Modbus-slave, also der "Server" gar keine Abfragen beim master machen kann, sondern immer nur auf Abfragen des masters antwortet?
Dann müsste ich ja die Wago als slave konfigurieren und node-red als master lassen?
Damit würde der Wago Modbus-Master-Konfigurator überflüssig und ich müsste in Codesys wohl mit irgendeinem slave FB arbeiten - richtig?
Wenn ja, wie muss ich dann meine Variablen aus den PRG nach Modbus bekannt machen?

 

[Tobsucht]

Ja, ein Server wartet auf eine Anfrage eines Clients und antwortet darauf.

Für den Slave auf dem 889 brauchst Du keinen Baustein.
Du kannst Variablen in der Steuerungskonfiguration unter Fieldbus Variables anlegen.

Die Modbusadressen ergeben sich aus der Speicheradresse. Das Handbuch hilft.

Grüße

 

[holgermaik]

Hallo
dein Konzept stimmt so nicht.
Wenn ich mir deine Anforderung so durchlese würde ich folgende Konfiguration empfehlen:
Die Wago wird der Server. Das bedeutet hier musst du nur die Variablen veröffentlichen. Den eigendlichen Server bringt die Wago schon mit und er braucht nicht programmiert werden.
Hier würde %MW0 dann der Adresse 12288 entsprechen für Datentyp Word
IM Beitrag #21 Wago 750-881 Modbus TCP Anfängerfragen ist eine schöne Tabelle verlinkt mit den Adressen.
Deine beiden anderen Teilnehmer werden Client und greifen nach Bedarf auf die Wago zu. So hälst du auch den Datenverkehr in Grenzen.
Die uID wird bei Server - Client nicht ausgewertet.

Holger

PS.
Um Missverständnisse zu vermeiden.
Von Master - Slave spricht man bei einer seriellen Übertragung. z.B. Modbus RTU - der Master sendet eine Anfrage und der Slave antwortet
Server - Client ist Ethernet TCP oder UDP - der Server stellt die Daten bereit und der Client kann sie abholen oder auch nicht.

Das Verwechseln bringt immer wieder Probleme. Ich persöhnlich finde auch die Bezeichnung im Konfigurator ungünstig gewählt.

 

[tomrey]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vielen Dank Euch beiden, ich sehe Licht am Ende des Tunnels...!
Ich habe noch ein paar Detailfragen zur konkreten Umsetzung:

Was ist der Unterschied für die Benutzung zwischen den PFC- und den Merkervariablen?

Wo/wie deklariere ich die Modbus-Variablen am Besten:
- Ergänzung der bisherigen Deklarationen meiner Vars in den diversen PRG/FB?
- neue Liste in Global (analog Netvars)?
-Steuerungskonfig/Hardware? Dort sind wohl die Fieldbus=PFC und Flag=Merker - richtig? Wenn ich diese Variante nutzen würde, müsste die Deklarationen aller meiner bestehenden Vars neu machen oder Modbus-Vars zusätzlich deklarieren und dann "Umfüllen" - stimmt das so?

Ich habe bei dieser Slave/Server-Konfig nirgends die Möglichkeit gefunden "optimiert" auszuwählen um das "Umfüllen" meiner bestehenden in neue Modbus-Register für z.B. F16 zu sparen.
Gibt es das nur bei Wago=Master?

Gibt es die Möglichkeit (welche FC23?) eine große gemeinsame Modbus-STRU anzulegen, die von allen Visu-Masters sowohl beschrieben als auch gelesen werden kann? Das Risiko gleichzeitigen Zugriffs sehe ich nicht. In der Steuerungskonfig kann ich kein ARRAY deklarieren geschweigen denn eine STRU...? Müsste ich das ARRAY of STRU im PRG aus/in DWORDS auf- und zudröseln?
LG

 

[holgermaik]

Was ist der Unterschied für die Benutzung zwischen den PFC- und den Merkervariablen?

Temperatur_Eingangsword AT %IW0:WORD;
Temperatur_Merkerword AT %MW0:WORD;
Temperatur_Merkerword:= Temperatur_Eingangsword;

Mal am Beispiel einer Temperaturmesskarte
Temperatur_Eingangsword - wäre ein Inputregister (3x0000)
Temperatur_Merkerword - ware ein Holdingregister (4x0000)
Ob du das Temperatur_Eingangsword jetzt im Programm, in einer Globalen Variablenliste oder direkt in der Steuerungskonfig deklarierst macht technisch gesehen hier kein Unterschied. Die Vor und Nachteile liegen in der Hardware (wenn was dazu kommt oder wegfällt)

Wo/wie deklariere ich die Modbus-Variablen am Besten:
..- neue Liste in Global (analog Netvars)?

Ich persöhnlich würde eine neue globale Liste anlegen und umfüllen. Das hat den Vorteil das du genau weist welche Variable in welchem Datenword steckt. Das ist aber Geschmackssache. Du kannst auch deinen bestehenden Variablen die im Programm verstreut liegen den Zusatz AT %MWxx verpassen. Dabei verliert man allerdings bei vielen Variablen schnell den Überblick. Technisch gesehen macht das keinen Unterschied.

Ich habe bei dieser Slave/Server-Konfig nirgends die Möglichkeit gefunden "optimiert" auszuwählen um das "Umfüllen" meiner bestehenden in neue Modbus-Register für z.B. F16 zu sparen.
Gibt es das nur bei Wago=Master?

Das ist Sache des Client wie der die Variablen abfragt. Der Server antwortet nur. Wenn der Client einen Block abfragt antwortet der Server auch mit einem Block. Wenn der Client einzelne Var abfragt antwortet der Server auch einzeln.

Gibt es die Möglichkeit (welche FC23?) eine große gemeinsame Modbus-STRU anzulegen, die von allen Visu-Masters sowohl beschrieben als auch gelesen werden kann? Das Risiko gleichzeitigen Zugriffs sehe ich nicht. In der Steuerungskonfig kann ich kein ARRAY deklarieren geschweigen denn eine STRU...? Müsste ich das ARRAY of STRU im PRG aus/in DWORDS auf- und zudröseln?

Diese Möglichkeit besteht. Da aber Codesys 2.3 keine Union beherscht ist Handarbeit angesagt und rechnen.

TYPE Modbus :
STRUCT
    Word1:WORD;
    Byte1:BYTE;
    Fuellbyte:BYTE;
END_STRUCT
END_TYPE

VAR_GLOBAL
    Modbusvariablen AT %MW0:Modbus;
END_VAR

    Modbusvariablen.Word1 := meinWord;
    Modbusvariablen.Byte1 := meinByte;

Bei der Structur darauf achten, dass du immer ein komplettes Word zusammenbekommst -> siehe Füllbyte
Bei dem Beispiel wäre jetzt Word1 das Word0, Byte1 das Word1...
Das ganze lässt sich dann auch in ein Array verpacken.
Holger

 

[tomrey]

Hallo Tobsucht und holgermaik,
es ist geschafft, Modbus läuft sowohl vom Linux-Server lokal als auch vom win7 laptop per VPN.
Ganz herzlichen Dank, ohne Euch hätte ich das nicht geschafft!
@holgermaik:
Danke auch für die Detailerklärungen, den Unterschied zwischen Merkern und PFC bzw. input und holding Registern habe ich nicht verstanden. Wann nutzt man was?
Ich habe Testvars beider Art ausprobiert, gehen beide.
Zur Deklaration nutze ich momentan die Steuerungskonfiguration, werde aber vermutlich Deinem Vorschlag folgen und eine separate Globalenliste machen.
Nebenher habe ich eine EXCEL-Tabelle für die Speicheradressen.
Dabei habe fand ich es heute seltsam, daß die Adressen bei einzelnen Bitvars trotz 8 zu 1 genauso weiterlaufen wie bei Words.
Da muß ich noch ein wenig forschen.
Das Thema FC23 hat sich insofern erledigt als node-red das nicht kann.
Wünsche allerseits ein sonniges Wochenende!

 

[tomrey]

Zuviel Werbung?
-> Hier kostenlos registrieren

So, nach weiteren Tests brauche ich nochmal Unterstützung beim Ver- und Entpacken von Bool-Vars in WORD, falls jemand damit Erfahrung hat auch auf der node-red-Seite:
In der Steuerungskonfiguration bearbeite ich die bit-Kanäle, die ich ja dan einzeln im PRG ansprechen kann. Wie sieht das mit einem ankommenden WORD aus, wie wird das aufgeteilt?
WORD_TO_BOOL macht das wohl nur für das erste bool..
Auf der node-red Seite genau umgekehrt: Für das Entpacken habe ich einen node gefunden (Digital Input aus node-red-contrib-remote-io) aber fürs Packen vor dem Rücksenden an die 889 habe ich nix gefunden.
Habe ich den Unterschied zwischen Merkern und PFC bzw. input und holding Registern richtig so verstanden, daß PFC entweder les- oder schreibbar sind, die Merker dagegen les- und schreibbar?
Grüße

 

[holgermaik]

daß PFC entweder les- oder schreibbar sind

Eine PFC Variable bezieht sich ja direkt auf die Hardware. Wenn du also eine Eingangskarte hast kannst du diese nur lesen. Ein Merker(word) kannst du lesen & schreiben.

Zum Packen auf der Codesys Seite

WordVar.0 - Bit0
WordVar.15 - Bit 15
WordVar.B0 - Byte 0
WordVarB1 - Byte 1

Ist sowohl les- als auch schreibbar.
Zu NodeRed kann ich leider nichts sagen

 

[tomrey]

Eine PFC Variable bezieht sich ja direkt auf die Hardware.

Das verstehe ich nicht, ich denke das ist lt. Steuerungskonfig doch ein eigener Feldbus-Variablenbereich...?

 

[holgermaik]

Zuviel Werbung?
-> Hier kostenlos registrieren

Von PFC Variablen spricht Wago immer bei direkter Adressierung. z.B. %IW, %QW, %MW, %IX, % QX.....
Auch der Feldbus aus deinem Bild ist ja direkt adressiert: %IW256. Der Unterschied zur Steuerungskonfiguration ist, dass die Verwaltung hier nicht vom Controller sondern vom Feldbus übernommen wird.

 

[tomrey]

Hi all,
bevor ich nun den Testbetrieb verlasse und "produktiv" werde, möchte ich Euch mein aktuelles Konzept nochmal zur Diskussion stellen, weil ich doch noch einige Unsicherheiten habe:
node-red verfolge ich als Visu-Ersatz nicht weiter sondern werde für die neue Visu und alles was nicht "SPS-geeignete" Verarbeitung ist, eine Modbus-Kopplung zwischen meiner 889 und einem raspi mit codesys v3 runtime machen. node-red kommt für die nicht "SPS-geeignete" Verarbeitung zum Einsatz also z.B. für die Steuerung eines Yamaha-AVR.

Nun zu Modbus:
Für die Visu benötige ich natürlich zunächst die aktuellen Zustände, die kann ich mir direkt von den physischen DO's holen.
Damit entfiele "Umfüllen" nach PFC-OUT - richtig? Sind demnach PFC-OUT nur für Variablen vorgesehen, die kein physisches OUT haben?
Die Abfrage vom raspi mache ich mit FC1 mit Länge 160, damit habe ich alle phys. DO's erschlagen und spare mir "Umfüllen" von Bools in Words - richtig so?
Die Bedienbefehle vom raspi->889 mache ich per PFC-IN, indem ich meine vorhandenen "xVisuDI's" auf PFC-IN in einer neuen GVL mappe.
Dafür muß ich dann allerdings sämtliche VisuVar's aus den PRG und FB in eine GVL bringen (habe bisher nur die global, die von mehreren PRG/FB genutzt werden).
Die VisuVar's schicke ich dann vom raspi per FC5 ebenfalls alle auf einmal zur 889. Ist das korrekt und sinvoll so?
Offen sind "nicht-BOOL"-Vars:
Ich habe den Wago-scheduler mehrfach im Einsatz, der arbeitet mit einer VAR_INOUT vom "TYPE typSchedule":
Anhang anzeigen 46775 und darin gibt es "TYPE typScheduleWeekly":
Anhang anzeigen 46776deren Werte ich in der Visu ein-/ausgebe.
Die Visu dazu ist eine Visu-Vorlage aus dem Wago-Anwendungshinweis, die ich mit Platzhalter und Ersetzung für meine unterschiedlichen Timer in die bisherige Visu eingebunden habe.
Wie bekomme ich so ein Platzhalter/Ersetzungskonstrukt nach Modbus?
Ich denke, dazu müsste ich mit MerkerVars für In-/OUT arbeiten aber wie bekomme ich die TYPE/STRU's nach Modbus?
Eine ähnliche Baustelle ist für mich die KNX-Heizugssteuerung. Dort arbeite ich aber nur mit Byte/Int und Real, mein Ansatz wäre diese ggf. in Word umgefüllt per Merker zu transportieren.
Für einen Zisternenfüllstand habe ich eine analoge Klemme mit einem Word, daß ich wieder direkt physikalisch abgreifen könnte (nur lesen).
Für die Bedienung von Rollos und Dimmern unterscheide ich zwischen kurzem und langem Tasten sowohl bei den xDI's als auch den xVisuDI's.
Dafür verwende ich den FB_kurzlang aus der Wago Gebaeude_allgemein.lib
Wie teile ich dem per Modbus einen langen Tastendruck mit?

Letzte Grundsatzfrage:
Das Ganze mache ich um:
-Die 889 von der Visu zu entlasten
-Die Visu per Codesys V3 unabhängig von Java wieder im aktuellen browser zu haben.
Kann ich erwarten, daß die neue abgesetzte Visu per Modbus mindestens genauso schnell ist wie bisher auf der 889?
(Der raspi hängt im LAN am gleichen giga-swich wie die 889 oder sollte ich den raspi direkt auf die 2. Ethernet Schnitstelle vom 889 z.B. mit gekreuztem patch-Kabel hängen?
Wie sollte ich den Modbus/Visu-Task auf dem raspi timen (z.B. freilaufend?)
Soweit ich das sehe, gibt es auf der 889 keine Einstellmöglichkeit für einen Modbus-task als slave/server - richtig?

Vielen Dank für Eure Hilfe und ein schönes WE