Mögliche Rack/Slot Kombinationen ?

[pvbrowser]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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 #

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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 :-(

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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

 

[Jochen Kühner]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

Während man bei dem eigentlich sehr trivialen Siemens Protokoll

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

 

[pvbrowser]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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.

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

 

[pvbrowser]

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 ...