# Mögliche Rack/Slot Kombinationen ?



## pvbrowser (8 Juli 2010)

Kann mir jemand sagen, welche Kombinationen von Rack/Slot bei den verschiedenen S7 SPS'en gültig sind ?

--------#     Rack         Slot
##########################
S7_200   #
S7_300   #
S7_400   #
S/_1200  #


----------



## IBFS (8 Juli 2010)

pvbrowser schrieb:


> Kann mir jemand sagen, welche Kombinationen von Rack/Slot bei den verschiedenen S7 SPS'en gültig sind ?
> 
> --------# Rack Slot
> ##########################
> ...


 
Du solltest schon dazu sagen, ob das sich auf CPU oder CP bezieht.
Also bei der S7-300 ist es für die CPU klar:

Rack 0 / Slot 2 == CPU

Bei der S7-400 kann es versch. Kombination geben - auch Multiprozessorbetieb.
Das kann man für die konkrete Konfig aber alles aus der HWKonfig ablesen. 

Mit S7_200 #   und   S7_1200 #   habe ich momentan nix zu tun, aber das sollte auch kein
Problem sein das herauszubekommen.


Gruß

Frank


----------



## vierlagig (8 Juli 2010)

IBFS schrieb:


> Bei der S7-400 kann es versch. Kombination geben - auch Multiprozessorbetieb.
> Das kann man für die konkrete Konfig aber alles aus der HWKonfig ablesen.



schließt "Multiprozessorbetrieb" in deiner Definition die Mglkt. 2er unabhängiger CPUs, die lediglich über SEND und RECV kommunizieren könne, wenn sie wollen, ein?


----------



## IBFS (8 Juli 2010)

Die Frage, die gestellt wurde, bezieht sich doch nur auf den
physiaklischen RACK/SLOT-Platz. Da ist mir die Art der
Kommunikation erstmal schnuppe, denn das war ja nicht gefragt.
Und wenn des die Möglichkeit gibt, zwei CPUs zu stecken, dann
sind das zwei verschiedene SLOT-Plätze. 
Das ist so wie die quasi-MPI-Adesse einer FM343, die mußte
auch korrekt angegeben werden, sonst war Essig mit der 
Datenübertragung. - Ja ich komme vom Thema ab.   

Gruß

Frank


----------



## pvbrowser (8 Juli 2010)

IBFS schrieb:


> Du solltest schon dazu sagen, ob das sich auf CPU oder CP bezieht.



Rack/Slot legen ja letztendlich den TSAP bei der Kommunikation fest.
Ähnlich zu libnodave haben wir eine Klasse zur Kommunikation mit Siemens SPS'en.
http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlSiemensTCP.html

Mir geht es jetzt darum, eine Regel zur Bildung des TSAP aus Rack/Slot zu bekommen, die für alle S7 Modelle gilt.


----------



## Jochen Kühner (8 Juli 2010)

Kannst du den TSAP nicht einfach berechnen, aus den Rack/Slot Werten, sowie das LibNoDave macht??

Glaube 4 Bits für Rack und 4 Bits für Slot....


----------



## pvbrowser (8 Juli 2010)

Jochen Kühner schrieb:


> Kannst du den TSAP nicht einfach berechnen, aus den Rack/Slot Werten, sowie das LibNoDave macht??
> 
> Glaube 4 Bits für Rack und 4 Bits für Slot....



Bei libnodave finde ich:

