# Daten über Ethernet aus S7 auslesen



## arcis (2 Juni 2009)

Wir müssen über Ethernet aus einer S7 Daten auslesen. 
Der Kunde will aber sein S7-Programm nicht mehr anfassen.

Kennt jemand dafür geeignete Tools, am besten auf Linux Basis?


----------



## Human (2 Juni 2009)

Soviel ich weiß gibt es die libnodave auch für Linux bzw. ist auch auf Linux verwendbar.

http://libnodave.sourceforge.net/

bzw. im Hochsprachenteil des Forums findest du einiges darüber!


----------



## arcis (2 Juni 2009)

*+*



> *BIG FAT WARNING:
> This is beta code and information. You assume all responsibility for its use.
> 
> DANGER: DON'T connect to a PLC unless you are certain it is safe to do so!!! It is assumed that you are experienced in PLC programming/troubleshooting and that you know EXACTLY what you are doing. PLC's are used to control industrial processes, motors, steam valves, hydraulic presses, etc. You are ABSOLUTELY RESPONSIBLE for ensuring that NO-ONE is in danger of being injured or killed because you affected the operation of a running PLC.
> Also expect that buggy drivers could write data even when you expect that  they will read only !!! *


Ich kann das schon verstehen, aber unser Zeugs muss schnell gebacken werden, zuverlässig sein und professionelle Unterstützung bei Problemen bieten können.


----------



## Human (2 Juni 2009)

Vielleicht dann von Siemens ProDave... 



> ...und professionelle Unterstützung bei Problemen bieten können


 
aber ich bezweifle, dass du das bei Siemens jemals bekommen kannst! *ROFL*


----------



## arcis (2 Juni 2009)

*+*



> aber ich bezweifle, dass du das bei Siemens jemals bekommen kannst!



Dann kann ich dem Kunden immer noch sagen, dass Siemens sein Zeugs nicht auf die Reihe kriegt. Das ist der Unterschied.


----------



## Rainer Hönle (2 Juni 2009)

Und jetzt mal wieder die Möglichkeit für Werbung ;-)
Schau mal bei ACCON-AGLink nach. Das gibt es für Windows, Windows CE und Linux mit Beispielen für alle möglichen Sprachen. Hat außerdem den Beta-Status schon lange hinter sich und wird unter anderem auch von einer Siemens-Tochter (auch bei Cern) gerne eingesetzt.


----------



## Human (2 Juni 2009)

Da fällt mir doch noch was ein, was schon serienmäßig auf der CPU dabei ist und von Siemens ist und ich auch mal eingesetzt habe: Direkt über TCP/IP Daten an den PC senden, dafür gibt es einen FB 63 (TSEND), FB 64 (TRCV), FB 65 (TCON) und einen FB 66 (TDISCON).


----------



## andy_l (2 Juni 2009)

arcis hat aber geschrieben:



arcis schrieb:


> Der Kunde will aber sein S7-Programm nicht mehr anfassen.



Dann scheidet das aus, die Daten an den PC zu senden. Er muss sie sich zwangslaeufig abholen.

Andy_L


----------



## vierlagig (2 Juni 2009)

Rainer Hönle schrieb:


> Und jetzt mal wieder die Möglichkeit für Werbung ;-)
> Schau mal bei ACCON-AGLink nach. Das gibt es für Windows, Windows CE und Linux mit Beispielen für alle möglichen Sprachen.



von eurer produktseite: "Unterstützte Betriebssysteme  			Windows 2000, XP, 2003, Vista"

kein linux??? zumindest erkenn ichs da nicht draus


----------



## Human (2 Juni 2009)

andy_l schrieb:


> arcis hat aber geschrieben:
> 
> 
> 
> ...


 

Naja schon, aber normalerweise, wenn die Daten nicht zyklisch geholt werden sollte man ja noch irgendwo einen Handshake haben, damit man weiß, dass das dann die richtigen Daten sind, falls das noch nicht vorhanden ist kann man das ja auch gleich noch mit reinhauen...


