Probleme mit Libnodave und Routing

Thorsten Schier

Level-1
Beiträge
8
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi @ all,

wir verwenden seit einiger Zeit libnodave für den Zugriff auf S7-Steuerungen.

Nun wollten wir auch die libnodave-Erweiterung von Jochen Kühner für den Zugriff auf Steuerungen via Routing verwenden und haben damit nun Probleme.

Wir haben bei einem Partner ein Netz aus zwei Steuerungen aufgebaut und versucht, die eine Steuerung direkt über ISO over TCP anzusprechen und die andere via Routing über Profibus. Der Zugriff über ISO funktioniert auch, auch mit dem neuen Konstruktor, wenn man dort das Routing deaktiviert. Aktiviert man jedoch das Routing und versucht, die zweite Steuerung anzusprechen, schlägt der Verbindungsaufbau sofort fehl.

Wir haben dies sowohl mit unserer eigenen Applikation, die mit Delphi programmiert wurde und als Dienst unter Windows läuft, als auch mit dem Testprogramm (TestLibrary.exe) von Jochen Kühner ausprobiert.

Dabei haben wir folgende Hardwarekonfiguration verwendet:

Industrial Ethernet: EthernetHMS (S7-Subnetz-ID: 0002 - 0006):
Teilnehmeradresse: Station: Baugruppe: R/S:
172.16.16.12 - SIMATIC 300 (1) - CPU 315-2PN/DP - 0/2
172.16.16.20 - PG/PC(1) - -

PROFIBUS: PROFIBUS(1) (S7-Subnetz-ID: 0002 - 0001):
Teilnehmeradresse: Station: Baugruppe: R/S:
0 - PG/PC(1) - -
4 - SIMATIC 300 (1) - CPU 315-2PN/DP - 0/2
11 - SIMATIC 300 (2) - CPU 315-2 PN/DP - 0/2


Die Station Simatic 300 (2) sollte dabei via Routing angeprochen werden. Über das Programmiergerät hat das mit Step 7 auch funktioniert. Aber sowohl unsere Applikation als auch das Testprogramm von Jochen Kühner sind sofort auf einen Fehler gelaufen.


Wir haben folgende Parameter verwendet:

daveNewExtendedConnection:
IntPtr di, - Rückgabe von daveNewInterface
byte[] destination, - 172.16.16.12
int DestinationIsIP, - 1
int rack, - 0
int slot, - 2
int routing, - 1
int routingSubnetFirst, - 2 (führende Nullen wurden im Test-Programm immer weggenommen)
int routingSubnetSecond, - 1
int routingRack, - 0
int routingSlot, - 2
byte[] routingDestination, - 11
int routingDestinationIsIP - 0
);

daveNewExtendedConnection gibt als Fehlercode -1 zurück, das Testprogramm gibt folgende Meldung aus: "Error connecting...". Das passiert praktisch sofort.

Hat jemand eine Ahnung, was wir falsch machen? Sind die Parameter soweit korrekt gesetzt? Wie könnte man noch überprüfen, ob das Subnetz korrekt aufgesetzt ist?

Unsere Applikation läuft auf einem Rechner mit Windows 7 (64 Bit), unsere Anwendung ist aber eine 32 Bit-Anwendung. Auf dem Rechner ist keine Siemens-Software wie Step 7 installiert. Der Zugriff mit dem Programmiergerät erfolgte von einem anderen Rechner aus.

Viele Grüße und Vielen Dank,

Thorsten
 
Die Routing Configuration wurde auf die CPU geladen? Schick mir mal einen Wireshark Auszug wenn Ihr mit meinem Testprogramm zu der Routing CPU eine Verbindung aufbaust!

Hab es noch nie mit einer PN/CPU probiert, weis nicht ob da was anders ist?
 
Hallo Jochen,

danke für Deine Antwort!

Die Routing Configuration wurde auf die CPU geladen?

Davon gehe ich aus. Ich habe das allerdings nicht selbst gemacht, da wir die Testumgebung bei einem Partner von uns aufgebaut haben und die das Projekt in Step 7 entsprechend konfiguriert haben. Da ich mich selber mit Step 7 nicht auskenne, muß ich darauf vertrauen, daß das korrekt gemacht wurde. Mit dem Programmiergerät bzw. Step 7 kommt man ja auch via Routing über Profibus auf die Steuerung. Aber es ist natürlich möglich, daß bei der Konfiguration der CPUs etwas noch nicht stimmt und das Programmiergerät bzw. Step 7 trotzdem den Weg finden. Daher meine Frage, wie man noch überprüfen könnte, ob das Netz korrekt aufgebaut bzw. konfiguriert wurde.

