S7-1500 und libnodave oder AGLink?

Zuviel Werbung?
-> Hier kostenlos registrieren
Genau das wäre auch mein Vorschlag. Und zum Lesen könnte man ja auch evtl. auch mal einen anderen Client verwenden, z.B. Eine 300, 400 oder 1200 per Get, oder einen OPC - Server, ....
Nach den ganzen Diskussionen und Hinweisen auf Symbolik und magische Zahlen bin ich mir nicht sicher, ob wir überhaupt noch vom selben Protokoll gesprochen haben, und welches Protokoll jetzt nicht funktionieren soll.
 
Ich hatte noch keine 1500 in den Händen.
Die 1200er hat zumindest zwei Varianten der Variablendienste. Der Zugriff über Absolutadressen, wobei der Zugriff auf Merker immer funktioniert und sonst nur auf als 300/400 kompatibel angelegte Datenbausteine. Und der 'symbolische' Zugriff. Wobei es nicht wirklich symbolisch ist, sondern im TIA zu einem Symbol einer Nummernfolge und eine Prüfsumme generiert wird, und über diese Kombination auf Variablen in der Steuerung zugegriffen werden kann.

Die Bausteindienste und Variablentabelle laufen über eine neues Protokoll (72er).

Die Logfiles die SiemensUser hier angehängt hat sind auch dieses neue 72er Protokoll. Darum wäre es auch mal interessant zu sehen ob die 1500 einen wie bei der 1200 vorhandenen symbolischen Zugriff bietet, und ob das identisch aufgebaut ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
"Symbolisch" bringt den Vorteil, der auf der Folie unten fett markiert ist (kopiert aus PDF, das kürzlich hier zur Verfügung gestellt wurde).

Die Variante 'symbolische' Zugriff der Variablendienste wird aber bei 1500 nicht verwendet, jedenfalls nicht durch HMIs und nicht durch das TIA-Portal. Deshalb denke ich, dass diese Zugriffsart nicht funktioniert, sondern nur die Variante mit Absolutadressen.

STEP 7 Sprachinnovation
Durchgängige symbolische Programmierung


[COLOR=rgb(100.000000%, 100.000000%, 100.000000%)]Konsistenter, typsicherer, schneller und flexibler Zugriff auf Daten[/COLOR]



  • [COLOR=rgb(58.000000%, 62.000000%, 66.700005%)][/COLOR]Das Programm oder die Visualisierung verweist immer auf die richtige Variable, auch bei DB Änderungen
  • [COLOR=rgb(58.000000%, 62.000000%, 66.700005%)][/COLOR]Ermöglicht stets einen konsistenten Datenzugriff
  • [COLOR=rgb(58.000000%, 62.000000%, 66.700005%)][/COLOR]Automatische Namensänderung im gesamten Projekt
  • [COLOR=rgb(58.000000%, 62.000000%, 66.700005%)][/COLOR]Optimierte Bausteine um die beste Laufzeitperformance zu erreichen
  • [COLOR=rgb(58.000000%, 62.000000%, 66.700005%)][/COLOR]Array-Zugriff mit Indexvariable in allen Programmiersprachen
  • [COLOR=rgb(58.000000%, 62.000000%, 66.700005%)][/COLOR]Keine aufwändige Offsetberechnung mehr!
  • [COLOR=rgb(58.000000%, 62.000000%, 66.700005%)][/COLOR]Intellisense für die schnellere Variablenfindung


Seite 11 AS FA SB-PRM 2 Industry Sector


S7-1500


S7-1200


[COLOR=rgb(100.000000%, 100.000000%, 100.000000%)]© Siemens AG 2013. Alle Rechte vorbehalten.[/COLOR]
 
Hi,