grep rack nodave.c 
daveConnection * DECL2 daveNewConnection(daveInterface * di, int MPI, int rack, int slot) {
dc->rack=rack;
dc->msgOut[17]=dc->rack+1;

grep slot nodave.c 
daveConnection * DECL2 daveNewConnection(daveInterface * di, int MPI, int rack, int slot) {
dc->slot=slot;
dc->msgOut[18]=dc->slot;

Anscheinend muss bei rack noch 1 addiert werden.
Dann wären S7_300 und S7_400 geklärt.

Bei S7_200 gibt es ja keinen Rack/Slot.
Da steht dann 'M','W'. in msgOut[17/18]

Wie sieht das aber nun bei S7_1200 aus ?

Leider habe ich keine S7_1200 zum testen :-(


----------



## Jochen Kühner (8 Juli 2010)

pvbrowser schrieb:


> Bei libnodave finde ich:
> 
> grep rack nodave.c
> daveConnection * DECL2 daveNewConnection(daveInterface * di, int MPI, int rack, int slot) {
> ...



Mhmmm Ich bin mir da jetzt nicht sicher ob das so ganz richtig ist, kann es aber auch nicht mit einem rack>0 testen, da Ich nur eines habe! Aber beim Routing habe Ich es so implementiert:
(dc->routingSlot + dc->routingRack*32)

Das was dort mit Rack+1 angegeben wird ist bei mir die Verbindungsart (PG, OP... Verbindung).

Aber vielleicht ist es auch bei mir falsch...

Kann Vielleicht mal jemand libnodave mit Rack>0 testen...


----------



## Jochen Kühner (8 Juli 2010)

*Also...*

Also Ich hab das heute nochmal mit Wireshark, AgLink und Step7 probiert, und Ich denke das die Implementierung in libnodave nicht richtig ist... Ich hab das in meiner Version mal angepasst... Wär aber schön wenn das mal noch jemand nachprüfen könnte...

Also Ich denke die Zeile
dc->msgOut[17]=dc->rack+1;
muss raus und
dc->msgOut[18]=dc->slot;
muss durch
dc->msgOut[18]=dc->slot + dc->rack * 32 ;

ersetzt werden...

So ist's nun zumindest bei mir drinn...

Mfg.


----------



## pvbrowser (9 Juli 2010)

Das Protokoll ist ja "reverse engineered".
Ich denke das weiß noch niemand von uns so ganz genau.

Du hast ja:
    switch ( $this->CPU ) {
      case ("S7200"):
        //S7200: Chr(193) & Chr(2) & Chr(16) & Chr(0) 'Eigener Tsap
        $bSend1[11] = 193;
        $bSend1[12] = 2;
        $bSend1[13] = 16;
        $bSend1[14] = 0;
        //S7200: Chr(194) & Chr(2) & Chr(16) & Chr(0) 'Fremder Tsap
        $bSend1[15] = 194;
        $bSend1[16] = 2;
        $bSend1[17] = 16;
        $bSend1[18] = 0;
        break;
      case ("S7300"):
        //S7300: Chr(193) & Chr(2) & Chr(1) & Chr(0)  'Eigener Tsap
        $bSend1[11] = 193;
        $bSend1[12] = 2;
        $bSend1[13] = 1;
        $bSend1[14] = 0;
        //S7300: Chr(194) & Chr(2) & Chr(3) & Chr(2)  'Fremder Tsap
        $bSend1[15] = 194;
        $bSend1[16] = 2;
        $bSend1[17] = 3;
        $bSend1[18] = $this->Rack * 2 * 16 + $this->Slot;
        break;
      case ("S7400"):
        //S7400: Chr(193) & Chr(2) & Chr(1) & Chr(0)  'Eigener Tsap
        $bSend1[11] = 193;
        $bSend1[12] = 2;
        $bSend1[13] = 1;
        $bSend1[14] = 0;
        //S7400: Chr(194) & Chr(2) & Chr(3) & Chr(3)  'Fremder Tsap
        $bSend1[15] = 194;
        $bSend1[16] = 2;
        $bSend1[17] = 3;
        $bSend1[18] = $this->Rack * 2 * 16 + $this->Slot;
        break;
      default:

Wir haben da
  static const unsigned char s7_200_connect_block[] =
    {3,0,0,22,0x11,0xE0,0x00,0x00,0x00,0x01,0x00,0xC1,2,'M','W',0xC2,2,'M','W',0xC0,1,9};
  static const unsigned char s7_300_connect_block[] =
    {3,0,0,22,0x11,0xE0,0x00,0x00,0x00,0x01,0x00,0xC1,2,1  ,0  ,0xC2,2,1  ,2  ,0xC0,1,9};
  static const unsigned char s7_400_connect_block[] =
    {3,0,0,22,0x11,0xE0,0x00,0x00,0x00,0x01,0x00,0xC1,2,1  ,0  ,0xC2,2,1  ,3  ,0xC0,1,9};
  static const unsigned char other_connect_block[] =
    {3,0,0,22,0x11,0xE0,0x00,0x00,0x00,0x01,0x00,0xC1,2,1  ,0  ,0xC2,2,0  ,1  ,0xC0,1,9};
  unsigned char connect_block[22];

und von außen kann der Benutzer connect_block[17/18] beeinflussen: 
  if(rack_number != -1) connect_block[17] = rack_number;
  if(slot_number != -1) connect_block[18] = slot_number;
Wenn da -1 steht, nimmt er also die default Werte.

Siehe den doConnect()
http://pvbrowser.org/pvbrowser/sf/m...mensTCP.html#14d6ae4a736f17e41fd79a14d3f65abc

aus
http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlSiemensTCP.html

Es wäre schön, wenn wir das allgemeingültig rauskriegen würden.
Also auch für S7_1200.


----------



## Jochen Kühner (9 Juli 2010)

Dann ahbt ihr es ja auch so wie Ich jetzt...

Ich habs zumindest mit AGLink probiert, Die senden im

dc->msgOut[17] die Verbindungsart, und das wird auf der SPS dann auch als PG oder OP Verbindung angezeigt, Also denke Ich das es bei libnodave falsch ist!

Sonst dürfte euer Code mit dem wert 3 in [17] ja gar keine Verbindung aufbauen wenn es das rack wäre...

Für die 1200 kann man vieleicht mit dem reflector was aus den siemens dlls rauslesen (wenn das denn legal ist...)

Hab aber auch keine 1200 zur hand, sonst würde Ich gerne weiterhelfen...


----------



## Rainer Hönle (9 Juli 2010)

Schön dass ACCON-AGLink als Vorbild dient ... ;-)


----------



## Jochen Kühner (9 Juli 2010)

Rainer Hönle schrieb:


> Schön dass ACCON-AGLink als Vorbild dient ... ;-)



Nicht nur... Aber dort kann Ich einfach die Verbindungsart einstellen, was in Step 7 nicht so leicht möglich ist... Dort müsste Ich es dann erst wieder mit einem OP und mit Step 7 probieren...

Denke Ihr werdet das ja auch nicht anders gemacht haben ;-)

Mfg.


----------



## Rainer Hönle (9 Juli 2010)

Jochen Kühner schrieb:


> Nicht nur... Aber dort kann Ich einfach die Verbindungsart einstellen, was in Step 7 nicht so leicht möglich ist... Dort müsste Ich es dann erst wieder mit einem OP und mit Step 7 probieren...
> 
> Denke Ihr werdet das ja auch nicht anders gemacht haben ;-)
> 
> Mfg.



Wir mussten den steinigen Weg gehen und bekamen die Häppchen nicht so mundfertig serviert ...
Aber zur Beruhigung: es steckt noch viel mehr drin, als das was man mit den paar Checkboxen und Auswahlen einstellen kann ;-)