Schick mir mal einen Wireshark Auszug wenn Ihr mit meinem Testprogramm zu der Routing CPU eine Verbindung aufbaust!

Hab es noch nie mit einer PN/CPU probiert, weis nicht ob da was anders ist?

Von der Kommunikation zwischen dem Testprogramm und der Routing-CPU habe ich leider keinen Wireshark-Auszug. Ich kann allerdings einen von der Kommunikation über das Programmiergerät bzw. Step 7 anbieten. Vielleicht hilft das ja auch weiter um zusehen, ob das Subnetz korrekt konfiguriert ist? Ich hänge den mal als Anhang an.

Sobald ich wieder bei unserem Partner bin, werde ich dann auch die Kommunikation zwischen dem Testprogramm und unserer Applikation einerseits und der CPU andererseits protokollieren.

Die DLL die wir verwendet haben stammt vom 23. 7.

Viele Grüße,

Thorsten

PS:
Noch eine Anmerkung nebenbei: die DLL scheint die daveNewExtendedConnection nicht korrekt zu exportieren. Wenn man sich z. B. mit PE Explorer ansieht, was die DLL exportiert, so wird die Methode dort als _daveNewExtendedConnection@48 angegeben. .NET scheint ja trotzdem damit klarzukommen, aber unsere in Delphi geschriebene Anwendung konnte die DLL zunächst nicht binden, bis wir den Aufruf in der nodave.pas, der Delphi-Header-Datei für die libnodave, so angepaßt haben, daß sie genau mit dem in PE Explorer angezeigten Namen aufgerufen wird. Das nur zur Info, da wir dieses Problem für uns ja gelöst haben.
 

Anhänge

  • S7Routing.zip
    5 KB · Aufrufe: 22
Zuletzt bearbeitet:
Kannst mir ja mal vorher schreiben bevor du dort bist, wenns dann mit der neuen dll nicht geht, schickst mir mal ein wireshar auszug vom verbindungsaufbau mit dem simatic manager, und einen mit meinem connection programm.

Ich werd das routing am Montag an meinem Testsystem nochmal probieren, da das was ich dir vorhin in der geänderten dll geschickt hab glaube ein fehler war!
 
Nochmals Ich...

Hab grad nochmals deinen Wireshark auszug angesehen...

Kann es sein das Ihr die Subnetz Nummer erst nach diesem Auszug geändert habt, und das vielleicht nicht auf die PLCs geladen habt?

Sowie Ich das sehe benutzt Step 7 noch folgende Subnetznummer: 0499-0009
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hab grad nochmals deinen Wireshark auszug angesehen...

Kann es sein das Ihr die Subnetz Nummer erst nach diesem Auszug geändert habt, und das vielleicht nicht auf die PLCs geladen habt?

Sowie Ich das sehe benutzt Step 7 noch folgende Subnetznummer: 0499-0009

Wir hatten am Anfang mit Subnetz-IDs in diesem Bereich (499 etc.) getestet. Der Wireshark-Auszug ist dann wohl aus diesem Zeitabschnitt. Da wir festgestellt haben, daß bei der zweiten ID teilweise auch Buchstaben (z. B. A oder C) auftauchten, haben wir vermutet, daß diese IDs hexadezimal angegeben sind und man die dann eventuell bei den Parametern in dezimal umrechnen muß. Um das als potentielle Fehlerquelle auszuschließen, haben wir dann Subnetz-IDs im einstelligen Bereich gewählt.

Ob es da bei der Aktualisierung auf den PLCs Probleme gegeben hat, kann ich nicht völlig ausschließen. Es hat allerdings auch schon vorher nicht funktioniert, weder mit den Subnetz-Ids wie sie in Step 7 angegeben wurden, noch nach Umrechnung in Dezimal. Und der Simatic Manager konnte ja weiter per Routing auf die zweite CPU zugreifen.

Ich melde mich auf jeden Fall noch mal, wenn ich wieder zu unserem Partner fahre.

Wäre denn wohl die Demo von AGLink geeignet, um zu testen, ob die PLCs korrekt konfiguriert sind?

