' schrieb:sondern für die PC-Gestütze Messtechnik,
Das sehe ich auch so.
Für die Messwerterfassung gibt es den sog. MAX und das DAQmx-System. Diese beiden machen die komplette Messwerterfassung bis hin zu dem Punkt, an dem der Anwender einen Puffer vorfindet, in dem seine erfassten Daten im von ihm gewünschten Format stehen. Und die ganze Sache läuf ab, ohne dass der Anwender (also der LV-Programmierer) davon etwas merkt. Und das auch noch unabhängig von der eingesetzten Hardware: PCI, PXI, Windows - alles egal, es gibt nur eine Schnittstelle! Weis denn noch einer (außer natürlich RolfK, naja und den wenig anderen) was da alles dahintersteckt, hinter dem MAX und dem DAQmx-System? So schnell wie mit LV respektive MAX kann man keine universelle Messwerterfassung machen. (Es gibt natürlich Komponenten von anderen Anbietern, Addidata fällt mir gerade ein, die etwas ähnliches haben: Für eine eng umgrenzte Messaufgabe tut das auch. Aber nicht fürs große Ganze.) In Sachen Messwerterfassung ist NI konkurrenzlos.
Das mit dem Speicher reservieren in Verbindung mit C++ sehe ich jetzt nicht so eng: In Delphi ist eine manuelle Speicherreservierung (mittels getmem() etc) nicht notwendig. Da gibt es ein "Init-Array" wie in LV auch. Das eine graphikbasiert, das andere textbasiert. Und "was schneller geht", Delphi textorientiert strukturiert/OOP oder LV graphikorintiert Datenfluß - das sei mal dahin gestellt.
LV hat aber auch Schwächen: Ich bin mit meiner Delphi-IDE (D7Pro, D2k7Ent) und mit den "Delphi-Frontpanels" sowas von verwöhnt, dass ich (diplomatisch) sagen muss: Die LV-IDE und das LV-FP ansich stehen weit hinter der Delphi-IDE und der Delphi-VCL (visual code library = FP). (Ich rede nicht von D2005/D2006, auch nicht von LV-8-0).
Da aber die vorhandene Messwerterfassung, die 0.0% der SW-Entwicklungszeit in Anspruch nimmt, die Probleme mit IDE/FP aufwiegen, wird LV verwendet. Und die Problemchen mit der IDE und dem FP sind ja wohl doch eher ein Ansporn für jeden Hardcode-Progger!