----------



## Flinn (2 Juni 2009)

*Fetchen?*

Hallo,

gitb es vlt. noch eine weitere S7 am Netz, die die Daten dann aus der SPS fetcht (einseitig projektiert) ?

Gruß
Flinn


----------



## Rainer Hönle (2 Juni 2009)

vierlagig schrieb:


> von eurer produktseite: "Unterstützte Betriebssysteme  			Windows 2000, XP, 2003, Vista"
> 
> kein linux??? zumindest erkenn ichs da nicht draus



Oberhalb dieser Tabelle mit deinem zitierten Eintrag steht folgender Text:
"Die Entwicklerlizenzen für Linux und Windows CE sind aus Gründen der Übersichtlichkeit nicht aufgeführt."


----------



## vierlagig (2 Juni 2009)

Rainer Hönle schrieb:


> Oberhalb dieser Tabelle mit deinem zitierten Eintrag steht folgender Text:
> "Die Entwicklerlizenzen für Linux und Windows CE sind aus Gründen der Übersichtlichkeit nicht aufgeführt."



wer lesen kann ist klar im vorteil - kostenpunkt? wie die anderen?


----------



## Rainer Hönle (2 Juni 2009)

vierlagig schrieb:


> wer lesen kann ist klar im vorteil - kostenpunkt? wie die anderen?



Die WinCE- und Linux-Varianten kosten rund 1/3 mehr als die Standard-Windows-Varianten.


----------



## Zottel (3 Juni 2009)

*BIG FAT WARNING:
This is beta code and information. You assume all responsibility for its use.

DANGER: DON'T connect to a PLC unless you are certain it is safe to do so!!! It is assumed that you are experienced in PLC programming/troubleshooting and that you know EXACTLY what you are doing. PLC's are used to control industrial processes, motors, steam valves, hydraulic presses, etc. You are ABSOLUTELY RESPONSIBLE for ensuring that NO-ONE is in danger of being injured or killed because you affected the operation of a running PLC.
Also expect that buggy drivers could write data even when you expect that  they will read only !!! *


arcis schrieb:


> Ich kann das schon verstehen, aber unser Zeugs muss schnell gebacken werden, zuverlässig sein und professionelle Unterstützung bei Problemen bieten können.


Na ja, der 2. Teil, hinter DANGER, steht da wegen der verrückten Schadenersatzklagen, von denen man manchmal aus Amiland hört.
Und nach Erfahrungen mit manchen Nutzern halte ich es auch hierzulande für möglich, daß mal jemand die Schreibfunktion an einer laufenden Maschine testet und NACHHER schaut, wo die wohl hingeschrieben hat...


----------



## arcis (4 Juni 2009)

*+*



> Die WinCE- und Linux-Varianten kosten rund 1/3 mehr als die Standard-Windows-Varianten.


Bei diesen Preisen verstehe ich auch, warum ein libnodave existiert.

Man sollte sich vielleicht überlegen, diese Pakete in kleinere Module
aufzuspalten. Bei diesen Zahlen wird erst mal ganz angestrengt über
Alternativen nachgedacht. Hier gehts doch nur um eine trivialste 
Ethernetkommunikation zwischen einer SPS und einer Applikation. Und nur weil 
dieses popelige Protokoll nicht offen ist, wird einem ziemlich heftig in die Tasche gegriffen, 
übrigens auch bei Siemens.

Bei Mitsubishi gibt es das alles umsonst.


----------



## Rainer Hönle (4 Juni 2009)

arcis schrieb:


> Bei diesen Preisen verstehe ich auch, warum ein libnodave existiert.
> 
> Man sollte sich vielleicht überlegen, diese Pakete in kleinere Module
> aufzuspalten. Bei diesen Zahlen wird erst mal ganz angestrengt über
> ...



