Tool im Testbereich

Kein Produkt ..... mehr für Firmen internes messen, steuern, regeln, 
Daten erfassen, visualisieren, speichern .... Langzeittests von 
Prototypen.

Externe Aktoren und Sensoren können mittels dll angesprochen werden.

Es gibt diesbezüglich keine konkrete Aufgabe am Horizont .... Welches 
Tool könnte für sowas in die engere Auswahl kommen?

Mir ist klar, dass mit allen 3 (Labview, VS C#, Python oder anderen) 
Lösungen umgesetzt werden können;
genauso wie mit einer Schaufel eine Baugrube ausgehoben werden kann.
Es geht mir um Effizienz.

Welches Tool wäre für solche Aufgaben eurer Meinung nach das 
geeignetere?

EM schrieb:
> Welches Tool wäre für solche Aufgaben eurer Meinung nach das
> geeignetere?

Naja, viele Fragen wurden ja nicht beantwortet. Mit LabVIEW kann man 
hoch produktiv arbeiten(wenn man damit umgehen kann). Leider muss man 
relativ viel lernen um mit LabVIEW richtig umgehen zu können, man kann 
da leicht einer falschen Illusion unterliegen.

Wenn die DLLs nicht threadsicher sind, hast Du bei LabVIEW den Nachteil, 
dass Du alle DLLs in dem GUi Thread ausführen solltest (es gibt da noch 
andere Lösungen, aber die sind etwas fortschrittlicher).

Wenn es ActiveX Componenten und nicht DLLs sind, dann würde ich C# 
vorziehen.

Python ist gut falls Daten umfangreicher verarbeitet werden müssen.

Ansonsten: was können denn die Leute schon? Wenn Expertenwissen 
vorhanden ist, dann kann man sich ja viel Einarbeitungszeit sparen.

Schränkt irgend eines ein?
LabView bringt wohl sehr viel vorgefertigte Bausteine und GUI Elemente 
mit. Die NI und sonstige Hardware sollte über DLL in diversen Tools 
einbindbar sein.
Bei Labview stört mich die "grafische Programmierung".

Textuelles programmieren könte hier mehr flexibilität bieten.

Gibt es eventuell überschneidende Lösungen?
Nutzen von LabView GUI Komponenten in VS C#, Python oder QT?

Was wären die Stärken von LabView?

EM schrieb:
> Was wären die Stärken von LabView?

Stärke ist halt hauptsächlich, dass man solche einfachen 
Programmieraufgaben extrem schnell lösen kann (sieht dann zwar nicht 
ganz so toll aus, aber Mitarbeiter sind auch teuer). Ein einfaches GUI 
ist fast schon fertig, bevor man ein QT Programm auch nur kompiliert hat 
(gut, ist jetzt etwas übertrieben).

EM schrieb:
> Textuelles programmieren könte hier mehr flexibilität bieten.

Das hängt halt davon ab, wie anpruchsvoll Deine 'Businesslogik' ist.

> Bei Labview stört mich die "grafische Programmierung".
>
> Textuelles programmieren könte hier mehr flexibilität bieten.

Ich sag so: die grafisch-visuelle Programmierung verhindert 
Versionierung, genauer: das ausfindig machen von Unterschiede.
(bei Systeme von praxisrelevanter Größe, nicht Trivialübungen)

Die grafisch-visuelle Programmierung eignet sich bloss in einer ersten, 
explorativen Phase.
Für Phasen der Produktion mit auch nur minimalen QS-Anforderungen ist 
grafisch-visuelle Programmierung ein Garant für Probleme.

BTDT, leider mehrfach.

Gibt es Verantwortliche? Oder eine Horde Physiker, von denen jeder die 
Software "erweitert", um seinen  Messaufbau an die Anlage zu basteln, 
und in einem Jahr schon wieder woanders arbeitet?

Genau das Beispiel von Tom lässt mich vor LabView zurückschrecken.
LabView mag viele GUI Komponenten und Treiber für NI Hardware 
bereitstellen.
Das verarbeiten der Daten von Signal Input zu Signal Output mit diversen 
grafischen Komponenten  aus der LabView Lib ist mir fremd.
Um diese Lib Komponenten zweckmässig und fehlerfrei einsetzen und 
miteinander sinnvoll verbinden zu können, sollte man ihre Funktion unter 
der grafischen Haube im black box Sinne verstanden haben.

Klar, LabView beinhaltet verifizierte Komponenten die garantiert 
funktionieren. Was ein Vorteil sein kann gegenüber selbst geschriebenem 
Code.

In die LabView Welt können ja auch Dlls eingebunden werden, die mit x 
beliebiger Sprache erstellt wurden.

Gibt es auch die Möglichkeit LabView GUI Elemente in z.B. VS C# zu 
importieren?
Dlls der NI Hardware sollten ja überall einbindbar sein.