TIA Modbus TCP MB-Client mehrfach in einem FB aufgerufen

Zuviel Werbung?
-> Hier kostenlos registrieren
habe grade die Beiträge nachgelesen...

=> Mit einer Siemens-Steuerung bekomme ich es nicht hin, Daten von 22 Ladegeräten oder anderen Modbus-Teilnehmern einzusammeln???

Also ich habe neulich einen Hardware-Umbau gemacht, da waren 15 Energiezähler von Janitza drin, ein paar Lüfter und Stellantriebe, an sich knapp 30 Geräte, per Ethernet-Verbindung mit Modbus-TCP anbindung... Das hat eine S7-1513 verwaltet und gesteuert. Über die maximale Anzahl von Teilenehmer hätte ich mir jetzt garkeine Gedanken gemacht!

Paralell kucke ich noch nach Infos in YouTube-Videos, was andere so machen... Wenn ich jetzt nach deren Vorbild, alle einzelnen Word-Brocken über einzelne Register auslesen würde, wäre ich bei 30 Aufrufen des MB-Client, pro Ladegerät, in meinem konkreten Anwendungsfall, bei 4 Ports und 22 Ladegeräten wären das 2640x den MB-Client aufgerufen... Ich glaube wir verlaufen uns hier grade in Begrifflichkeiten, oder?
 
Wie von ducati schon erwähnt. Die 1510sp welches die kleinste CPU im portfolio ist, kann gleichzeitig 88 stehende Verbindungen halten. Das heisst, bis 80 Modbusserver abfragen ist überhaupt kein Problem (vom Standpunkt Verbindungsressourcen). Wenn du jedes register einzeln holen willst, brauchst du auch mehrere Zyklen.
Zieladresse festlegen. Req auslösen, auf done warten buffer wegsichern req löschen, back again.
Darum holt man ja normalerweise die Daten zusammenhängend.

Die Abfragen zu zwei verschiedenen Modbus TCP Servern laufen ja wiederum Parallel. Die müssen nicht gegeneinander verriegelt sein.
 
habe grade die Beiträge nachgelesen...

=> Mit einer Siemens-Steuerung bekomme ich es nicht hin, Daten von 22 Ladegeräten oder anderen Modbus-Teilnehmern einzusammeln???
doch, mit einer 1500er problemlos.
Für 22 Modbusserver brauchst Du 22 MB_Clients mit eigenem IDB und eigenem Verbindungseinstellungen und eigener VerbindungsID.
Diese 22 laufen parallel, also einfach nen Taktmerker an den REQ.

Welche Daten Du jetzt pro Server brauchst, würd ich mir erstmal auf nen Zettel schreiben und dann überlegen, ob ich die in EINEM Block, mehreren Blöcken oder alle einzeln hole.
Dann kannst anfangen zu überlegen, wie Du das mit den mehreren Blöcken am besten machst.
 
Es braucht für das Projekt weder ne 1500er noch braucht es dutzende Ressourcen. Die Wahl der CPU hat nichts mit den Ressourcen bei simplen Abfragen zu tun, sondern eher ob man kritische Daten lesen oder Motoren steuern muss. Und da stellt sich dann eher die Frage ob Modbus der richtige Weg ist und nicht Profinet.

Mein Weg, funktioniert immer, 0 Ausfälle:
Einfach in Schritt 4 auf Disconnect den Done aus Schritt 4 machen, dann den Baustein extern mit einer Schrittkette aufrufen in 22 Netzwerken, oder wenn es schneller gehen soll 5 Gruppen bilden, jeweils ~4 rein, die als Schrittkette, oder einen Verwaltungs-FB in dem die Leseparameter mittels Array und Index übergeben werden. Das Schritt 1 nur startet wenn von extern der Befehl kommt und am Ende eine Rückmeldung Fertig sollte dabei sein.
Abfrage aller 22 wird bei Dir dann vermutlich irgendwo bei 80ms sein wenn die Gegenseite so schnell arbeiten kann, ne 1200er schafft das locker.

Die Diskussion über den EN - lass es sein. EN ist am Client/Server ein Killer die einen CPU-Neustart nötig macht wenn was schief läuft >80A3.
Taktmerker an REQ - auf keinen Fall, macht Probleme mit Mehrfachaufrufen, wird ein Problem wenn das LAN mal spinnt, niemals Taktmerker an irgendeinen Baustein schreiben der über mehrere Zyklen hinweg läuft.

Die 22 Geräte sind NIX. Anlagen mit 1600+ Geräten sind da anspruchsvoller aber auch einfach mit ner 1200er zu managen. Einmal nen Baustein für Verwaltung, einmal nen MB-Client-Baustein erstellen, kompatibel zueinander machen, Arrays und SCL nutzen und alle zukünftigen Programme sind schneller programmiert als man Routing fertig hat oder die ganzen IP-Adressen eintragen kann.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Tja, warum Siemens es nicht hinbekommt, einen Modbusbaustein anzubieten, wo die Benutzung eindeutig ist, frag ich mich schon lange. Jetzt haben wir hier im Thread schon mindestens 4 Varianten, wo der eine oder andere jeweils meint, es richtig zu machen... 😂

Wobei hier auch viel aneinander vorbeigeredet wird.

Wenn Du 1600+ Geräte abfragen willst, musst Du natürlich disconnecten... Für 22 würd ich das erstmal nicht machen, höchstens im Errorfall...

Und den EN := false; machst Du, wenn Du mehrere Client-Bausteine mit dem selben Instanz-DB und selben Verbindungsparametern zum selben Gerät nutzt um nacheinander verschiedene Register abzufragen ohne zu disconnecten.

Und Takmerker am Req ist mal schnell ne einfache Sache, die funktioniert ohne sich wilde Req Setze und Rücksetzeorgien auszudenken, die dann doch im Einzelfall Ärger machen, weil nicht alle Sonderfälle abgedeckt werden... (aber natürlich nicht, wenn mehrere Register am selben Gerät ausgelesen werden)

Done und Error herzunehmen ist zwar schön, braucht aber nen Hosenträger, weil abundzu, warum auch immer, weder Done oder Error kommt...
 
Zuletzt bearbeitet:
Die anderen Punkte werden zur Diskussion, EN/REQ/DONE/ERROR scheinen bei mir ganz anders zu funktionieren, lassen wir das; ich mach es grundsätzlich anders, Kunden vergeben immer wieder Aufträge, jedem das seine.

Ein Punkt den ich ansprechen möchte:
Für 22 würd ich das erstmal nicht machen, höchstens im Errorfall...
Er hat ein Projekt mit 7 Stück grade am Wickel. Danach eines mit 22 in Aussicht. Lass das nächste 40, 6, 13,... haben.
Warum nicht einfach dynamisch so wie er es angesprochen hat?
Einmal programmieren, danach einfach n Array dran, als Anwenderkonstante die Anzahl der Geräte eingeben, im Array die IP-Adressen, fertig? Keine Bastelei mehr, Code ändert sich nie mehr, nur die Konstante und IP-Adressen für die gleichen Geräte. Statt Konstante geht auch ne remanente Variable, n remanentes Array, beides in eine HMI und das Programm muss gar nicht mehr angepackt werden, nur noch parametriert über die HMI, auf zur Serie.
 
Zurück
Oben