Das Problem ist auch nicht das Ethernetprotokoll, sondern das was Siemens damit macht. Und dies dann auch noch bei den unterschiedlichsten Steuerungen zu testen. 
BTW: Bei den Entwicklerlizenzen fallen keinerlei Runtimegebühren mehr an. Unter Win32 gibt es aber auch als Alternative die Möglichkeit einer Runtimelizenz.

Warum setzt ihr eigentlich keine Mitsubishi ein wenn es dort das alles umsonst gibt?


----------



## arcis (4 Juni 2009)

*+*



> Warum setzt ihr eigentlich keine Mitsubishi ein wenn es dort das alles umsonst gibt?



Wir setzen die SPS ein, die der Kunde will. Und jetzt ist halt mal wieder Siemens dran.

Es gibt da angeblich ein offenes "Fetch/Write" Protokoll aus S5 Zeiten von Siemens, mit dem man auch auf S7 CPU's zugreifen kann. Hat jemand zufällig :wink: einen Link zur Beschreibung zur Hand?


----------



## Rainer Hönle (4 Juni 2009)

arcis schrieb:


> Wir setzen die SPS ein, die der Kunde will. Und jetzt ist halt mal wieder Siemens dran.
> 
> Es gibt da angeblich ein offenes "Fetch/Write" Protokoll aus S5 Zeiten von Siemens, mit dem man auch auf S7 CPU's zugreifen kann. Hat jemand zufällig :wink: einen Link zur Beschreibung zur Hand?



Ist soweit ich weiß sogar in den Siemens-Kommunikationshandbüchern beschrieben. Erfordert allerdings im Gegensatz zu Lösungen wie libnodave oder AGLink eine Anpassung des SPS-Programmes.


----------



## arcis (4 Juni 2009)

*+*



> Erfordert allerdings im Gegensatz zu Lösungen wie libnodave oder AGLink eine Anpassung des SPS-Programmes.



Mal schauen, ob wir den Kunden von einer Konfigurationsänderung in seinem Projekt überzeugen können. Erfordert wahrscheinlich 10 Minuten Überzeugungsarbeit. Auf alle Fälle wäre das mal eine Alternative.


----------



## Flinn (4 Juni 2009)

Hallo,

das habe ich doch schon oben geschrieben.

Mit einem GET-Auftrag kannst du einseitig (also nur bei Dir) projektiert, Daten von einer S7 aus einer anderen S7 fetchen, s.o.

Gibt es denn jetzt eine andere S7 am Netz, die evtl. Daten auslesen kann??

Gruß
flinn


----------



## Grubba (4 Juni 2009)

> Es gibt da angeblich ein offenes "Fetch/Write" Protokoll aus S5 Zeiten von Siemens, mit dem man auch auf S7 CPU's zugreifen kann. Hat jemand zufällig :wink: einen Link zur Beschreibung zur Hand?


 
Jo, hab ich, bitteschön:
https://support.automation.siemens....=content&prodLstObjId=22233099&subtype=133300

@Flinn
 Fetch/Write kannst Du doch auch direkt vom PC aus machen.


----------



## arcis (4 Juni 2009)

*+*

Wie immer ganz unten und ganz hinten, Anhang E, Kopplung zu Fremdsystemen mit FETCH/WRITE.

Vielen Dank an Grubba!


----------



## heisch (10 Juni 2009)

Wenn Du die Simatic nicht anpacken darfst, kannst Du die (offengelegte)
S5-kompatible Kommunikation nicht nehmen, weil Du sonst den CP konfigurieren mußt.

Bleibt also die S7-Kommunikation.

Falls der Zugriff auf DBs reicht und Du Linux benutzen willst:
( Vorsicht Werbung
Schau mal auf //sites.inka.de/heisch.  dort: rktcp_server
Dort kannst Du die Demoversion runterladen und alles ausprobieren.
Die Demo-Version ist eine laufzeitbeschränkte Vollversion

Gruß Werner


----------

