Step 7 AG_RECV (FC6) für Modbus TCP Verbindung

Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Dermatze

Angehängt ist das Project mit gleiche Hardware und mit Lars Weiß seine TCP Server modbus baustein.
OB1=>FB10 ,IDB10 innerhalb FB10 SFB4 TON. Register DB ist 111.
In originale Quelle ist dann noch in Temp variable ein Entleer Puffer von 255 Byte aber das gab Problemen bei meine alte test cpu mit lokal data stack.

Diese entleer Puffer herausgeholt(nach überleg mit Lars) und Kommunikation funktioniert not immer einwandfrei.
Baustein van Lars lauft in ein unseren Anlagen mit S7417 und CP443 wobei in ein andere teil von der Anlage CTI SPS modbus Client ist. Die Ethernet module van CTI unterstützt 16 modbus server verbindingen und 64 modbus client Verbindungen damit das von CTI seite aus modbus client günstiger war.

Das project was ich ihr geschickt hatte was um so üben ob das ach andersrum gehen wurde.
(CTI SPS modbus server und S7 sps modbus Client) und das funktioniert wie in dem screenshots zu sehen ist.
Muss dann auch data ausstachen können mit PAC weil modbus server ist modbus server und sollte eigentlich nicht wichtig sein ob das eine andere SPS ist oder ein PAC.

Mit freundlichen Gruß
Henny
 

Anhänge

  • Modbus_Server_LW.zip
    1 MB · Aufrufe: 26
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Matze,

Du brauchst keinen Modbus Server, Du brauchst einen Modbus Client.
Und Du mußt nicht so viel verschiedenes ausprobieren sondern Dich da mal konzentriert durchbeissen.

Ich habe über Deine Aufgabe nachgedacht. Die Programmvorlage von Lars auf AG_RECV umzubauen ist eigentlich nicht schwer, allerdings auch nicht in 1 Stunde gemacht, unter anderem auch deshalb, weil die Vorlage nicht ganz fehlerlos ist und ein wenig überarbeitet werden müsste. Zusätzlich: wenn Du wirklich mehr als die ersten 222 Register auslesen willst (also den ganzen UDT aus der Vorlage), dann kann man nicht mehr gleichlange Antworten abfordern (weil man mehrere unterschiedlich lange nicht zusammenhängende Registerbereiche auslesen muß), dann wird man doch besser den Modbus-RX-Header (9 Byte) und die nachfolgenden Registerwerte getrennt empfangen müssen. Man braucht mindestens 4 Registerabfragen, welche jeweils andere Antwortlängen haben. Eigentlich habe ich das Programm bereits "im Kopf" und bräuchte es "nur" noch runterschreiben. Es möglichst robust zu programmieren braucht aber etwas mehr Zeit. Nur allgemeine Tips zum Programmieren geben reicht anscheinend nicht aus.

Und dann ist ja auch noch Dein unverständliches Problem mit dem AG_RECV-Error, bei dem wir von Ferne wohl nicht helfen können. Für mich unverständlich auch wieso das Programm von kassla #24 bei Dir nicht funktioniert. Was hast Du da geändert? Du solltest Dich da wirklich mal konzentriert durchbeissen.

Harald
 
Guten Morgen Harald,

ja, ich habe mir die Sache sehr viel einfacher vorgestellt :neutral:
Wie das ganze funktionieren soll habe ich mittlerweile schon verstanden - meine ich - siehe #14

Du mußt nicht so viel verschiedenes ausprobieren sondern Dich da mal konzentriert durchbeissen.
Der im #41 enthaltende FB10 ist ja der von Lars, den wollte ich ausprobieren, da hier mehrere AG_RECV Aufrufe durchgeführt werden.

Mir machen ja augenscheinlich "nur noch" die zwei AG-RECV Aufrufe zu schaffen.
Das mit den Registern habe ich mir mal genauer angesehen. Am zweiten AG_RECV (der die Messwerte empfängt) steht bei der LEN eine 240 (online Status) und dann wartet der AG_RECV auf neue Daten.
Da die Werte ja einmal eingelesen werden (nach Neustart), setze ich die Registeranzahl herunter, so dass nur die ersten o.g. Register eingelesen werden sollen.
Mal sehen was dabei rauskommt.

Ich bleibe dran, auch wenn sich bald Ratlosigkeit breit macht :confused::confused:
Evtl. liegts ja auch mit an der alten 315er - wer weiss

Gruß
Matze
 
Zuletzt bearbeitet:
mal konzentriert durchbeissen

Also, gemäß dem FB10 aus #41 habe ich im Baustein, aus dem Siemens Beispiel, die Verriegelung realisiert.
Und die zu empfangenden Bytes auf 240 eingegrenzt.

In der "Schreibtisch-SPS" läuft es jetzt endlich!!!!!!!!!
Alle Daten (die 240Bytes) kommen und werden auch aktulisiert, es gibt keinen Versatz mehr.

Danke nochmals, für Eure Unterstützung und GEDULD! :ROFLMAO:

