ProfiLab via TCP mit anderen Anwendungen verbinden

Antworten
tom_g
Beiträge: 215
Registriert: Freitag 31. Oktober 2008, 14:59

ProfiLab via TCP mit anderen Anwendungen verbinden

Beitrag von tom_g » Dienstag 12. Januar 2010, 15:52

ProfiLab TCP sockets werden verwendet, um 2 oder mehrere getrennte ProfiLab-Anwendungen via TCP (auf demselben Rechner = local host) oder via Intra/Internet zu verbinden.

Auch RealView verfügt über "TCP client", um von ProfiLab via "TCP server" Messdaten zu erfassen.

Meine Motivation besteht darin, andere Anwendungen mittels TCP an ProfiLab anzubinden. Zwar bietet ProfiLab mit dem Aufruf von DLLs eine leistungsfähige Codeschnittstelle für beliebige Erweiterungen unter Einsatz von C/C++ .
Persönlich kenne ich aber ein anderes Werkzeug besser, und dieses möchte ich denn auch nutzen.

Datenaustausch mit ProfiLab TCP
Dazu ist es zunächst notwendig, das Verfahren des Datenaustausches (Telegramm) zu kennen. Meinen diesbezüglichen heutigen Kenntnisstand möchte ich dem Forum nicht vorenthalten, und bitte Abacom bei Inkonsistenz um Korrektur.

ProfiLab TCP verwendet zum Glück (bisher = V4) ein sehr einfaches Datenaustauschverfahren.

