TCP/IP-Telegrammverkehr mit Anlagensteuerung/SPS

[Nico B.]

Hallo zusammen,

ich habe leider keine Ahnung, ob ich hier das richtige Unterforum erwischt habe, da ich auch nicht so richtig Themen zu ähnlichen Problemen hier gefunden habe. Also falls es nicht passt, wäre ich froh, wenn ihr den Thread einfach ins passende Unterforum verschieben könntet.

Nun aber zu meinem Problem.
Ich möchte gern eine Deplhi-Anwendung schreiben, die mit einer Anlagensteuerung/SPS per TCP/IP-Telegramm Daten austauschen kann. Falls es dazu irgendwelche Tutorials oder ähnliches gibt, wäre ich sehr begeistert, wenn ihr mir einen Tipp geben könntet, wo ich die finde. Oder wenigstens nach was ich suchen muss…

Vielen Dank schon mal.
Nico

[sirius]

Ein Tutorial kenne ich nicht (außer die üblichen TCP / Socket Tuts). Aber das was du vor hast, dürfte nicht all zu schwer sein.

Du brauchst einen TCP-Client (da gibt es ja einige) und fängst mal an eine Verbindung aufzubauen. Meist kannst du auch gleich den Status o.ä. abfragen.


Hier mal ein Grundgerüst zum rumspielen:

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, scktcomp, StdCtrls;

type
  TForm1 = class(TForm)
    Memo1: TMemo;
    Button1: TButton;
    Edit1: TEdit;
    procedure FormCreate(Sender: TObject);
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
    FClient:TClientSocket;
    procedure ClientRead(Sender:TObject; Socket: TCustomWinSocket);
    procedure ClientError(Sender:TObject; Socket: TCustomWinSocket;
      ErrorEvent: TErrorEvent; var ErrorCode: Integer);
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.ClientError(Sender: TObject; Socket: TCustomWinSocket;
  ErrorEvent: TErrorEvent; var ErrorCode: Integer);
begin
  showmessage(syserrormessage(Errorcode));
end;

procedure TForm1.ClientRead(Sender: TObject;
  Socket: TCustomWinSocket);
begin
  memo1.Lines.add(socket.ReceiveText);
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  Fclient:=TClientSocket.Create(self);
  FClient.Address:='127.0.0.1';
  FClient.Port:=5000;
  FClient.ClientType:=ctNonBlocking;
  FClient.OnRead:=ClientRead;
  FClient.OnError:=ClientError;
  FClient.Open;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  FClient.Socket.SendText(Edit1.text);
end;

end.

[DeddyH]

Crosspost Entwickler-Ecke

[Medium]

Die wichtigere Frage ist, welche SPS du da hast, und welche Protokolle sie an ihren Schnittstellen unterstützt. Man kann sich dann ggf. einen ganzen Batzen Arbeit ersparen, wenn man z.B. die libnodave DLL einsetzt (im Fall von Siemens SPSen). Bevor man anfängt ein möglicherweise sehr umfangreiches Protokoll selber zu implementieren, würde ich zunächst danach schauen.

[Nico B.]

Hallo zusammen,
danke schon mal für die vielen Antworten.
Ich werde mich jetzt also an libnodave versuchen.
Dafür habe ich zuerst libnodave 0.8.5 runtergeladen.
Leider scheitere ich schon wieder an der Installation des Packages unter Delphi 2006.
In der Anleitung aus dem Download heißt es:
1. Select Component - Install in tehe Delphi-menu
2. Select Add... button
3. Select Browse
4. Select NoDave Component.pas
5. Select OK
Bei 4. hakt es schon, da hier nur BPL-Dateien ausgewählt werden können.
Eine solche Datei gibt es aber leider im gesamten Download nicht.
Was muss ich tun?

[Medium]

Da ist die Beschreibung etwas blödelig. Man kann nur Packages installieren, keine einzelnen pas Files. Im Zweifel musst du selbst ein Projekt anlegen und die nötigen Dateien hinzufügen und das ganze als Package (bpl) kompilieren, wenn dem Download nicht schon eine Projektdatei beiliegt mit der dies erzeugt wird.

