PLCSim Netzwerkerweiterung "NetToPLCSim"

Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich teste im Moment den Zugang über NettoPlcSim und der S7-1200 bzw. S7-1500.

Ich habe das TIA V13 SP1 Upd 4 Professional im Einsatz, bzw. S7-PLC Sim V13 SP1.

Folgendes Problem:

Auf die S7-1200 kann ich problemlos über den Port 102 zugreifen, es gehen alle Funktionen.

Greife ich jedoch auf die S7-1500 zu, so geht zwar der erste Zugriff (etwas verzögert) jedoch dann "stirbt" die V13-Simmulation, bedeutet dass die V13 PLC-Sim nicht mehr gestoppt und gestartet werden kann. Hier hilft nur noch das Beenden und das Neustarten der V13 PCL-Sim.

Kennt jemand das Problem bzw. gibt es hier einen Lösungsansatz?

Gruß

Alute
 
Hi,
womit greifst du denn auf die Simulation zu?

Ich habe es bisher immer nur mit einer Visualisierung getestet (WinCC 7.3, Siemens HMI). Der erste Zugriff dauert immer etwas länger, da ich anhand des ersten eintreffenden Paketes entscheide, ob ich mich zu Plcsim für 300/400 oder 1200/1500 verbinde. Bevor sich jemand mit Nettoplcsim verbindet, hat Nettoplcsim auch keine Verbindung zu Plcsim.

Was ich festgestellt habe, ist dass es stabiler läuft wenn Nettoplcsim sich den Port 102 greift bevor eine Siemens Anwendung gestartet wurde. Also wenn du so vorgehst, wie ich es über deinem Post beschrieben habe.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Thomas,

danke für die schnelle Antwort.

Also, ich greife mit einer Snap7-Anwendung darauf zu. Diese eröffnet den Port, greift die Information ab und schliest den Port wieder. Wie gesagt, klappt mit den anderen Kombinationen (S7-1200, S7-300) ohne Probleme, also Zugriff für Zugriff. Der Zugriff erfolgt quasi "Transaktionsorientiert".

Lediglich bei der S7-1500 "stirbt" die Simulation nach dem ersten Zugriff, die Daten hiervon erhalte ich auch noch. Dann sind keine Zugriffe mehr möglich und auch die Simu ist in einem undefinierten bzw. inoperablen Zustand. Es sieht fast so aus als ob die PlcSim die Anfrage abarbeitet und den Abschluß nicht mehr schafft.

Das Greifen des Ports mit dem NettoPlcSim vor dem Starten der Simulation hat hierbei keinen Einfluß.

Gruß Alute
 
Was liest du denn für Speicherbereiche? Put/Get Kommunikation hast du freigegeben, und falls DB ist dieser nicht-optimiert?

Ich habe es zumindest mal mit libnodave getestet, ich weiß allerdings nicht mehr ob 1200 oder 1500 Plcsim. Ich könnte zumindest probieren ob ich das Problem nachstellen kann.

Ich habs oben falsch beschrieben, bei der Kommunikation zu Plcsim gibt es nur Unterschiede ob das "neue" oder "alte" Protokoll verwendet wurde. D.h. Kommunikation zu Plcsim 300/400 und Plcsim 1200/1500 nicht-optimiert ist gleich (z.B. Snap7, libnodave), und das Plcsim 1200/1500 symbolisch (neues Protokoll). Welche Variante verwendet wird, wird angezeigt wenn du vor Verbindungsaufbau das Monitor-Fenster offen hast. Aber das nur zur Information.
 
Hallo Thomas,

danke für die Antwort. Inzwischen habe ich das V13 SP1 Upd 9 installiert, in der Hoffnung es geht. Leider das gleiche Verhalten, lediglich das Zusammenspiel mit der Port 102 verhält sich etwas anders. Wie gesagt das Verhalten mit der S7-1500 ist identisch.

Zu S7-300/400 und S7-1200/1500 die Thematik zum Protokoll ist klar. Hier habe ich keine Probleme. Das Thema mit den DB ist auch klar und spielt hier keine Rolle.