ich habe noch einmal ein paar Wireshark-Mitschnitte gemacht. Hierbei wurde über die TIA-Beobachtungstabelle und über HMI auf eine absolute Datenbausteinvariable (DB10.DBW2) und auf eine symbolische Bausteinvariable (aus optimiertem DB10) gelesen:
Anhang anzeigen TIA_Wireshark_DB.zip
S7-1500-TIA_DB10_Sym: Zugriff über TIA-Beobachtungstabelle auf symbolische Datenbaustein-Variable (DB10.Variable)
S7-1500-TIA_DB10DBW2: Zugriff über TIA-Beobachtungstabelle auf (nicht symbolische) Datenbaustein-Variable (DB10.DBW2)
S7-1500-HMI_DB10_Sym: Zugriff über HMI auf symbolische Datenbaustein-Variable (DB10.Variable)
S7-1500-HMI_DB10DBW2: Zugriff über HMI auf (nicht symbolische) Datenbaustein-Variable (DB10.DBW2)

Ich hab's auch noch mal mit LibNoDave probiert. Aber hier gab es die bekannte Fehlermeldung.
Hat einer von euch denn schon mal geschaut, ob evtl. das 32er Protokoll irgendwie in dem 72er Protokoll gekapselt ist?
Oder unterscheidet sich das Ganze grundlegend?

Gruß
Gerd
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das in den Aufzeichnungen verwendete 72er Protokoll ist grundlegend anders. Aber das 32er Protokoll - Variablendienste mit Absolutadressen - wird ebenfalls unterstützt, sofern man es freigeschaltet hat. LibNoDave kann doch das 32er Protokoll mit Absolutadressen! Oder was hast du denn genau probiert?
 
Mit LibNoDave kann ich keine Absolutadressen von einer 1500 lesen (Fehlermeldung: "Error: context is not supported. Step7 says:Function not implemented or error in telgram.")

Ich habe die Option "
Zugriff über PUT/GET-Kommunikation durch entfernten Partner (PLC, HMI, OPC, ...) erlauben" ausgewählt (und übertragen).
Ich kann zwar eine Verbindung zur 1500er aufbauen, aber wenn ich z.B. MW3 oder DB10.DBW2 lese, erhalte ich die oben genannte Fehlermeldung.

Möglicherweise unterstützt die 1500er das 32er Protokoll nicht oder es muss in LibNoDave ein wenig angepasst werden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich könnte mir höchstens noch vorstellen das die 1500er CPU auf den Verbindungstyp schaut, und der ist bei LibNoDave immer PG/PC! Vielleicht kannst du das mal noch mit meiner modifizierten Version probieren, da kann man nämlich den Verbindungstyp einstellen! (lieder ging das die ganze Zeit noch nicht von der Oberfläche).
Ich hab hier mal ne Version von meiner WPF VarTab anghängt, wo du auch den Verbindungstyp einstellen kannst, vielleicht läufts ja damit...
 

Anhänge

  • JFK-VarTab.zip
    987 KB · Aufrufe: 22
Ich könnte mir höchstens noch vorstellen das die 1500er CPU auf den Verbindungstyp schaut, und der ist bei LibNoDave immer PG/PC! Vielleicht kannst du das mal noch mit meiner modifizierten Version probieren, da kann man nämlich den Verbindungstyp einstellen! (lieder ging das die ganze Zeit noch nicht von der Oberfläche).
Ich hab hier mal ne Version von meiner WPF VarTab anghängt, wo du auch den Verbindungstyp einstellen kannst, vielleicht läufts ja damit...

Hab's mal mit der 1500er probiert.
Wenn ich unter "Config Connections" "OP" oder "PG/PC" wähle bekomme ich zwar eine Verbindung zustande, aber wenn ich die Lupe anklicke, wird mein MW3 nicht gelesen (obwohl vor Adresse und unter Connection ein grüner Punkt erscheint, die Werte für MW3 werden nicht aktualisiert). Eine Fehlermeldung gab es aber nicht. Allerdings wird die Oberfläche auch nicht mehr richtig aktualisiert. Sieht so aus, als ob es irgendwo hängt.
Wenn ich als Connection-Type "0-??" wähle, bekomme ich keine Verbindung zur Steuerung zustande.

Ein Gegentest mit meiner 300er funktionierte problemlos (sowohl PG/PC als auch OP)