Das Verhalten lässt sich mit TCPViewer (http://www.westbrooksoftware.com) an der leicht modifizierten Demo (client muss auf port 30001)
"\Programme\ProfiLab-Expert40\Beispiele\Neue_Funktionen\TCP\Local_Host" schnell austesten

Es wird keine Kommandoschicht verwendet, es werden direkt Variablen-Daten ausgetauscht.

ProfiLab TCP client sendet ein 16 Byte Datenpaket über Winsock (falls an einen Server verbunden), sobald sich der Eingangswert TX ändert.
ProfiLab TCP client empfängt ein 16 Byte Datenpaket, welches vom Server umgehend oder irgendwann versendet wird.
Es ist nicht zwingend, auf einen "client request" eine "server reply" absetzen zu müssen und umgekehrt auch nicht, wenn der Server aktiv Daten an den client senden kann.
Für ProfiLab TCP server verhält sich die Sache genauso.

Das Datenpaket setzt sich zusammen aus den ersten 10 Bytes [1..10] = TX-Variable , und einem Byte [12] = Kanaladresse
Die Daten werden im "extended float Format" (double double) übermittelt, d.h. ein Floatingpoint Wert, dargestellt mit 80bits, das erlaubt sehr grosse Zahlen mit hoher Auflösung.
Die restlichen Bytes scheinen unbelegt zu sein.

Beispiel: CD CC CC CC CC CC CC 8C FF 3F 00 07 00 00 00 00

Der "analog" mode, wie auch der "digital" mode übertragen einen einzigen FP-Wert, wobei der digital mode die Summe der (gesetzten) Bitwertigkeiten + 0.1 darstellt.

Da in anderen Anwendungen der extended float oft nicht zur Verfügung steht, dafür nur der kürzere long float (64 bit), muss im Server eine Konversion zwischen extended float und long float durchgeführt werden
(Infos wie: bitConverter as described by: http://www.codeproject.com/KB/cs/longdouble.aspx -- tnx to Nathan Baulch !)
und bei http://www.umnicom.de/Elektronik/Sonsti ... ap513.html

Konkrete Server Anwendung mit Euphoria

Euphoria V3.1 ist eine von vielen Programmiersprachen. (http://www.rapideuphoria.com)
Sie ist Freeware/Opensource/OpenCommunity, gut dokumentiert und vereint diverse Vorteile aus C, Pascal, Basic.
Sie ist für interpretierten Code extrem schnell, hat bemerkenswerte Datentypeneinfachheit und den extraordinären dynamischen Array, genannt "sequenz". Es existieren viele Libraries, darunter die win32lib, welche den Zugriff auf das Windows Betriebssystem ermöglicht. Anwendungen in Euphoria lassen sich in Sekunden editieren und zum Test unmittelbar aus dem Editor danach interpretieren. Ein Debugger erlaubt
leistungsfähiges Entkäfern. Die Fehlermeldungen sind sensationell zielweisend. Ein Fehlerdump kann helfen, Laufzeitfehler zu entschlüsseln.
Für mich ganz einfach DER Hit.

Der von mir realisierte Euphoria-TCP Server benutzt eine TCP-Library, damit reduziert sich der Kern der Anwendung auf wenige Zeilen. Ein kleines GUI erlaubt den Status, einen Monitor und 2 Server-Modi zu wählen:

ProfLab mode und RealView mode
Im ProfiLab mode wartet der Server auf ein Datenpaket von einem ProfiLab client. Ein solches Paket enthält bekanntlich einen floating point Variablenwert und die Kanaladresse des clients. Sobald ein Paket empfangen wurde, wird der extended float in einen long float gewandelt, und der Wert in ein Eingangs-Array gespeichert.
Dann wird eine Verarbeitung vorgenommen, und der Resultatwert in ein Ausgangsarray gespeichert. Danach wird der Ausgangswert aus dem array via TCP zurück zum ProfiLab client "serviert". Für ProfiLab resultiert damit "Euphoria-in-the-loop"

Genau um diese Verarbeitung von Eingangs- zu Ausgangsdaten geht es ja: in ProfiLab sind gewisse Dinge nicht sehr elegant oder gar nicht realisierbar (ausser eben durch Einsatz von DLLs). Die Verbindung der grafischen mit einer formalen Programmierumgebung erhöht die Flexibilität meiner Meinung nach deutlich.

Natürlich bestehen Einschränkungen: Geschwindigkeit, keine Stringfähigkeit, somit ist der Einsatz der Euphoria-Serveranwendung mit gutem Gewissen für Raten < 100 Hz und für numerische Verarbeitung geeignet.

Ganz nebenbei (weil RealView dieselbe Datenschnittstelle aufweist) bekommen Anwendungen in Euphoria einen leistungsfähigen Trender/Logger, wenn RealView zur Datenvisualisierung benutzt wird. Dann kommt der RealView mode zum Zuge: der Server sendet aktiv (und nicht als "Transponder") mit seiner eigenen Zeitbasis adressierte Variablen zu RealView.

Was ich hier erläutere, kann natürlich mit dem Wissen, wie ProfiLab TCP aufgebaut ist, mit anderen Windows-Programmiersprachen genauso gut umgesetzt werden (VisualBasic...)

Als eine von vielen möglichen Anwendungen sehe ich die Einbindung von Hardware, wobei der Gerätetreiber im Server programmiert wird (sei das ein HP34970 Datenlogger oder ein Modem oder ...) weil diese Aufgabe nur sinnvoll in formaler Umgebung vorgenommen werden kann. Ein anderes konkretes Beispiel wäre die kubische Regression zu berechnen, weil solche Math-Funktionen in ProfiLab nicht verfügbar sind. USW





Bei Interesse kann ich den Euphoria-zu-ProfiLab-Server und eine PL-Demo gerne hochladen.

Hat jemand unter Euch ähnliche Erfahrungen/Entwicklungen gemacht ?
Bitte melden. Viele Grüsse von Thomas
Curiousity makes us progress !

abacom
Site Admin
Beiträge: 3428
Registriert: Dienstag 23. September 2008, 10:54
Kontaktdaten:

Re: ProfiLab via TCP mit anderen Anwendungen verbinden

Beitrag von abacom » Mittwoch 13. Januar 2010, 09:21

Alles schön und gut. Viel Mühe die tom_g sich gemacht hat.
Wir können aber weder die Richtigkeit noch für die Langlebigkeit des internen Protokolls garantieren.
Wenn man sich schon so viel Mühe mit der Programmierung macht, wäre es sicher besser
z.B. einen ModBus[TCP]-Server in der eigenen Anwendung unterzubringen.
Da hat man ein verlässliches Protokoll, das zudem auch noch universeller ist.
Noch schicker (aber sehr Aufwendig) wäre es die eigene Anwendung als OPC-Server auszulegen.
Wesentlich einfacher besteht auch noch der Weg über virtuelle COM-Kabel Daten auszutauschen.
Siehe auch...
viewtopic.php?f=21&t=1043&p=2197&hilit=com0com#p2197
ABACOM support

tom_g
Beiträge: 215
Registriert: Freitag 31. Oktober 2008, 14:59

Re: ProfiLab via TCP (ModBus) mit Euphoria Server verbinden

Beitrag von tom_g » Donnerstag 14. Januar 2010, 16:04

Hallo Abacom,
vielen Dank für die Antwort. Zu ProfiLab TCP war mir klar, dass das Protokoll proprietär und möglichen Aenderungen unterworfen ist.

ModBus TCP finde ich einen guter Vorschlag, weil damit auch viele andere Automatisierungsumgebungen ansprechbar werden.

Ich habe mich deshalb drangemacht, einen ModBus TCP Server in Euphoria zu programmieren. Ich habe zu Beginn nur mal die FC1 (read coils) Funktion realisiert.

Gleich zu "Erfolgsbeginn" stelle ich aber fest, dass nach erfolgreichem Connect (CN = aktiv) und (= kein ERR meine CPU durch ProfiLab (ersichtlich im TaskManager) an den Anschlag ausgelastet wird. Ich kann immerhin testweise mit 100Hz Clock an FC1 client Telegramme austauschen, aber eben bei "full load", ProfiLab zeigt bei niedriger Ausführpriorität einen Abarbeitungszyklus von niedrigen 150 Hz, welche auf meinem Rechner sonst um 500 Hz liegen.

Weil dieselbe "sockets" Umgebung hier zur Anwendung kommt, welche beim vorgängig beschriebenen ProfiLab TCP server und beim ProfiLab client dieses Phänomen nicht zeigt, denke ich an den ModBus client als Verursacher.

Ist Ihnen das Verhalten bekannt, oder haben Sie einen Hinweis, woran das liegen könnte ?

Vielen Dank für Ihre Hilfe, mit freundlichen Grüssen:
Thomas
Curiousity makes us progress !

BKGMX
Beiträge: 132
Registriert: Montag 7. Dezember 2009, 10:37
Wohnort: Berlin

Re: ProfiLab via TCP mit anderen Anwendungen verbinden

Beitrag von BKGMX » Dienstag 19. Januar 2010, 12:54

Hallo tom_g,

für die digitale Verarbeitung hatte ich mir auch mal unter Delphi einen externen TCP-Server
erstellt, bei der analogen Übertragung bin ich aber dann gescheitert, da ich auf "extended float"
nicht gekommen bin. Falls Du Interesse hast, könnten wir da zusammen weiterarbeiten.
Ziel ist eigentlich, einen beliebigen Controller mit TCP-Socket (z.B. PIC) über Profilab anzusteuern.

Gruß BK

Das Beispiel ist leider zu groß um es hier hochzuladen.

tom_g
Beiträge: 215
Registriert: Freitag 31. Oktober 2008, 14:59

Re: ProfiLab via TCP mit anderen Anwendungen verbinden

Beitrag von tom_g » Mittwoch 20. Januar 2010, 20:45

Guten Abend <BKGMX>

ich lege hier gerne den source code bei, denn ich habe den code für mich teilweise dokumentiert, darin sind auch zwei Funktionen (function float80_to_atom( sequence e )) und (function Double_to_LongDouble(atom val)), welche Sie vielleicht interessieren. Delphi unterstützt den Datentyp extended float direkt, in Euphoria gibts nur den double, so muss ich die 10 bytes des exteded float in Form eines Datentyp_converters behandeln. Mal übertragen, steht dem "gateway" zu PIC (dann wohl über einen seriellen Port nichts mehr entgegen. Wichtig hier ist, wie ProfiLab TCP funktioniert.
Ich hoffe, für Ihr Projekt etwas Motivation eingebracht zu haben ?

PS: ich weiss nicht, wieso dass uploads als *.exw oder *.txt nicht akzeptiert werden. Als *.prj gehts. Die source ist zwar nur Text, allerdings für Edita (Euphoria-Editor) und für den Euphoria Interpreter müsste sie in *.exw umbenannt werden. Die include libraries habe ich natürlich nicht mitangehängt...

Mit freundlichen Grüssen:

Thomas
Dateianhänge
ProfiLab_TCP_server.prj
(25.16 KiB) 521-mal heruntergeladen
Curiousity makes us progress !

BKGMX
Beiträge: 132
Registriert: Montag 7. Dezember 2009, 10:37
Wohnort: Berlin

Re: ProfiLab via TCP mit anderen Anwendungen verbinden

Beitrag von BKGMX » Donnerstag 21. Januar 2010, 19:25

Hallo tom_g,
habe mir das mal runtergeladen, bin allerdings noch nicht zum anschauen gekommen.
Bei der PIC hatte ich eigentlich an so eine der neuen PIC32 mit Ethernet gedacht.
Dann könnte ich mal meine XPorts ausmustern, da die Ansteuerung über virtuelle COM-Ports doch immer sehr fehleranfällig ist.

Vielen Dank

Antworten

Zurück zu „Datenschnittstellen“