Nochmal danke für Deine Hilfsbereitschaft!

Viele Grüße,

Thorsten
 
Wäre denn wohl die Demo von AGLink geeignet, um zu testen, ob die PLCs korrekt konfiguriert sind?

Auch ACCON-AGLink muss die korrekte Netznummern kennen, damit die Kommunikation über Routing funktioniert. Aber mal in der aktuellen Version von ACCON-AGLink im Konfigurationshandbuch nachschauen. Dort ist bei Routing genau beschrieben, was wo eingetragen werden muss. Auch das Problem Hex/Dez sollte da ersichtlich sein.
 
Auch ACCON-AGLink muss die korrekte Netznummern kennen, damit die Kommunikation über Routing funktioniert. Aber mal in der aktuellen Version von ACCON-AGLink im Konfigurationshandbuch nachschauen. Dort ist bei Routing genau beschrieben, was wo eingetragen werden muss. Auch das Problem Hex/Dez sollte da ersichtlich sein.

Danke, ich werde mir das im Handbuch ansehen.

Viele Grüße,

Thorsten
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Jochen,

Kannst mir ja mal vorher schreiben bevor du dort bist, wenns dann mit der neuen dll nicht geht, schickst mir mal ein wireshar auszug vom verbindungsaufbau mit dem simatic manager, und einen mit meinem connection programm.

wir haben jetzt auch bei uns im Haus ein S7-Netz aufgebaut, so daß wir das jetzt jederzeit testen können.

Unser Test mit dem neuen Netz ergibt folgendes Ergebnis:

ACCON-AGLink bekommt Verbindung zu der Steuerung, zu der geroutet werden soll (im folgenden Slave genannt), daher gehe ich davon aus, daß das Subnetz korrekt konfiguriert ist und die Routinginformationen in den CPUs eingetragen wurden.

Dein Testprogramm (TestLibrary.exe) bekommt genauso wie unsere Anwendung keine Verbindung zum Slave, sondern lediglich zum Master.

Die Subnetz-IDs sind diesmal: 005D-0001

MPI-Adresse des Slaves ist 3.

Bei beiden CPUs handelt es sich wieder um eine CPU 315-2 PN/DP, Rack und Slot sind jeweils 0 und 2.

Beim Vergleich der Wireshark-Auszüge fällt auf, daß ACCON-AGLink und die TestLibrary.exe nicht dasselbe schicken. Im folgenden poste ich mal die Auszüge, wo wohl die Daten für den Connect geschickt werden, im Anhang jeweils ein vollständiger Connect, bzw. Connect-Versuch. Dabei fällt auf, daß die Position, an der sich die Daten befinden, jeweils nicht identisch ist.

Bei AGLink wird z. B. die Information für Rack und Slot im letzten Byte übertragen, bei der TestLibrary.exe im viertletzten (das habe ich durch Änderungen an diesen Werten herausgefunden). Die drei letzten Bytes, die die TestLibrary.exe überträgt, kann ich im Auszug für AGLink nicht wiederfinden. Insgesamt wird aber die gleiche Anzahl an Bytes übertragen. Wobei ich sagen muß, daß ich nun nicht sagen kann, ob dieser Unterschied eine Rolle spielt oder nicht. Vielleicht kannst Du ja was damit anfangen. Als Verbindungsart wurde jeweils TCP bzw. ISO over TCP ausgewählt. Das Betriebssystem des Rechners ist Windows XP, 32 Bit.

Für unsere Applikation habe ich im Moment keinen Wireshark-Auszug, da sie auf einem anderen Rechner läuft. Bei Bedarf kann ich den aber morgen nachliefern.

Hier Teile der Wireshark-Auszüge:

ACCON-AGLink:
666-681

669:
0030 ff ff 85 52 00 00 03 00 00 4a 45 e0 00 00 00 08 ...R.... .JE.....
0040 00 c0 01 0a c1 1c 01 00 00 02 00 00 00 00 00 00 ........ ........
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0060 02 00 c2 1c 01 06 01 02 00 5d 00 00 00 01 03 00 ........ .]......
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 02 ........ ........


TestLibrary.exe mit DLL vom 6. 8.:
1540-1547