----------



## LowLevelMahn (9 Juli 2010)

*finde ich aber trotzdem nicht so gut*

>Denke Ihr werdet das ja auch nicht anders gemacht haben

aber die deltalogic junges *sind* den schweren(langsamen) weg über step7 gegangen 

hoffe du läufst dich jetzt nicht warm und adaptierst schritt für schritt das sps-kommunikations-featureset *mittels* aglink-trivialisierten testszenarien 

so hab ich es bei deinen bisherigen posts noch nicht gesehen, aber lass dich nicht von der dunklen seite der macht verleiten...


----------



## pvbrowser (9 Juli 2010)

Ich finde, dies ist ein schönes Beispiel für die Nachteile proprietärer Protokolle.

Während man bei dem eigentlich sehr trivialen Siemens Protokoll auf "reverse engineering" angewiesen ist, wenn man nicht den original Siemens Treiber nehmen will (den lässt sich Siemens ja vergolden).
Wenn man die Nachbauten nimmt, muss man halt etwas "frickeln" 

Im Gegensatz dazu macht Modbus (egal ob RTU oder TCP) keinerlei Probleme, weil die Spec. offen dokumentiert ist.
Deshalb achte ich auch darauf, dass die von mir verwendeten Komponenten möglichst Modbus können.


----------