Zu Snap7: Es ist richtig, die SZL's. Ich lese hier mit und ohne SZL's. Ich kann z.B. direkt und gezielt SZL's auslesen. Auch Funktionen ohne der Mitwirkung von SZL kann ich auslesen, wie gesagt immer ist nur der erste Zugriff bei der S7-1500 erfolgreich.

Nochmals zu den SZL's: Im Gegensatz zu der S7-300/400 gibt es auf der S7-1200/1500 vereinzelte SZL's. Es stehen also nur wenige Einträge, welche ich direkt auslesen kann, zur Verfügung.

Zu Rack/Slot: Klar, diese stimmen überein.

Gruß

Alute
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Thomas,

das probiere ich noch gerne, dies werde ich morgen machen, muss erst das Programm (libnodave testISO_TCP.exe) noch suchen, heute bin ich leider schon aufgebraucht.

Ich hatte es auch mit einem anderen Utility (Snap7 Client Demo) probiert, war das gleiche Verhalten.

Ich werde es morgen mal mit einer anderen CPU, jetzt verwende ich CPU 1511-1 PN, versuchen, vielleicht liegt es ja daran.

Danke für Deine Zeit, ich melde mich morgen wieder.

Schönen Sonntag noch...
 
Hallo Thomas,

ich habe jetzt das Problem im Griff. Du lagest mit Deiner Vermutung zu den SZL-Einträgen richtig. Es können alle Daten, außer den SZL-Einträgen erfolgreich gelesen werden. Bei den SZL-Einträgen wird der erste Zugriff noch geliefert und dann ist Schluß.

Folgendes zu dem S7-PLC-Simulator:

- Unter V11, S7-300 werden noch alle SZL-Einträge zur Verfügung gestellt und können erfolgreich gelesen werden
- Unter V13, S7-1200 werden nur noch wenige SZL-Einträge zur Verfügung gestellt und können erfolgreich gelesen werden
- Unter V13, S7-1500 werden noch weniger SZL-Einträge zur Verfügung gestellt, es kann nur der erste Zugriff gelesen werden

Hier scheint von Seiten Siemens noch eine gröbere Baustelle bezüglich der SZL-Einträge zu existieren. Irgendwie schade. Mal sehen, vielleicht sind ja diese Probleme mit der V14 behoben.

Thomas, nochmals vielen Dank für Deine Unterstützung.

Gruß

Alute
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich glaube nicht, dass Siemens die SZLs mit der V14 erweitert bzw. dass dort überhaupt noch Arbeit investiert wird. Das ist ja sozusagen nur ein Kompatibilitätsmodus.