1543:
0030 ff ff 85 52 00 00 03 00 00 4a 45 e0 00 00 00 01 ...R.... .JE.....
0040 00 c1 1c 01 00 00 02 00 00 00 00 00 00 00 00 00 ........ ........
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 01 02 c2 ........ ........
0060 1c 01 06 01 02 5d 00 00 00 01 00 03 00 00 00 00 .....].. ........
0070 00 00 00 00 00 00 00 00 00 00 00 01 02 c0 01 09 ........ ........


TestLibrary.exe mit DLL vom 23. 7.
3085-3090

3088:
0030 ff ff 85 52 00 00 03 00 00 4a 45 e0 00 00 00 01 ...R.... .JE.....
0040 00 c1 1c 01 00 00 02 01 02 00 00 00 00 00 00 00 ........ ........
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 c2 ........ ........
0060 1c 01 06 01 02 5d 00 00 00 01 00 03 00 00 00 00 .....].. ........
0070 00 00 00 00 00 00 00 00 00 00 00 01 02 c0 01 09 ........ ........

Viele Grüße,

Thorsten
 

Anhänge

  • S7RoutingN2.zip
    1,1 KB · Aufrufe: 7
Hallo Jochen,



wir haben jetzt auch bei uns im Haus ein S7-Netz aufgebaut, so daß wir das jetzt jederzeit testen können.

Unser Test mit dem neuen Netz ergibt folgendes Ergebnis:

ACCON-AGLink bekommt Verbindung zu der Steuerung, zu der geroutet werden soll (im folgenden Slave genannt), daher gehe ich davon aus, daß das Subnetz korrekt konfiguriert ist und die Routinginformationen in den CPUs eingetragen wurden.

Dein Testprogramm (TestLibrary.exe) bekommt genauso wie unsere Anwendung keine Verbindung zum Slave, sondern lediglich zum Master.

Die Subnetz-IDs sind diesmal: 005D-0001

MPI-Adresse des Slaves ist 3.

Bei beiden CPUs handelt es sich wieder um eine CPU 315-2 PN/DP, Rack und Slot sind jeweils 0 und 2.

Beim Vergleich der Wireshark-Auszüge fällt auf, daß ACCON-AGLink und die TestLibrary.exe nicht dasselbe schicken. Im folgenden poste ich mal die Auszüge, wo wohl die Daten für den Connect geschickt werden, im Anhang jeweils ein vollständiger Connect, bzw. Connect-Versuch. Dabei fällt auf, daß die Position, an der sich die Daten befinden, jeweils nicht identisch ist.

Bei AGLink wird z. B. die Information für Rack und Slot im letzten Byte übertragen, bei der TestLibrary.exe im viertletzten (das habe ich durch Änderungen an diesen Werten herausgefunden). Die drei letzten Bytes, die die TestLibrary.exe überträgt, kann ich im Auszug für AGLink nicht wiederfinden. Insgesamt wird aber die gleiche Anzahl an Bytes übertragen. Wobei ich sagen muß, daß ich nun nicht sagen kann, ob dieser Unterschied eine Rolle spielt oder nicht. Vielleicht kannst Du ja was damit anfangen. Als Verbindungsart wurde jeweils TCP bzw. ISO over TCP ausgewählt. Das Betriebssystem des Rechners ist Windows XP, 32 Bit.

Für unsere Applikation habe ich im Moment keinen Wireshark-Auszug, da sie auf einem anderen Rechner läuft. Bei Bedarf kann ich den aber morgen nachliefern.

Hier Teile der Wireshark-Auszüge:

ACCON-AGLink:
666-681

669:
0030 ff ff 85 52 00 00 03 00 00 4a 45 e0 00 00 00 08 ...R.... .JE.....
0040 00 c0 01 0a c1 1c 01 00 00 02 00 00 00 00 00 00 ........ ........
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0060 02 00 c2 1c 01 06 01 02 00 5d 00 00 00 01 03 00 ........ .]......
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 02 ........ ........


TestLibrary.exe mit DLL vom 6. 8.:
1540-1547

1543:
0030 ff ff 85 52 00 00 03 00 00 4a 45 e0 00 00 00 01 ...R.... .JE.....
0040 00 c1 1c 01 00 00 02 00 00 00 00 00 00 00 00 00 ........ ........
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 01 02 c2 ........ ........
0060 1c 01 06 01 02 5d 00 00 00 01 00 03 00 00 00 00 .....].. ........
0070 00 00 00 00 00 00 00 00 00 00 00 01 02 c0 01 09 ........ ........