## Rainer Hönle (9 Juli 2010)

pvbrowser schrieb:


> Während man bei dem eigentlich sehr trivialen Siemens Protokoll


Sorry Rainer, ab da kann ich nur *ROFL* sagen.


----------



## pvbrowser (9 Juli 2010)

Rainer Hönle schrieb:


> Sorry Rainer, ab da kann ich nur *ROFL* sagen.



Also, ich finde das Siemens Protokoll wirklich trivial.
Siemens versteckt da nur ein paar Geheimnisse drin.
Wenigstens der Datenaustausch SPS <-> PC sollte von Siemens offen dokumentiert werden. Der Rest, der für weitergehende Funktionen (Programmierung ...) gebraucht wird, kann ja meinetwegen geheim bleiben.

Für mich selber stellt die Kommunikation mit Siemens SPS kein großes Problem da. Dazu habe ich ja genügend "Knoff Hoff" 
Anders sieht es schon aus, wenn Andere das mal eben nutzen wollen.


----------



## Rainer Hönle (9 Juli 2010)

pvbrowser schrieb:


> Also, ich finde das Siemens Protokoll wirklich trivial.
> Siemens versteckt da nur ein paar Geheimnisse drin.
> Wenigstens der Datenaustausch SPS <-> PC sollte von Siemens offen dokumentiert werden. Der Rest, der für weitergehende Funktionen (Programmierung ...) gebraucht wird, kann ja meinetwegen geheim bleiben.
> 
> ...



Welche Kommunikationsprotokolle meinst Du jetzt? Es gibt ja nicht DAS Siemens-Protokoll.


----------



## pvbrowser (9 Juli 2010)

Rainer Hönle schrieb:


> Welche Kommunikationsprotokolle meinst Du jetzt? Es gibt ja nicht DAS Siemens-Protokoll.



Das alte Fetch/Write Protokoll von S5 war ja noch wenigstens offen gelegt.

Das neuere Protokoll für S7 Modelle, mit dem man
ORG_DB, ORG_M, ORG_E, ORG_A, 
ORG_PEPA, ORG_Z, ORG_T
austauschen kann, ohne auf der SPS eine Kommunikation schreiben zu müssen, ist eben nicht offen,
wird aber z.B. von libnodave nachgebaut.
So ein Nachbau ist aber immer wackelig, wenn neue Modelle herauskommen ...


----------



## pvbrowser (9 Juli 2010)

Der Punkt ist einfach,

Ich sehe es nicht ein Geld dafür auszugeben, um mit einer SPS kommunizieren zu können.

Die Hersteller sollen einfach Ihre Hardware verkaufen und das Protokoll zum Datenaustausch offen legen (so wie bei Modbus).


----------



## Rainer Hönle (9 Juli 2010)

pvbrowser schrieb:


> Das alte Fetch/Write Protokoll von S5 war ja noch wenigstens offen gelegt.
> 
> Das neuere Protokoll für S7 Modelle, mit dem man
> ORG_DB, ORG_M, ORG_E, ORG_A,
> ...


Das ist ja auch der einfachste Teil im Protokoll. Beim Rest wird es allerdings richtig spannend. Und da müssen wir schon gut sein, denn unser ACCON-AGLink ist auch in verschiedenen Bereichen beim großen S im Einsatz.



> So ein Nachbau ist aber immer wackelig, wenn neue Modelle herauskommen ...


Mit diesem Wackeln kann ich schon eine ganze Weile ganz gut leben. Außerdem sehe ich das Ganze eher sportlich: wie lange brauchen wir, um das geänderte Protokoll zu implementieren.


----------



## LowLevelMahn (9 Juli 2010)

Rainer Hönle schrieb:


