Umfrage zur Siemens SPS Unterstützung für IP-Symcon 4.0

Die Beta kann es bereits. Prob’ es doch mal und gib und Feedback! :slight_smile:

paresy

Hallo paresy,

Ich hab deine Frage ob jemand mehr verwendet als Ausgänge, etc.

Ich vermisse derzeit die schmerzlich Möglichkeit den Datentyp TOD zu verwenden.
Auch der Zugriff auf Strings wäre super.

Dann sollte auch VIPA gehen…ist aber nicht meine Baustelle, nur ein Tipp.

@MrEASY: Läuft die Version 4.0 denn bei dir gut mit deiner S7? Die anderen Funktion kann ich mir zu einem späteren Release gut vorstellen.

paresy

Ich habe die 4.0 nicht am laufen.
Mit derzeit meinte ich bei der 3.4er

Ich habe leider nur ein System. Gibt es Probleme mit der Verbindung? Falls bedarf an einen Test besteht, kötte ich ne VM aufsetzen um das Ganze zu testen.

Ich hoffe, dass es keine Probleme gibt :slight_smile: Ich freue mich aber über jedes Feedback. Falls du also eine VM aufsetzen würdest, wäre das Klasse!

paresy

Hallo Paresy,

ich habe bei meinem IPS 4.0 drei LOGO 7 laufen - und bisher klappt alles wunderbar!

Joachim

S7-300 über Ethernet

Ich möchte noch ergänzen, dass die Reconnect Probleme den WAF extrem nach unten ziehen, in Kombination mit einem ständig laufenden Windows PC, der trotz Optimierung für geringen Stromverbrauch immer noch wesentlich mehr zieht als ein Pi, wäre eine Pi Version mein persönlicher Traum.

Wenn Windows mal wieder Updates installiert und dann rebootet steht bei mir im Haus alles still.

@TimoB: Die Beta der 4.0 ist ja verfügbar, welche Support für S7 per Ethernet hat (auch auf Pi). Magst du mal probieren und uns Feedback geben?

paresy

Hallo,

habe es gerade installiert.

Anschließend wurde ein Client Socket (192.168.178.212 Port 102) angelegt, der als übergeordnete Instanz dem Siemens Gateway zuordnet wurde.

Ich bin mir gerade bei dem Port nicht sicher, ob das der Default-Port für die Cp343 ist, in der alten Config konnte man keinen Port angeben, vermute also dass der fix war.

Leider funktioniert die Verbindung nicht (Firewall testhalber komnplett deaktiviert)

| Öffne Socket…
14:07:37 | 35239 | MESSAGE | Event Control | Wiederverbinden [Client Socket] erfolgreich
14:07:37 | 35239 | WARNING | Client Socket | Fehler beim Lesen: Eine vorhandene Verbindung wurde vom Remotehost geschlossen
14:07:47 | 35239 | ERROR | KernelMT | InstanzManager: Fehler bei Instanz #21776 , Meldung IM_CHANGESTATUS: Zeitüberschreitung beim Warten auf Antwort
14:08:37 | 35239 | MESSAGE | Client Socket | Einstellungen gespeichert
14:08:37 | 35239 | MESSAGE | Client Socket | Öffne Socket…
14:08:37 | 35239 | MESSAGE | Event Control | Wiederverbinden [Client Socket] erfolgreich
14:08:37 | 35239 | WARNING | Client Socket | Fehler beim Lesen: Eine vorhandene Verbindung wurde vom Remotehost geschlossen

Noch ein Tipp:

Finde es ganz praktisch, wenn man 3.4 vs 4.0 parallel testen kann, ohne eine VM installieren zu müssen.

Ich arbeite hierzu einfach mit symbolischen Links

mklink /D IP-Symcon „c:\IP-Symcon - 3.4“

bzw

mklink /D IP-Symcon „c:\IP-Symcon - 4.0“

klappt wunderbar.

Das klingt eher, als wenn die Verbindung nicht akzeptiert wird. Hast du die TSAP Einstellungen mal kontrolliert?

Hier wie es für die Logo aussieht. Aber es müsste für die S7 ähnlich sein: SPS: Siemens, Vipa — IP-Symcon :: Automatisierungssoftware

paresy

(gelöscht)

Unter 3.4 läuft es ja korrekt und die TSAP Einstellungen habe ich aus der 3.4 Settings.json übernommen bzw wurden übernommen

Ich habe die ClientDemo von Snap 7 unter Windows 10 getestet. Damit klappt es. Die Remote TSAP muss auf 1.2 gesetzt werden (1 = PB, 2 = Rack 0 - Slot 2)

Allerdings klappt es mit identischen Einstellungen in IP-Symcon nicht. Die TSAP Einstellungen werden über die EIgenschaftsseite übrigens auch nicht gespeichert. Ich musste die JSON Datei manuell editieren, bin mir aber nicht sicher, ob die Einstellungen überhaupt korrekt ausgelesen werden. VIelleicht gibt es ja hier einen Bug.

Unter Pi läuft es mit identischer Konfiguration problemlos, nur dass ein Pi 1 scheinbar etwas zu schwachbrüstig ist, da die Response-Zeit für das Schalten von Ausgängen mit ca. 800-1000ms zu langsam ist.

Wenn es auf dem Pi läuft, muss es aber ziemlich sicher auch auf deinem Windows Rechner funktionieren! Magst du es ggf. mal mit einer frischen Konfiguration ausprobieren?

paresy

Ich habe es auch mit einer frischen Konfiguration schon versucht. Kann es an diesem „MagicConnect“ Feature liegen, wonach Snap7 erst das PLC anpingt?

Das Ändern der TSAP Werte über die Konsole scheint generell nicht zu funktionieren, egal ob der Symcon Dienst auf dem Pi oder Windows läuft. Ich muss diese immer direkt in der Settings.json ändern. Das lässt sich aber ja leicht reproduzieren.

Leider scheint Snap 7 die analogen Eingänge nicht zu unterstützen (PEW), wodurch die Heizungssteuerung derzeit nicht funktioniert und es kommt teilweise auf dem Pi zu erheblichen Verzögerungen beim Setzen der Ausgänge. Ich sehe, dass das Kommando gesendet wurde, aber manchmal dauert es sogar bis zu 5 Sekunden, bis dann tatsächlich der Ausgang geschaltet wurde.

Noch irgendeine Idee? Benötigst du noch irgendwelche Infos?

Vielen Dank für die TeamViewer Hilfe!

Für das Problem mit der Konfiguration des S7 Gateways gibt es zum nächsten Update einen Fix.
An dem Problem mit den Verzögerungen sind wie noch dran - scheinbar treten die aber nur auf dem Pi1 auf.

paresy