Gruß
Gerd
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe noch nie mit GET Daten aus einer SPS ausgelesen. Wenn ich das richtig sehe, muss ich hierzu erst eine S7-Verbindung zwischen 300er und 1500er projektiert, oder?

Hier scheitert es aber schon, da meine 315-2 DP + CP343-1 TCP laut Step7 keine S7-Verbindung unterstützt.
Hat einer von euch evtl. eine Step-by-Step-Anleitung, wie ich vorgehen muss, um mit einer 315 + CP343-1 Daten aus der 1500er zu lesen?
 
Gibt es einen aktuellen Stand ob die Verbindung mit der 1500er geht? Bzw. ob es nach der Verbindung immer noch hängt?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mit Hilfe einer S7-315-2 PN/DP können per Put/Get DB's aus der S7-1500 gelesen, als auch geschrieben werden.
Die umgekehrte Richtung funktioniert ebenfalls.
Da meine 315 schon recht alt ist, scheint doch noch ein grundsätzliches Problem in libnodave zu bestehen, was dazu führt, das die 1500'er beim Senden die Daten ablehnt.

Mit Snap7 funktioniert die Kommunikation zur 1500'er tadellos.
 
Da meine 315 schon recht alt ist, scheint doch noch ein grundsätzliches Problem in libnodave zu bestehen, was dazu führt, das die 1500'er beim Senden die Daten ablehnt.
Hast du die Möglichkeit mit Wireshark ein Logfile der Kommunikation zu erstellen? Dann kann man prüfen woran es bei libnodave hakt. Am Besten ein Logfile mit libnodave wenn es nicht funktioniert, und dann mit Snap7 wenn es funktioniert.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe mir die Problematik von libnodave im Vergleich mit Snap7 und ComD.. nochmal genauer angeschaut.
Und es geht doch, zumindest bin ich nun in der Lage DBs (nicht optimierte natürlich) zu schreiben und auch zu lesen.

Wir lesen und schreiben recht große Datenbereiche aus der Steuerung und
holen uns beim Start unserer Software die max. PDU Größe für jede Steuerung, um die Kommunikation zu optimieren.
Genau da geht's schief, denn libnodave liefert für die S7-1500 eine PDU Größe von 960 Bytes.

Begrenzt man nun die PDU Größe auf max. 480 Bytes läuft alles perfekt.

Das Lesen und Schreiben von Ausgängen, Eingängen, ... geht leider nicht, aber dieses Problem hat auch Snap7 und das kommerzielle
ComD..
 
Wir lesen und schreiben recht große Datenbereiche aus der Steuerung und
holen uns beim Start unserer Software die max. PDU Größe für jede Steuerung, um die Kommunikation zu optimieren.
Genau da geht's schief, denn libnodave liefert für die S7-1500 eine PDU Größe von 960 Bytes.

Begrenzt man nun die PDU Größe auf max. 480 Bytes läuft alles perfekt.

Falls die 1500 mit einer PDU-Größe von 960 Bytes antwortet, sollte sie diese auch beherrschen. Womit lässt du dir die ausgehandelte Größe denn anzeigen? Hast du mal mit Wireshark geguckt welche Werte dort angezeigt werden?
Zur libnodave Version 0.8.5 gab es mal eine Änderung bei der Aushandlung der PDU Größe, da war aber eigentlich nur die Anzeige der ausgehandelten Größen falsch.
 
Die Funktion daveGetMaxPDULen hat bisher bei 300er, 400er und WinAC immer korrekte Werte geliefert.
Für eine CP1543-1 habe ich im Handbuch die PDU 480 gefunden. Für die hier vorhandene CPU 1513 ist mir noch nichts untergekommen.
Ich habe im Moment nicht die Zeit, mir die Werte aus dem Wireshark Mitschnitt raus zu fiddeln. Das Ding muss erstmal laufen.

Snap7 und auch das kommerzielle ComD.. arbeiten allerdings mit kleinen PDU Größen < 480.
 
Zurück
Oben