RealView 3.0 User Interface: ASCII Kommandos?

Antworten
Phineas
Beiträge: 6
Registriert: Freitag 1. April 2011, 17:42

RealView 3.0 User Interface: ASCII Kommandos?

Beitrag von Phineas » Freitag 1. April 2011, 17:55

Ich möchte über das RealView User Interface periodisch Daten von einem Sensor abrufen. Hierzu muss ich jedes mal ein ASCII Kommando senden. Mit einem Terminal Programm funktioniert dies einwandfrei. In RealView 3.0 habe ich leider keine Möglichkeit gefunden, für das User Interface Kommando Strings (HEX oder ASCII) zu definieren. Da der Zugriff auf einen COM Port jeweils nur von einem Programm aus möglich ist, kann ich nicht gleichzeitig ein Programm laufen lassen, das regelmäßig Kommandos generiert, während ich die empfangenen Daten mit RealView aufzeichne.

Hat jemand eine einfache Lösung für dieses Problem?

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

Re: RealView 3.0 User Interface: ASCII Kommandos?

Beitrag von tom_g » Donnerstag 14. April 2011, 07:23

Hi Phineas,

RealView liest den Buffer der seriellen Schnittstelle, worauf es konfiguriert ist.
Es versucht, numerische Werte aus den von Dir gesendeten Zeichen herauszuinterpretieren.

Das bedeutet insbesondere, dass Du den/die Anfragen zum Sensor in einer eigenen Anwendung selbst programieren musst. Geeignet wäre z.B. ProfiLab, oder Du machst was in einer anderen Programmiersprache.

Die Antwort des Sensors passt wohl nicht direkt an RealView, in Deiner Anwendung musst Du das geeignete Format selbst aufbereiten.

Das ganze zusätzliche Teil (diese nötige Anwendung) heisst dann Gateway und benötigt eine Schnittstelle zum Sensor, und eine weitere zum Übertragen an RealView. Das KANN ProfiLab.
Doch dann ist diese zweite Schnittstelle von Deiner Anwendung zum Senden der Daten "besetzt" - somit brauchst Du gar eine weitere Schnittstelle nur für RealView, welche diese selbst öffnet und auf ihr auf geeignete formatierte Daten horcht.
Für die Verbindung zwischen Deiner zweiten und der dritten von RealView brauchst Du typischerweise sog. "virtuelle Schnittstellen", welche nur in Software dasselbe Verhalten einer physikalischen seriellen UART emulieren und ein Werkzeug, welches diese Schnittstellen in Software verbinden kann wie ein Kabel.

Gut geeignet ist VSTE.
Lies zuerst weiter und finde den Link unten.

Wahrscheinlich ist Dir das ja klar.

Zitat aus der Hilfe:

"Programmbefehl im µC-Programm:
Print #1, CH1;"\";CH2;"\";CH3

Beispiel für die Ausgabe:
123\-1.234\1.23E-3
124\-1.235\1.24E-3
...

An diesem Pseudo-Programm erkannt man leicht den Aufbau des Protokolls:
Die numerischen Werte der zu übertragenen Kanäle sind als lesbarer ASCII-Text auf die Schnittstelle auszugeben.
Als Trennzeichen zwischen den Kanälen muss ein ein "\"-Zeichen (umgekehrter Schrägstrich; Backslash) verwendet werden.
Die Übertragung endet typischerweise mit der Zeichenkombination chr(13) chr(10).
Das Protokoll ist von uns fehlertolerant implementiert worden. So kann z.B. auch nur chr(13) oder nur chr(10) am Zeilenende stehen. Ebenso werden sowohl Komma und Punkt als Dezimalzeichen akzeptiert. Die Ausgabe vor- und nachstehender Zeichen, wie z.B. "I =-1,234 mA" liefert einen numerischen Zahlenwert von -1,234. Einheiten werden nicht verarbeitet. Voranstellung dürfen selbst keine numerischen Werte enthalten. So würde beispielsweise die Ausgabe von "Kanal 12 = 13.1 Volt" den numerischen Wert 12 statt 13,1 liefern!

