ProfiLab via TCP mit anderen Anwendungen verbinden
Verfasst: 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
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