jetzt habe ich das thema ja angeregt und freue mich, das, wenn auch spärlich, einige leute interesse zeigen. also werde ich mal wieder etwas input geben.

also... labview ist ein programm der firma national instruments, das es ermöglicht irgendwelche vorgänge in verschidensten formen darzustellen. ich würde fas sagen, dass es das excel für techniker und elektroniker ist (excel kann halt balkendiagramme) und labview kann halt das, was man in dem link, den stefan_z eingestellt hat sehen kann.

hier nochmal der link:
http://www.heise.de/ct/projekte/mach...i/LabViewDemos


und stefan hat natürlich recht... es wird ein parser benötigt. wenn man in der labview software ein virtuelles messinstrument konstruiert, möchte dieses ja die darzustellenden daten irgenwo herholen. dazu benutzt es eine u.a. eine serielle schnittstelle. in unsre kleinen atmels muss also etwas hereinprogrammiert werden, was auf die anfrage von labview antwortet und die gewünschten daten sendet.

also ein parser, der auf bestimmte worte auf dem seriellen port adequat antwortet. das wäre doch super.

unser forum-kollege guenter1604 hat schon grosartige arbeit geleistet. er hat versucht, das ct-lab über fernbedienung zu steuern und entsprechenden code generiert.

ich zitiere hier mal aus seinem beitrag:

Hallo kolisson,

guck mal hier...

http://www.heise.de/ct/projekte/machmit/ctlab/ticket/10


und jetzt füge ich noch ein zitat aus dem ct-forum bei:

Re: Parser in Basic ?
Carsten Meyer, Carsten Meyer, cm@ct.heise.de (243 Beiträge seit 26.01.00)
Hallo,

einen toleranten UND platzsparenden Parser zu schreiben, ist nicht
ganz trivial. Der im c't-Lab hat gewisse Vereinfachungen, z.B. kann
man das Ausrufezeichen bei Befehlen auch weglassen (nicht jedoch das
Fragezeichen bei Abfragen).

Der Parser sammelt eingehende Zeichen zunächst in einem String, bis
ein CR oder CR/LF auftritt. Dann startet folgender Mechanismus:

Zeilen mit einem "#" am Anfang werden gleich an den OptoBus-Ausgang
durchgereicht und intern verworfen (weil Messwert von einem anderen
Modul).

Der Parser sucht zunächst nach einem Doppelpunkt. Wenn vorhanden,
nimmt er die Zahl vor dem Doppelpunkt als Modulnummer. Stimmt die
Zahl mit der über die Jumper eingestellte Modul-Adresse NICHT
überein, wird die Befehlszeile wie oben an den Ausgang durchgereicht
und verworfen.

Dann sucht er nach Buchstaben. Findet er einen, geht er davon aus,
dass man ein Mnemonik eingegeben hat. Die Buchstaben sammelt er, bis
er auf einen Nicht-Buchstaben (Leerzeichen, Sonderzeichen oder Zahl)
stößt. Dann schaut er in einer Tabelle (Array) nach, welcher
SubChannel dem Mnemonik entspricht. Findet er keinen entsprechenden
Eintrag, ist der Befehl falsch geschrieben oder unbekannt, und es
gibt eine Fehlermeldung. Ohne Mnemonik nimmt er die (erste oder die
dem Doppelpunkt folgende) Zahl direkt als SubChannel-Angabe.

Zahlen hinter dem Mnemonik (keine Zahl bedeutet "0") werden als
positive Offsets zur Mnemonik-SubChannel-Entsprechung (z.B. SCL hat
SubCh 200, SCL 1 => 200+1 => 201) gewertet, um einen eindeutigen
SubChannel zu bekommen. Leerzeichen können weggelassen werden.

Steht hinter dem Mnemonik, SubChannel oder SubChannel-Offset ein "?",
handelt es sich um eine Abfrage, und der gewünschte Wert wird
ausgegeben.

Trifft der Parser dagegen auf ein "=", handelt es sich um einen
(Ausgabe-)Befehl. Die Zahl hinter dem "=" ist der einzustellende
Wert. Leerzeichen und Nicht-Zahlen (und eigentlich auch das
abschließende "!") werden ignoriert.

Nach diesem Muster sind

0:20? {Modul-Adresse ist jetzt 0}
val 20?
VAL20?
val 20 ?

gleichwertig, ebenso wie

SCL?
SCL 0?
200?
VAL 200?

oder

0:VAL 20=1.5! {Modul-Adresse ist jetzt 0}
0:20 = +1.5
20=1.5

Hoffe, damit einige Klarheiten beseitigt zu haben.

cm