Gruß
Matze
 

Anhänge

  • PAC3200_315-2DP_CP343-1.zip
    1.018,3 KB · Aufrufe: 28
Zuletzt bearbeitet:
in die Anlage sps und dann ist fertig.

Wie kann ich denn die "Slavenummer" ermitteln?
Auf dem Schreibtisch war das PAC3200 Slave 1, da nichts weiter an der CPU dran war.
Wie ist das in der Bestandanlage, da wird das PAC sicher nicht Slave 1 sein, oder?
Kann man die Nummer in der HW-Konfig oder in Netpro sehen, wie z.B. Profibus-/MPI-Adresse?

Gruß
Matze
 
Hallo Matze

Normaler weise bracht man mit modbus tcp das slave oder Unit Nummer eigentlich nicht.
Jedes modbus tcp server hat ein uniques ip adres und damit ist das eigentlich erledigt.
Default adres ist meistens 1.

Mit modbus RTU RS485 variant bracht man das unit Nummer und must es für jedem slave unique sein damit der master weis wohin gelesen und geschreben werden muss. Kann man dann sehen wie slave adressen mit profibus.

In netpro von anlage sps das ip adres von anlage PAC korrekt einstellen und dann mit ihren modbus funktion baustein in der SPS soll es eigentlich laufen.

Wie Mann das unit Id von PAC anderen oder sehen kann(falls nicht 1 ist) Weiß ich leider nicht weil ich damit nog nicht gearbeitet habe.

Mit freundlichen Gruß
Henny
 