> Sorry Rainer, ab da kann ich nur *ROFL* sagen.



dabei ist immer wichtig was die Zielsetzung einer "Lösung" ist

ich denke das pvbrowser das protokoll in bezug auf nicht-alles-100%-perfekt-und-vollständig-ziel trivialisiert (noch dazu werden in den offenen implementation auch viele features kaum bis garnicht genutz)

aus deltalogic-sicht ist das protokoll eben nicht trivial - da man eine 100% abdeckung und premium qualität erreichen möchte - damit kann man eine libnodave/pvbrowser redet mit der sps implementation nicht gleichgesetzt werden


----------



## Rainer Hönle (9 Juli 2010)

pvbrowser schrieb:


> Der Punkt ist einfach,
> 
> Ich sehe es nicht ein Geld dafür auszugeben, um mit einer SPS kommunizieren zu können.
> 
> Die Hersteller sollen einfach Ihre Hardware verkaufen und das Protokoll zum Datenaustausch offen legen (so wie bei Modbus).



In weiterer Konsequenz sollen die Hersteller dann auch die Programmiersoftware, die Projektiersoftware etc. alles verschenken?


----------



## pvbrowser (9 Juli 2010)

Rainer Hönle schrieb:


> In weiterer Konsequenz sollen die Hersteller dann auch die Programmiersoftware, die Projektiersoftware etc. alles verschenken?



Die Hersteller sollen in 1 Linie Ihre Hardware verkaufen.
Die Kommunikation zur SPS MUSS offen sein.
Modbus ist ja bei vielen Herstellen auf deren SPS verfügbar, kostet bei Siemens aber nach meinem Wissen.

Bezahlt werden soll Hardware, Programmier/Projektier-Software als Developer Lizenz. Runtime Lizenzen will ich nicht.

Bezahlt werden soll der Bau/Test/Inbetriebnahme einer Automation beim Kunden. Der Kunde sollte aber die Quellen der geschaffenen Lösung erhalten.


----------



## pvbrowser (9 Juli 2010)

Ich könnte mir vorstellen, dass einige Hersteller (nicht unbedingt Siemens) in Zukunft embedded Hardware anbieten werden, auf der MeeGo oder Android läuft und
wo die Hardware in einen industrietauglichen Gehäuse ist und
über I/O verfügt.


----------



## Jochen Kühner (9 Juli 2010)

Rainer Hönle schrieb:


> Das ist ja auch der einfachste Teil im Protokoll. Beim Rest wird es allerdings richtig spannend. Und da müssen wir schon gut sein, denn unser ACCON-AGLink ist auch in verschiedenen Bereichen beim großen S im Einsatz.



Siemens hat ja sogar den russischen Lizenzgenerator im Einsatz welchen es für Siemens Produkte gibt (wir haben das in einer Siemens Schulung gezeigt bekommen wie man damit Lizenzen installiert.... Zzzzz...)


----------



## Rainer Hönle (9 Juli 2010)

Jochen Kühner schrieb:


> Siemens hat ja sogar den russischen Lizenzgenerator im Einsatz welchen es für Siemens Produkte gibt (wir haben das in einer Siemens Schulung gezeigt bekommen wie man damit Lizenzen installiert.... Zzzzz...)



So etwas. Da bin ich aber froh, dass sie bei uns die Lizenzen kaufen.


----------



## Sven Rothenpieler (9 Juli 2010)

pvbrowser schrieb:


> Die Hersteller sollen in 1 Linie Ihre Hardware verkaufen.
> Die Kommunikation zur SPS MUSS offen sein.



Und wenn ich ein Auto kaufe, dann nur mit integrierter Vollkasko-Versicherung ohne zusätzliche Kosten und lebenslanger Steuerfreiheit... das wär mal was...


----------



## vierlagig (10 Juli 2010)

zum glück halte ich mich mittlerweile aus solchen diskussionen raus.

ich würd mich ja nur noch maßlos aufregen über die weltfremde sicht so mancher anwender und dem entwickelnden und vertreibenden gewerbe nicht genug zustimmung und verständnis zukommen lassen können...


----------