TestLibrary.exe mit DLL vom 23. 7.
3085-3090

3088:
0030 ff ff 85 52 00 00 03 00 00 4a 45 e0 00 00 00 01 ...R.... .JE.....
0040 00 c1 1c 01 00 00 02 01 02 00 00 00 00 00 00 00 ........ ........
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 c2 ........ ........
0060 1c 01 06 01 02 5d 00 00 00 01 00 03 00 00 00 00 .....].. ........
0070 00 00 00 00 00 00 00 00 00 00 00 01 02 c0 01 09 ........ ........

Viele Grüße,

Thorsten

In deinem Wireshark auszug, sind de Zeilen nicht enthalten!
 
Ahhh...

So wie ich das sehe,, hab Ich schonmal bei der SubnetzID Low und HighByte vertauscht (habs immer mit AAAA-BBBB getestet, da fällt das natürlich nicht auf!). Wenn, dann hab Ich das warscheinlich bei allen Connections falsch... Der Rest, weis Ich nun auch nicht, Ich hats im Büro ja schon am laufen... Hab das mit dem Subnetz mal geändert, den Rest Teste ich mal morgen im Büro.
 

Anhänge

  • libnodave.zip
    72,4 KB · Aufrufe: 11
Zuviel Werbung?
-> Hier kostenlos registrieren
Bei AGLink wird z. B. die Information für Rack und Slot im letzten Byte übertragen, bei der TestLibrary.exe im viertletzten (das habe ich durch Änderungen an diesen Werten herausgefunden). Die drei letzten Bytes, die die TestLibrary.exe überträgt, kann ich im Auszug für AGLink nicht wiederfinden.

Das wiederum macht nichts, da die 3 letzten Bytes ein andere Parameter sind, welchen AG Link als erstes überträgt, daher sollte das kein Problem sein (Die Parameter beginnen mit c0, c1, c2).
 
Hallo Jochen,

In deinem Wireshark auszug, sind de Zeilen nicht enthalten!

Sorry für die Verwirrung. Die Zeilen haben nach dem Abspeichern neue Nummern erhalten, das war mir nicht bewußt.

Hab das mit dem Subnetz mal geändert, den Rest Teste ich mal morgen im Büro.

vielen Dank! Mit der neuen DLL funktioniert es jetzt, sowohl mit Deinem Testprogramm, als auch mit unserer Applikation.

Viele Grüße,

Thorsten

PS:

Für andere, die das Routing auch von Pascal oder Delphi aus nutzen möchte, hänge ich mal die von uns dafür geänderte Delphi-Header-Datei, nodave.pas, an. Ohne Gewähr, daß sie auch bei anderen funktioniert. Außerdem weise ich darauf hin, daß die Datei nicht alle Funktionen der Libnodave unterstützt, da bis auf unsere Änderungen für das Routing die letzte Änderung wohl von 2007 ist, so daß neuere Änderungen in der Libnodave noch nicht nachgezogen wurden.
 

Anhänge

  • nodave.zip
    9,7 KB · Aufrufe: 9
Hallo Jochen,



Sorry für die Verwirrung. Die Zeilen haben nach dem Abspeichern neue Nummern erhalten, das war mir nicht bewußt.



vielen Dank! Mit der neuen DLL funktioniert es jetzt, sowohl mit Deinem Testprogramm, als auch mit unserer Applikation.

Viele Grüße,

Thorsten

PS:

Für andere, die das Routing auch von Pascal oder Delphi aus nutzen möchte, hänge ich mal die von uns dafür geänderte Delphi-Header-Datei, nodave.pas, an. Ohne Gewähr, daß sie auch bei anderen funktioniert. Außerdem weise ich darauf hin, daß die Datei nicht alle Funktionen der Libnodave unterstützt, da bis auf unsere Änderungen für das Routing die letzte Änderung wohl von 2007 ist, so daß neuere Änderungen in der Libnodave noch nicht nachgezogen wurden.

Schön zu hören das es jetzt geht... Ich werd die änderungen heute noch bei den anderen Verbindungsarten nachziehen, und dann mal wieder auf meiner Homepage online stellen. War auch blöd von mir das nur mit aaaa-bbbb zu testen, so fällt das natürlich nicht auf...
 
Zurück
Oben