Normaler weise bracht man mit modbus tcp das slave oder Unit Nummer eigentlich nicht.[
Hängt vom Gerät ab, ich hatte auch schon welche die darauf geachtet haben.

Meistens kann man die UnitID irgendwo am Gerät (meist wo die IP ist) einstellen.

Update: Siemens hat mittlerweile für das PAC ein FAQ für den 1500er MBus-Client Baustein rausgebracht.
https://support.industry.siemens.com/cs/ww/de/view/109736516
FAQ schrieb:
Wenn die Verbindung zu einem SENTRON PAC-Gerät aufgebaut werden soll, dann müssen Sie statische Variable "MB_Unit_ID" des Instanz-Datenbausteins der Anweisung "MB_CLIENT" anpassen.
Die UnitID scheint für das PAC anscheinend wichtig zu sein. Auch bei unseren Janitza geht es ohne diese nicht.
 
Zuletzt bearbeitet:
Hallo Zusammen.

Von der Schreibtsich- zur Anlagen-SPS. Programm ist drin, PAC ist verbaut, Verbindung projektiert und im Modbus Baustein eingestellt.
Was soll ich sagen, beim ersten AG_RECV Aufruf gibt es wieder einen Fehler. Allerdings gab es den bislang (auch auf dem Schreibtisch) nicht.
Ich habe mehrmals geprüft ob ich irgendwo etwas vergessen/übersehen habe, nix gefunden alles aus dem funktionierenden Programm #45 kopiert.

Der erste AG_RECV sieht so aus:
Anlage_HC_FB80_1.AG_RECV.JPG

gem der Hilfe ist es
Hilfedatei.JPG

Was ist an der Stelle eine erfolgreiche Abhilfe?


Hardware:
Schreibtisch: 315-2AF03-0AB0 V1.21
Anlage: 315-2AG10-0AB0 V2.6
Der CP wurde mit in die Anlage übernommen 343-1EX30-0XE0 V3.0
 
Hallo Harald,

ja der ist geladen und mit 9Byte hat er die Länge um das Antworttelegramm vom PAC einzulesen.
Anlage_HC_Rx-Header.JPG

Es ist ja der selbe wie bei dem Versuchsaufbau.
 
Hallo Matze

Wann das auf den Schreibtisch SPS gelaufen hatte dann must es doch eigentlich auch laufen in Anlage SPS?
Ihr hat eigentlich nur ein unterschiedlicher SPS in Anlage mit ein andere Programm und zusätzlich ihren modbus Programm, CP343 und PAC sind wie getestet?
Sind in anläge SPS nog Programm teile die ach AG send oder AG receive anrufen?
Ist Kommunikation mit PAC established?

Angehängt ist das project von #38 aber dann erweitert mit bits für job selektion.
Habe ihren DB83 van PAC einkopiert und fuhr Anruf nur job 4 gewählt und versorgt mit modbus Adresse von pac.
Hardware adresse von CP hab ich übernommen von screenshot W#16#12C?

Anruf OB1=> FC99 => FB11,DB71 innerhalb FB11 SFC24 “test db” ,SFC21 “fill” , FC5 AG_Send und FC6 AG_Receive.
Innerhalb FC99 must sind Timer 21 und 25 genutzt und ihr muss small sehen ob das past sonst timernr anderen.

Getest ist diese Baustein mittlerweile neben CTI sps mit modbus server ethernet Schnittstelle auch mit Wago 750-352 ethernet Kopf Station mit wago analog und digitale i/o karte.

Hoffe das es ihr weiter hilft.

Mit freundlichen Gruß
Henny
 

Anhänge

  • PAC_furMatze.zip
    1,2 MB · Aufrufe: 16
Zuviel Werbung?
-> Hier kostenlos registrieren
Wann das auf den Schreibtisch SPS gelaufen hatte dann must es doch eigentlich auch laufen in Anlage SPS?
Das dachte ich eigentlich auch.

Ihr hat eigentlich nur ein unterschiedlicher SPS in Anlage mit ein andere Programm und zusätzlich ihren modbus Programm, CP343 und PAC sind wie getestet?

genau

Sind in anläge SPS nog Programm teile die ach AG send oder AG receive anrufen?

Nein, die Modbus-Verbindung zum PAC ist die einzige die AG_SEND / AG_RECV verwendet

Ist Kommunikation mit PAC established?

Ja.
 
Hallo Matze

Bausteine AG_Send und AG_Receive sind auch eine gleiche Version oder neuer?
CP ach versucht neu zu starten?

Gibt es nog eine Möglichkeit die Schreibtisch SPS zu verbinden in der Anlage mit CP und PAC?
Getestet Programm ist bestimmt nog in Schreibtisch SPS.

Wann die Kommunikation dann wieder gut zum laufen kommt dann ist es definitive kein Software Problem in dem sine das das durch ihnen erstellte Programm nicht in Ordnung ist. Dann must es was zu tun haben mit unterschiedlichem Baustein Versionen??

Schwer zu sagen wo das Problem ist.

Mit freundlichen Gruß
Henny
 
Bausteine AG_Send und AG_Receive sind auch eine gleiche Version oder neuer?
CP ach versucht neu zu starten?

Gleiche Version, Neustart brachte keinen Erfolg

Gibt es nog eine Möglichkeit die Schreibtisch SPS zu verbinden in der Anlage mit CP und PAC?
Getestet Programm ist bestimmt nog in Schreibtisch SPS.

Das ist noch eine Idee, werd es versuchen.
Es sollte ja reichen wenn die Schreibtsich SPS am zweiten Port des Anlagen-CP steckt, dann sollte der PAC auch erreichbar sein (entsprechende Einstellungskorrektur in der Schreibtsich SPS HW-Konfig vorausgesetzt)

Schwer zu sagen wo das Problem ist.

So isses :???:

Zumindest der CP wartet "auf Arbeit"
Anlagen_CP_online.JPG
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Matze

Hab mit meiner Hardware ihren Baustein getestet und bei mir funktioniert er ach!!
Hat ihr in Anlage SPS FB10, instance DB80 , DB81,DB82 und DB83 geladen?
Ist clockmerker byte in Anlage SPS MB0 wie in das Programm?
Hab zum Testen in CTI SPS V8000 – V8119 nach modbus registers 2-121 gemapt (ofset1) und kante dann diese Werte problemlos einlesen in DB83 PAC DB.
Sehe auch die screenshots.

Damit ist sichergestellt das ihren Programm in Ordnung ist zumindest mit meine älteren hardware und ihren Schreibtisch hardware

Hardware bestelnr womit ich getestet habe kannst du sehen in Beispiel project von #41 , #54

Mit freundlichen Gruß
Henny
 

Anhänge

  • matze.jpg
    matze.jpg
    330,8 KB · Aufrufe: 22
  • matze2..jpg
    matze2..jpg
    218,4 KB · Aufrufe: 21
Damit ist sichergestellt das ihren Programm in Ordnung y

Davon bin ich ausgegenagen, da 1:1 von Schreibtisch SPS übernommen.
Es bleit dann nur noch die HW-Konfig/Netpro. Ich weiss nicht mehr wie oft ich die Einstellungen alle schon überprüft habe, da es aber dennoch daruf hinaus läuft muss sich der Fehlerteufel :twisted: da irgendwo versteckt haben.

Gru0ß
Matze
 
Hallo Matze

Kannst du CP und PAC ach anpingen von pc aus?
Sind beide auf das gleiche Netzwerk (Subnetz) angeslossen?
Ist da ein Ethernet Switch verbaut oder sind PAC und CP direkt durch Ethernet Kabel mit einander verbunden?

Mit meine alte CP kann ich nie direkt verbinden mit an andere Teilnehmer da der Ethernet port autocrossing nicht unterstützt, muss dann ein cross over kabel nehmen oder eine ethernetswitch verbauen.

Kann auch nach sein das in der Anlage SPS verbindingungs recoursen anders eingestellt werden müssen.
Hardware => CPU => eigenschaffen => Kommunikation.
Weiß nicht ob PG communication ein TCP Verbindung oder S7 Verbindung ist aber irgendwo in diese Richtung muss das Problem gesucht werden.

Ins das Schreibtisch Project was angehängt war ist das clockmerker byte eingestelt auf MB10 aber in project wird MB0 genutzt.

Leider kann ich ihr auch nicht mehr weiter helfen.

Mit freundlichen Gruß
Henny
 
Zurück
Oben