Was mich gerade nur irritiert ist, dass ich, als ich die libnodave vor ca. 2 Jahren das letzte mal runter geladen haben, keine VCL Komponenten dabei hatte. Das war einfach nur eine DLL und eine PAS mit den Wrappern. Ich hatte zur Vereinfachung dann nachher noch eine Komponente eines Users im SPS Forum gefunden, aber die war separat. Ich muss mir die noch mal ansehen glaub ich :)

[Nico B.]

Ich bekomme das einfach nicht hin.
Ich erstelle ein neues Projekt:
Datei > Neu > Package - Delphi für Win32
Das speichere ich als Package1.bdsproj

Nun füge ich die Datei nadavecomponent.pas dem Projekt hinzu.
Speichern.
Package1 compilieren
Package1 erzeugen....

Aber nirgendwo entsteht eine BPL-Datei.

[Nico B.]

Okay, ich glaub jetzt hab ich´s geschafft.
Ich habe hier
http://engbarth.es/?page_id=165
eine Version von LibNoDave heruntergeladen, die speziell für Delphi 2009/2010/XE/XE2 angepasst wurde. Darin habe ich nun ein Package-Projekt gefunden, das ich installieren konnte.

[schöni]

Die BPL Datei steht standardmäßig in /Projects/Bpl

[divBy0]

Hallo,
schön, dass du meine Seite gefunden hast.
Du musst nicht unbedingt LibNoDave nutzen um Daten mit einer S7 auszutauschen, du kannst auch die Indy-Komponenten nutzen, da die S7 auch TCP und UDP kann. Dazu einfach eine Verbindung in der S7 projektieren, entweder über NetPro oder eine offene Industrial-Ethernet-Verbindung mit dem Open-Communication-Wizard und den entsprechenden TConnect-, TDisconnect-, TSend-, TReceive-, usw. -Funktionen.

Die S7 ist im einfachsten Fall der Server und die Anwendung der Client, so müssen Daten nicht immer erst angefragt werden.

[Medium]

Für projektierte Verbindungen braucht es aber immer einen CP, oder nicht? Wir nutzen hier mittlerweile fast nur noch ISO-over-TCP bzw. S7Online, und kommen mit CPUs aus die eine Ethernetschnittstelle haben. Zumal dabei die verbundenen Clients nicht limitiert sind wie bei projektierten Verbindungen (wir nutzen meist nur einen, aber ein dezentraleres System ist im Moment in Planung).
Das Polling ist zwar anfangs nervig, aber wenn man sich ein Mal einen vernünftigen Unterbau geschaffen hat ist alles prima. Gut, am Ende wieder alles Abwägungssache für den konkreten Einsatzzweck :)

[divBy0]

Einen CP brauchst du nicht unbedingt, es kommt halt auf die Verbindung und Anzahl an.

Eine 314-2PNDP kann 8 Verbindungen TCP, UDP oder ISO-on-TCP, laut Datenblatt (siehe Anhang).

TCP und UDP kannst du auch ohne CP nutzen, dann musst die Verbindung wie gesagt über TConnect, TDisconnect, usw. aufbauen. Was auch Vorteile hat, da du z.B. die Ziel IP oder Portnummer ändern kannst ohne die Hardware neu übertragen zu müssen, also während dem Betrieb der Anlage.

Es kommt halt immer auf den Einsatzzweck an, zum Protokolieren bietet sich die Variante über offene Kommunikation an, da sich die Prozessdaten in der Produktion in ihrer Länge ja nicht ändern. SPS ist der TCP-Server, Anwendung der TCP-Client, die Anwendung verbindet sich zur SPS, kann sich authentifizieren und die SPS sendet dann die Daten zum Client.

Wenn man sich jetzt mal den Kommunikationsaufwand aufschaut stellt man schon fest, dass man da einiges einsparen kann.

Beispiel TCP:

- Anwendung verbindet zur Steuerung.
- Steuerung sendet Daten wenn diese bereit stehen.

Beispiel LibNoDave:

- Anwendung verbindet zur Steuerung.
- Anwendung fragt zyklisch bei der Steuerung an, ob neue Daten bereit stehen.
- Steuerung antwortet, auch wenn keine Daten bereitstehen.

[Nico B.]

Hallo Leute,
also erst mal... Ich find´s ja total klasse, hier so gut informierte Leute erwischt zu haben. Da sollte es ja kein Problem mein bisl Kleinkram zu lösen.