Wenn Du nun einen uC programmiert hast, welcher dieses Format "spricht", und dieser direkt an eine serielle Schnittstelle oder an das USB-IF gesteckt ist als virtuelle Schnittstelle, dann kannst Du RealView auf diese Schnittstelle konfigurieren. RealView "horcht" und versucht zu verstehen :-)

Wenn Du aber den uC über eine Schnittstelle mit einer eigenen Anwendung einliest, und daraus eine Aufbereitung (Umwandlung) der empfangenen Werte programmiert hast, sieht das etwas anders aus.

Hierzu benötige ich mehr Angaben über Deine Umgebung.
Falls das Problem daran liegt, dass der uC an die erste Schnittstelle angeschlossen wurde und Du die aufbereiteten Daten über eine zweite Schnittstelle wegsendest (zu RealView), benötigst Du eine virtuelle Verbindung von dieser (von Deiner Anwendung geöffneten) Schnittstelle zu derjenigen, welche RealView öffnet. Das etspricht deFakto einem Kabel zwischen der zweiten und einer dritten seriellen Schnittstelle. Deine Anwendung für den uC wird Gateway genannt.
Diese Beschreibung entspricht vielleicht nicht Deinem Problem - daher mehr Info nötig.

An anderer Stelle (ProfiLab) in diesem Forum verdankenswerterweise von KAKTUS beschrieben, eigenet sich die Software VSPE http://www.eterlogic.com/ hierzu bestens und ist zudem noch Freeware.

Viel Glück - RealView ist wie auch ProfiLab ein super Teil !

Viele Grüsse von Thomas
Curiousity makes us progress !

Phineas
Beiträge: 6
Registriert: Freitag 1. April 2011, 17:42

Re: RealView 3.0 User Interface: ASCII Kommandos?

Beitrag von Phineas » Freitag 22. April 2011, 11:09

Hallo Thomas,

herzlichen Dank für deine ausführliche Beantwortung meiner Frage. Für mich (als ziemlicher 'Programmier-Laie' :oops: ) stellt sich die Situation so da (bitte korrigiere mich, wenn ich da was falsch verstanden habe):
- RealView bietet keine interne Möglichkeit Kommandos an eine serielle Schnittstelle zu senden
- einzige Möglichkeit ist der Einsatz eines anderen Programms (z.B. ProfiLab oder ein selbst erstelltes Programm) zur Generierung von Kommandos
- dieses Programm muss die Hardware allerdings über einen anderen (virtuellen) seriellen Port ansprechen, da ein Port bereits durch Abfrage durch RealView blockiert ist. Was ich nicht ganz verstanden habe ist die Notwendigkeit eines dritten Ports.

Zur Erläuterung meiner Anwendung:
Ich möchte einen intelligenten kommerziellen Drucksensor, der über ein RS485 I/F verfügt (dessen internen µC ich allerdings nicht programmieren kann), mit RealView abfragen. Mittels Adapter RS232-RS485 und einem Terminal Programm kann ich ein Kommando an den Sensor schicken und der empfangene String ist kompatibel mit den Formatierungsvorgaben des RealView User I/F. Leider lässt sich der Sensor nicht so programmieren, dass er ohne Kommando regelmäßig Datensätze sendet. Mit einem anderen Sensor, der dies kann, funktioniert die Messdatenerfassung unter RealView über das User I/F perfekt.

Wie ich deinen Ausführungen entnehme, gibt es offenbar keine einfache Lösung für mein Problem. Vielleicht wäre es eine hilfreiche Ergänzung für eine neue RealView Version, die Command String Funktion, die bereits in ProfiLab implementiert ist, in RealView zu portieren. Mir ist auf jeden Fall der von dir skizzierte Aufwand zu groß (bzw. übersteigt meine Programmier-Fähigkeiten).

Weiterer Hinweis: es gibt eine Menge intelligenter Sensoren mit seriellem I/F auf dem Markt, die sich gut für die Verwendung mit RealView eignen (würden). Was bereits sehr gut funktioniert ist die Einbindung von Messdatenerfassungs Modulen (z.B.) der ADAM-4000 Serie von Advantech mittels OPC Server.

Fohe Oster-Tage wünscht

Phineas

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

Re: RealView 3.0 User Interface: ASCII Kommandos?