Bei den SZL-ID generiere ich die Antwort einer Anfrage nach dem Zustand der Baugruppen-LEDs (16#0x74) schon selber, mit Run dauerhaft auf Ein. Es hatte mal jemand eine Anwendung, die nur funktioniert wenn diese Antwort zurückkommt. Bei der Listenabfrage wird diese jedoch nicht mit eingebaut, da sieht man nur was Plcsim wirklich unterstützt.

Weißt du zufällig welche SZLs dein Programm anfragt? Dann könnte ich evtl. eine Antwort dass diese ID nicht unterstützt wird selber generieren, bevor Plcsim dann abstürzt / nicht benutzbar ist. Wobei, Nettopclsim weiß in diesem Fall nicht ob es mit einer Vplc für 300/400 oder 1200/1500 verbunden ist, darum würde das wieder für alle Varianten gelten.
 
Also, ich verwende das Tool "SPS Profiler" mit dem eine Überwachung und Verständigung realisiert wird. Darüber lassen sich neben den Standard Informationen (Ein-, Ausgabe, usw.) auch gezielt zusätzliche Systeminformationen (also die SZL's) auslesen und interpredieren. Für das Auslesen der Standard-Informationen werden keine SZLs benötigt. Die SZL's dienen lediglich dazu ergänzende und anteilige Systeminformationen, etwa Status, Speicher, Anzahl Blöcke, Directory und Bereiche auszulesen. Es ist also nicht notwendig hierfür SZL's zur Verfügung zu stellen da sie nur ergänzend benötigt würden. Ansonsten erfüllt das NettoPlcSim voll meine Anforderungen.
 
Hallo Thomas,

bin gerade dabei NetToPLCSim für die TIA Welt zu testen. Mein Aufbau besteht aus einer VM Windows 10 64 Bit mit WinCC 7.4 Update 2, einer zweiten VM mit PLCSIM für S7-1500 und einer dritten VM Windows 7 die per Softing OPC Server auf die SPS koppelt.

Ich hab es jetzt soweit, dass die Verbindung mit dem OPC Server einwandfrei funktioniert, aber ich bekomme keine Verbindung in der WinCC Runtime. Im Logger sehe ich die IP Adresse der WinCC VM mit dem Hinweis "Failed to connect to PLCSIM"
Im WinCC sind die Variablen im Simatic S7-1200, S7-1500 Channel angelegt. Einstellungen sind IP Adresse auf eingestellte IP, Zugangspunkt ist die entsprechende Netzwerkkarte der VM und die Produktfamilie s71500-Connection. Und da hörts ja dann schon auf, wass ich bei S7-1500 im WinCC einstellen kann. Windows Firewall habe ich jetzt extra mal deaktiviert, aber keine Änderung.

Mich wundert halt, dass der Softing koppelt während WinCC nicht zugreifen kann. Hast du noch irgendeinen Tipp für mich?

Danke!
 
Die Fehlermeldung "Failed to connect to PLCSIM" in WinCC hört sich aber danach an, als wenn da noch etwas auf Plcsim steht.
Mit Nettoplcsim muss WinCC so eingestellt werden, als wenn es mit der echten SPS kommuniziert, also unter dem TCP/IP-Baum in WinCC. Was du beschreibst ist das ja auch noch so.

Ich habe allerdings WinCC 7.4 noch nicht mit Nettoplcsim/Plcsim testen können.
Denn beispielsweise funktioniert WinCC 7.3 nicht mehr mit Plcsim V14, mit Plcsim V13 (und Nettoplcsim) funktioniert WinCC 7.3 hingegen einwandfrei. Allerdings liegt das Problem auf Protokollebene, ich weiß aber nicht ob das auch mit WinCC7.3 und einer realen 1500 mit neuerer Firmware auftritt.
Im Siemens Supportforum hatte jemand zumindest den Fall, dass ein WinCC 7.2 nicht mehr mit einer echten 1200 und der neuesten Firmware kommunizieren kann. Wie man es sonst von WinCC gewohnt ist, d.h. das kann mit jeder Siemens S7 sprechen, scheint mit den neuen 1200/1500 nicht mehr zu gelten. Siemens hat das aber nicht (öffentlich) dokumentiert, welche WinCC Version mit welcher Steuerungsgeneration/Firmwarestand kompatibel ist.
 
Ich wette, das wissen die selbst nicht genau und bekommen erst nach und nach mit, das es hier hakt. :ROFLMAO:
Oder so. Wahrscheinlich ist der WinCC Teil eine andere Abteilung. Die TIA-Leute frickeln in üblicher Weise vor sich hin, mit jedem Servicepack wird erstmal alles auf links gedreht - ist bei TIA ja egal, du musst ja immer alles zusammen hochrüsten weil sonst nichts mehr geht. Und die WinCC Leute bekommen davon nichts mit.
Das dürfte interessant werden, wenn der Kunde ein Multiserver/client WinCC am Laufen hat das er gerade für ein paar tausend Euro hochgerüstet hat damit es mit der 1500 kommunizieren kann, und es dann ein halbes Jahr später mit der neuen Steuerung nicht mehr zusammenspielt.
 
Die Fehlermeldung "Failed to connect to PLCSIM" in WinCC hört sich aber danach an, als wenn da noch etwas auf Plcsim steht.
Mit Nettoplcsim muss WinCC so eingestellt werden, als wenn es mit der echten SPS kommuniziert, also unter dem TCP/IP-Baum in WinCC. Was du beschreibst ist das ja auch noch so.
Die Fehlermeldung kommt nicht im WinCC sondern im Logger vom NetToPLCSim, sprich der bekommt wohl mit das WinCC gerne möchte aber das Routen klappt dann nicht.
Wenn sich die Gelegenheit ergibt kannst du ja berichten ob es mit der Konsteallation gehen müsste. Wir bestellen jetzt kurzfristig eine 1517-3 PN/DP so das der Kollege weiter testen kann.

Trotzdem Danke für das schnelle Feedback
 
Zurück
Oben