Ich für meinen Teil hab (nachdem ich zunächst ein wenig mit sirius Quellcode experimentiert habe und mir anschließend das libnodave-Beispiel angeschaut habe) auch langsam das Gefühl das libnodave schon ein wenig zu weit geht.
Ich will nicht auf Datenbausteine einer SPS zugreifen.
Mir reicht schon ein einfacher TCP/IP-Telegrammverkehr.

Mein Frage ist nun, wenn ich mit dem Quellcode von sirius weitermache, komme ich dann auch zum Ziel?
Mit TClientSocket und TServerSocket kann ich ja verschiedene Daten senden.

Könnt ihr mal sagen, ob das funktionieren würde?

Codebeispiel für das Versenden eines Telegramms von Delphi zur SPS:

Code:

FClient:=TClientSocket.Create(self);
try
  FClient.Adress:='0.8.1.5'; //IP der SPS
  FClient.Port:=5000;        //Port über den kommuniziert werden soll
  FClient.ClientType:=ctNonBlocking;
  FClient.Open;
  FClient.Socket.SendText('Hallo SPS');
finally
  FClient.Free;
end;

Codebeispiel für das Empfangen eines Telgramms von der SPS durch Delphi:

Code:

//Serververbindung herstellen
FServer:=TServerSocket.Create(self);
try
  FServer.Port:=5001;        //Port über den kommuniziert werden soll
  FServer.OnClientRead:=ServerRead;
  FServer.Open;
except
  FServer.Free;
end;

//Telgramm empfangen
procedure ServerRead(Sender: TObject; Socket: TCustomWinSocket);
begin
  Memo1.Lines.Add(Socket.ReceiveText);
end;

//TServerSocket vor Beenden im OnDestroy der Form freigeben
FServer.Free;

Vor allem bin ich mir ja unsicher, ob SendText die richtige Methode ist.
Vielleicht müsste/sollte ich besser SendStream oder SendBuf nehmen.
Wie ist eure Meinung dazu?

[Buddelfish]

Ich würde die per 'Close' noch explizit schließen. Aber grundsätzlich musst Du das Unit of Work Konzept hier nicht anwenden, d.h. Du schmeißt den Client auf dein Formular, öffnest ihn und wenn Du was schicken willst, schickst Du einfach. Wenn die Verbindung offen bleiben soll, dann würde ich mir über ein 'Keep Alive' Gedanken machen, d.h. der Client schickt an den Servcer 1x pro Sekunde (oder seltener) ein 'X' und der Server antwortet mit einem 'Y'. Kommt beim Client kein 'Y' stimmt was mit der Verbindung nicht und kommt nicht alle x Sekunden am Server kein 'X' stimmt auch was mit der Verbindung nicht. Beide können die Verbindung abbrechen und sich dann wieder verbinden.

Das mit dem 'X' und 'Y' ist nur exemplarisch, hier kann man noch eine laufende Nummer, Statusinformationen etc. reinpacken. Es soll halt nur kurz und in regelmäßigen Abständen passieren.

[Nico B.]

Okay, du meinst also so eine Art Watchdog.
Das würde ich auch definitiv implementieren.
Die Verbindung möchte ich über längere Zeit offen halten, da wäre so etwas sicher angebracht.

Jetzt frage ich mich aber noch, ob SendText wirklich das richtige ist bei der Kommunikation mit einer SPS...

[sirius]

1. Ich hoffe du hast keine 0815 IP genommen ;-) Und der Port ist auch entsprechend der Doku geändert wurden.

Ich habe noch nie mit einer SPS kommuniziert, aber mit verschiedenen anderen Geräten. Meistens weisen die Geräte auch ganz simple ASCII Protokolle auf, da ist ein SendText genug. Schreib doch mal ein bisschen vom Protokoll auf, was Du so senden musst.
Und wozu brauchst Du einen Server? Verbindet sich die SPS zurück?

[divBy0]

Warum nutzt du nicht die Indykomponenten?

Mit IdTCPClient.Socket.Write() kannst du einfach alles versenden was du brauchst, aber du musst dran denken, dass die Bytereihenfolge getauscht werden muss.

Bei der SPS gibt es kein Protokoll, du sendest einfach ein Array of Bytes mit deinen Inhalten. Die SPS empfängt und schreibt in die angegebenen Datenbausteine.

Einige Grundkenntnisse über die Datentypen in der SPS sollten vorhanden sein.