Beitrag von tom_g » Samstag 23. April 2011, 09:04

Hoi Phineas,

Du hast alles richtig verstanden.

Wie gesagt, wenn Dein Sensor aktiv sendet, und das Format von RealView unterstützt, OK. Hierbei öffnet RealView die einzig nötige Schnittstelle und der Sensor "spricht" hinein.

Wenn der Sensor aber aufgefordert werden muss, seine Werte zu liefern, so muss z.B. ProfiLab die Schnittstelle zum Sensor öffnen, und zum Sensor "rufen". Dieser gibt danach Antwort, ProfiLab nimmt diese Antwort entgegen, formattiert sie (evt.) für RealView - und muss den Wert nun aktiv wegsenden. Das heisst, dazu muss ProfiLab die zweite Schnittstelle öffnen. Wenn nun RealView hört, so passiert das eben auf einer von RealView geöffneten Schnittstelle, und das kann nicht diejenige von ProfiLab sein -> hier eben der "Trick" mit virtuellen Schnittstellen und -kabeln.

Für diese Aufgabe ist das ProfiLab auch recht überdimensioniert, aber es kanns.
Tatsächlich recht umständlich, braucht schon etwas Übung.

Ich kann nicht beurteilen, wie schwierig es ist, sog. command strings in RealView zu implementieren, würde aus zwei Gesichtspunkten aber selbst eher skeptisch dazu stehen:

1. scheint mir das interne Timing von RealView "hohe Schule", d.h. super fein gelöst von Abacom (mehrere Multikanal Schreiber mit eigener Abtastung und Trigger möglich...). Eine solche zusätzliche Schnittstelle könnte dieses Timing durcheinanderbringen.
2. gibts natürlich Hardware wie Sand am Meer und keinerlei Protokollnormierung - das Gateway als Anpassungsfunktion wird somit immer nötig sein.


Du kannst mir das Protokoll des fraglichen Sensors ja mal durchreichen. Vielleicht kann ich ohne riesen Aufwand so eine Gateway (die Anwendung in ProfiLab) anprogrammieren. Es zu versuchen ja, aber bitte aber ohne mein Versprechen, dies auch zu schaffen.
Es wäre in diesem Bereich aber natürlich schon vorteilhaft, mit der entsprechenden Hardware zusammen zu entwickeln, aus Erfahrung gibts immer kleine Häklein (hooks), vor allem mit der guten alten seriellen Schnittstelle ;-)
Hast Du überhaupt ProfiLab ? Sonst müsste ich es als exe versuchen.

Freundliche Grüsse von Thomas
Curiousity makes us progress !

Phineas
Beiträge: 6
Registriert: Freitag 1. April 2011, 17:42

Re: RealView 3.0 User Interface: ASCII Kommandos?

Beitrag von Phineas » Donnerstag 28. April 2011, 21:16

Hallo Thomas,

herzlichen Dank für dein Angebot; vielleicht komme ich später noch mal darauf zurück. Ich habe zwar eine lizensierte Version von ProfiLab, bislang aber kaum damit gearbeitet. Falls du ein grundsätzliches Interesse an der Thematik hast: hier zwei Links, die den 'sensorischen Hintergrund' beleuchten:

der Drucksensor, den ich gerne mit RealView abfragen würde, ist von Keller (Modell PAA-33X). Die RS4585 Schnittstelle (und eine frei verfügbare DLL) sind beschrieben unter: http://www.keller-druck.ch/frame.asp?se ... ad30g.html

Mit der PROG30/READ30 Software kann ich problemlos den Sensor konfigurieren bzw. Daten aufzeichnen. Leider gibt es keine Möglichkeit, den Sensor ohne Kommando periodisch Daten ausspucken zu lassen. Mit der Einbindung von DLLs habe ich gar keine Erfahrung; ich weiß auch nicht ob so was mit RealView überhaupt geht (aber dem Ingeniör ist nichts zu schwör ;-)).

Ein (vielleicht) etwas einfacheres Problem ist die Abfrage von Daten von einer ADAM-4011D Messdatenerfassung (ASCII-Protokoll). Informationen hierzu findest du unter http://origindownload.advantech.com//pr ... al_V15.pdf . Um einen Wert abzurufen, wird lediglich der String '#AA' mit AA= Adresse des Moduls (z.B. 01) geschickt. Details siehe Seite 5-13. Mit einem Terminal Programm funktioniert das einwandfrei. Die Daten kommen auch in einem für RealView direkt lesbaren Format.

Wie gesagt: du brauchst dich da nicht reinzuknien. Vielleicht erbarmt sich Abacom ja auch und spendiert RealView das Command I/F, das bereits in ProfiLab existiert. Damit könnten Anwender leicht dieses hervorragende Programm selber an verschiedene Hardware anpassen.

Viele Grüße

Phineas

Phineas
Beiträge: 6
Registriert: Freitag 1. April 2011, 17:42

Re: RealView 3.0 User Interface: ASCII Kommandos? Problem gelöst

Beitrag von Phineas » Samstag 28. Mai 2011, 22:33

Ich habe das von mir angesprochene (und offenbar zahlreiche andere interessierende) Problem inzwischen mit Hilfe des Abacom Programms 'ProfiLab Expert' folgendermaßen gelöst:

- Um das gewünschte Kommando zu generieren, verwende ich das String Bauteil '$CNST'. Hierin wird der gewünschte Command-String (in meinem Fall z.B. "#01") gespeichert. Der Ausgang des Bauteils wird mit dem Eingang eines RS-232 Bauteils 'COM String senden' verbunden. Der COM Port entspricht meinem Sensor, den ich ansprechen will. Dieser COM Port wird durch die laufende ProfiLab Anwendung blockiert und kann daher nicht per 'User Interface' von RealView abgefragt werden (wie von mir in meinem ersten Artikel 'beklagt').
- Um die Antwort des Sensors abzufragen, verwende ich das Bauteil 'COM String empfangen'. Dieses Bauteil wird auf den selben COM Port eingestellt wie der Sender oben. Den Ausgang des Empfängers verbinde ich mit dem Eingang eines String Bausteins '$VAL', der den empfangenen String in eine Zahl umwandelt (mich interessiert halt nur der Messwert).
- Den Ausgang mit dem Messwert verbinde ich mit dem 'TX' Eingang eines 'ProfiLab TCP' Bausteins (Bibliothek Hardware/Allgemein, PC). Dieser Baustein wird konfiguriert als Server mit Kanal 0 und Signal Typ 'analog'. Die Host IP muss unbedingt auf 127.0.0.1 belassen werden. Die Portadresse lasse ich unverändert (kann aber bei Bedarf geändert werden). Der 'EN' Eingang des Bausteins muss noch mit einem '+' Baustein auf high gelegt werden.
- Damit die Schaltung funktioniert, benötigen der COM Port Sender und Empfänger noch ein Clock Signal. Dieses erzeuge ich mit Hilfe eines 'Taktgenerators' Bausteins, den ich (für meinen Sensor) auf 10 Hz einstelle. Die Taktrate muss aber zu zu dem anzusteuernden Sensor (oder Gerät) passen; lieber langsamer als zu schnell! Das Clock Signal verbinde ich mit dem 'SND' Eingang des Senders und dem 'CK' Eingang des Empfängers.

Hiermit ist das Programm fertig, um Messdaten abzurufen und über die interne TCP Schnittstelle weiterzugeben.
In RealView wähle ich jetzt als Hardware unter 'Sonstiges' das Gerät 'ProfiLab TCP' aus und konfiguriere es mit den gleichen Parametern wie oben angegeben (IP, Port, Kanal, Typ). Zur Messdatenerfassung starte ich das ProfiLab Programm (vorzugsweise als kompilierte Exe). Dann kann ich RealView starten und sehe (hoffentlich) den gewünschen Messwert.

Aus meiner Sicht lohnt sich die Investition in das interessante Programm ProfiLab Expert, weil man dadurch viele Messgeräte und Sensoren an RealView anpassen kann, für die es keine speziellen Treiber gibt. Ich wünsche allen Interessierten viel Erfolg und hoffe, dass Abacom trotzdem in einer künftigen RealView Version eine einfache Command String Funktion implementiert.

Phineas

Antworten

Zurück zu „Kundenprojekte“