Labview und USB-I/O?

M

Martin Petrson

Guest
Hallo zusammen,

hat schon mal jemand einen USB-Portbaustein mit Labview verwendet? Es
sollen 8 digitale I/O vorhanden sein, einzeln als Ein- oder Ausgang
verwendbar; ein paar analoge I/Os wären auch nicht verkehrt aber nicht
unbedingt notwendig.

Der IO-Warrior ist ja aine Idee aber bietet leider keine Labview-dll und
den Umweg über C kann ich nicht einschätzen.

Für Vorschläge in jeder Richtung dankbar,

Martin
 
Hiho,

Hallo zusammen,

hat schon mal jemand einen USB-Portbaustein mit Labview verwendet? Es
sollen 8 digitale I/O vorhanden sein, einzeln als Ein- oder Ausgang
verwendbar; ein paar analoge I/Os wären auch nicht verkehrt aber nicht
unbedingt notwendig.

Der IO-Warrior ist ja aine Idee aber bietet leider keine Labview-dll und
den Umweg über C kann ich nicht einschätzen.
LabView bietet die Möglichkeit (unter Windows) ActiveX-Controls direkt
zu verwenden. Vielleicht bietet der IO-Warrior ja ein solches an (weiss ich
aus dem Kopf ned) - dann hat sich die Sache bereits erledigt.
Zur Not kann man auch Dlls direkt einsetzen, der Aufwand dürfte aber etwas
höher sein und mehr Gefummle verursachen.

Gruesse,
Reiner
 
Martin Petrson <mp345@hotmail.com> wrote in message news:<4084695B.D470F6AB@hotmail.com>...
Hallo zusammen,

hat schon mal jemand einen USB-Portbaustein mit Labview verwendet? Es
sollen 8 digitale I/O vorhanden sein, einzeln als Ein- oder Ausgang
verwendbar; ein paar analoge I/Os wären auch nicht verkehrt aber nicht
unbedingt notwendig.

Der IO-Warrior ist ja aine Idee aber bietet leider keine Labview-dll und
den Umweg über C kann ich nicht einschätzen.

Für Vorschläge in jeder Richtung dankbar,

Suche mal mit Google nach "labview iowarrior", da wirst Du schon
fuendig. Ausserdem habe ich in
einer neueren Version des SDK des IOWarriors ein LabVIEW DLL gesehen.
Und dann gibt es auch noch
das Forum bei http://www.codemercs.com/, wo man Dir bestimmt
weiterhelfen kann.
 
Martin Petrson wrote:

hat schon mal jemand einen USB-Portbaustein mit Labview verwendet?
Darf ich mir mal eine Gegenfrage erlauben? Wofür braucht man Labview?
Die Software ist doch absolut grauenhaft. Würde ich im Leben nicht
freiwillig benutzen.

Es
sollen 8 digitale I/O vorhanden sein, einzeln als Ein- oder Ausgang
verwendbar; ein paar analoge I/Os wären auch nicht verkehrt aber nicht
unbedingt notwendig.
Falls Du nichts findest, ich könnte Dir einen I2C Master mit
Labview Support empfehlen. Damit könntest Du das gewünschte per
I/O-Expander & Co erreichen.

Der IO-Warrior ist ja aine Idee aber bietet leider keine Labview-dll und
den Umweg über C kann ich nicht einschätzen.
Wenn ich mich richtig erinnere, wirbt Labview damit, daß sich ihre
Plug-In API seit Jahrzehnten nicht geändert hat. So fühlt sie sich
auch an :(.

Du hast wohl drei Möglichkeiten:

*) DLL mit der CIN-Schnittstelle von Labview schreiben: absolut
armselig und für C++ überhaupt nicht zu gebrauchen.

*) Konsolen Programme aus Labview starten

*) Seit Labview 7 kannst Du die .NET Technologie von MS benutzen:
die Lösung wäre ganz nett, leider zerstört Labview sämtliche
VI-Schaltungen, wenn sich auch nur der Pfad der .NET DLL
ändert.

Ich durfte in letzter Zeit Labview VIs für unsere Produkte
schreiben: grauenhaft.

cu, Marco

--
S: Minolta: Winkelsucher (VN), VC-9

E-Mail: mb-news-b<ät>linuxhaven.de
Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de
 
Reiner Rosin wrote:

LabView bietet die Möglichkeit (unter Windows) ActiveX-Controls direkt
zu verwenden.
Fragt sich nur mit welchen Beschränkungen. In der Regel unterstützen
solche Loader nur sehr wenige Datentypen. Fremden Code kann man selten
direkt nutzen.

Zur Not kann man auch Dlls direkt einsetzen, der Aufwand dürfte aber etwas
höher sein und mehr Gefummle verursachen.
Das obige gilt auch hier: kannst Du vergessen.

cu, Marco

--
S: Minolta: Winkelsucher (VN), VC-9

E-Mail: mb-news-b<ät>linuxhaven.de
Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de
 
Marco Budde <mb-news-a@linuxhaven.de> wrote in message news:<408A7DC2.2518ED74@linuxhaven.de>...
Reiner Rosin wrote:

LabView bietet die Möglichkeit (unter Windows) ActiveX-Controls direkt
zu verwenden.

Fragt sich nur mit welchen Beschränkungen. In der Regel unterstützen
solche Loader nur sehr wenige Datentypen. Fremden Code kann man selten
direkt nutzen.

Zur Not kann man auch Dlls direkt einsetzen, der Aufwand dürfte aber etwas
höher sein und mehr Gefummle verursachen.

Das obige gilt auch hier: kannst Du vergessen.
Was meinst Du hier ? Mann kann doch dll's relativ einfach verwenden ?

In Praxis habe ich auch gemerkt das die Default-dll auch mit Vee nicht
lauft, aber mann hat die Source, also kann mann die ändern ;-)

mfG,
Alain
 
Marco Budde wrote:
Darf ich mir mal eine Gegenfrage erlauben? Wofür braucht man Labview?
Die Software ist doch absolut grauenhaft. Würde ich im Leben nicht
freiwillig benutzen.
Wozu braucht man Windows? Irgendwie ist das Zeuch jetzt
Standard im semiprofessionellen Bereich. Alle Studenten
hier quälen sich mehr oder weniger freiwillig damit ab.
Ich versteh auch nicht, warum das in einem grösseren
Forschungsinstitut nicht besser zentralisiert wird und
warum hunderte Studis bei Null anfangen und dadurch
einen Haufen Zeit vertrödeln.

Ich durfte in letzter Zeit Labview VIs für unsere Produkte
schreiben: grauenhaft.
Grossfirmen, welche aus irgendwelchen Gründen Labview
benutzen (in F&E recht verbreitet), haben seit einiger
Zeit die Programmiererei ausgelagert (oder wie das
auf deutsch heissen mag).

--
mfg Rolf Bombach
 
Hallo,

Am 02.05.2004 11:54 schrieb iwantnospam@tijd.com:

In Praxis habe ich auch gemerkt das die Default-dll auch mit Vee nicht
lauft, aber mann hat die Source, also kann mann die ändern ;-)
Zumindest für den IOWarrior von CodeMercs kann ich dies nicht
bestätigen. Ich habe unter Agilent Vee geschafft die Orginal DLL zum
laufen zu bringen. Man muss nur die Header Datei etwas anpassen und auf
VEE Seite etwas mehr arbeit investieren. Also das ansprechen der IO-Pins
ist problemlos möglich, für alles andere bestand noch keine Notwendigkeit.

MfG

Stefan
--
"Going to church does not make you a Christian anymore than going to the
garage makes you a car."
 
On 20 Apr 2004, you wrote in de.sci.electronics:

hat schon mal jemand einen USB-Portbaustein mit Labview verwendet?
Ja, ich.
Eben jenen Warrior:

Der IO-Warrior ist ja aine Idee aber bietet leider keine Labview-dll und
den Umweg über C kann ich nicht einschätzen.
Herr Kainka bietet aber eine dll und die kann man problemlos in Labview
einbinden. Habe ich bereits erfolgreich ausprobiert (aber schon sehr lange
her - bei Bedarf pm. an: uli unterstrich mainz at web punkt de)

Nur Mut!
Gru3
Uli


--
Bitte keine Mail-Antworten hier, ich lese in den NGs. (Spamschutz)
 
iwantnospam@tijd.com wrote:

Was meinst Du hier ?
Ich meine damit, daß das DLL-Interface genauso unbrauchbar
sein wird wie das vieler anderer Systeme (ein Kunde berichtete
neulich z.B. von solchen Problemen auch bei Matlab).
Alles was über integrale Datentypen wie "int" hinausgeht,
kannst Du damit sowieso nicht nutzen.

Mann kann doch dll's relativ einfach verwenden ?
Wünsche ich Dir viel Spaß mit :). Genial ist auch die neue
..NET Plug-In-Schnittstelle in Labview 7. Da brauchst Du
nur den Pfad der DLL ändern und schon zerstört Labview Dir
die gesamte Schaltung.

lauft, aber mann hat die Source, also kann mann die ändern ;-)
Am besten man wirft Labview ganz weg und schreibt sich
ein kleines C-Programm. Ich finde es immer wieder erstaunlich,
für was für Zwecke die Leute Labview einsetzen.

cu, Marco

--
S: Minolta: Winkelsucher (VN), VC-9

E-Mail: mb-news-b<ät>linuxhaven.de
Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de
 
Rolf Bombach wrote:

Wozu braucht man Windows?
Eine berechtigte Frage :).

Irgendwie ist das Zeuch jetzt
Standard im semiprofessionellen Bereich.
Labview wird IHMO vor allem dort eingesetzt, wo die
Leute keine Programmier- oder Scriptsprache beherrschen.
Sachen, die man per Script mit ein paar Zeilen Code
erledigt, werden mit Labview extrem riesig und
unübersichtlich.

Alle Studenten
hier quälen sich mehr oder weniger freiwillig damit ab.
Echt? Aus der Uni kenne ich eigentlich nur die Matlab
Fraktion. Auch hier fragt man sich, warum ein Programm
1h eine Matrix berechnet, um dann festzustellen, daß diese
nicht in den Speicher paßt. Sowas hätte man auch gleich
feststellen können.

cu, Marco

--
S: Minolta: Winkelsucher (VN), VC-9

E-Mail: mb-news-b<ät>linuxhaven.de
Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de
 
Marco Budde wrote:
Irgendwie ist das Zeuch jetzt
Standard im semiprofessionellen Bereich.

Labview wird IHMO vor allem dort eingesetzt, wo die
Leute keine Programmier- oder Scriptsprache beherrschen.
Sachen, die man per Script mit ein paar Zeilen Code
erledigt, werden mit Labview extrem riesig und
unübersichtlich.
Wichtig sind vorallem die standardisierten Geräteschnitt-
stellen. Jedes Gerät, auch wenn es die gleiche Funktion
erfüllt, will ja proprietär wieder einmal ganz anders
angesprochen werden. Da kann man auch viel Zeit verlieren,
bis man herausgefunden hat, mit welchen Befehlen in
welcher Reihenfolge das Ding das tut, was im Prospekt
steht. Auf Anleitungen ist erfahrungsgemäss auch bei
namhaften Produkten kein Verlass.

Alle Studenten
hier quälen sich mehr oder weniger freiwillig damit ab.

Echt?
Ja, leider. Die verheizen da unglaublich viel Zeit. Wenn
ich in der Experimentierhalle so um mich blicke, sehe
ich ca. 30 Bildschirme, bis auf meine 3 läuft auf allen
Labview. Schaudern tut's mich auch, wenn bei einer
Facharbeit (so was wie eine Diplomarbeit für Lehrlinge)
zum Thema Vakuumtechnik 3 Monate lang Labview programmiert
wird, ohne dass der Kandidat je ein Vakuum in den
Händen gehabt hat, wenn ich das mal so ausdrücken darf ;-)

Aus der Uni kenne ich eigentlich nur die Matlab
Fraktion. Auch hier fragt man sich, warum ein Programm
1h eine Matrix berechnet, um dann festzustellen, daß diese
nicht in den Speicher paßt. Sowas hätte man auch gleich
feststellen können.
Naja, wer mit Geräten rumturnt, nimmt Labview, wer mit
Formeln murkst, Maple oder dergleichen, und wer mit
Zahlen werkelt, nimmt Matlab. Warum auch nicht. Zeit-
verschwendung ist für mich eher, wenn das Problem
anliegt, eine 50x50 Matrix zu diagonalisieren, der
Betreffende aber statt Matlab zu nehmen erst mal
anfängt mit C rumzubasteln. Wenn Matlab der moderne
Taschenrechner ist, ist das halt so. Rummoralisieren
a la "wir haben früher alles mit dem Rechenschieber
gemacht" halt ich für wenig angebracht, Pferdekutschen
und Petrollampen sind auch out...

--
mfg Rolf Bombach
 
Rolf Bombach wrote:

Wichtig sind vorallem die standardisierten Geräteschnitt-
stellen.
Das hängt aber auch sehr stark von der Anwendung ab oder?

Jedes Gerät, auch wenn es die gleiche Funktion
erfüllt,
Was bei vielen Meßgeräten aber nicht der Fall sein dürfte.

will ja proprietär wieder einmal ganz anders
angesprochen werden. Da kann man auch viel Zeit verlieren,
Daß man mit Labview schneller zum Ziel kommt, glaube
ich ehrlich gesagt nicht. Die paar Zeilen proprietären
Code sind IHMO überhaupt kein Problem.

bis man herausgefunden hat, mit welchen Befehlen in
welcher Reihenfolge das Ding das tut, was im Prospekt
steht. Auf Anleitungen ist erfahrungsgemäss auch bei
namhaften Produkten kein Verlass.
Meinen Support Erfahrungen nach lesen viele Kunden sowieso
nie die Anleitung =:).

Naja, wer mit Geräten rumturnt, nimmt Labview,
Vor allem die Leute aus dem Fertigungs- bzw. Meß- und
Regeltechnikbereich scheinen total auf Labview zu stehen.
Liegt vermutlich daran, daß die Leute nicht programmieren
können.

wer mit
Formeln murkst, Maple oder dergleichen, und wer mit
Zahlen werkelt, nimmt Matlab. Warum auch nicht.
Weil diese Tools teuer und langsam sind? Krank sind doch auch
Simulationen komplexer Algorithmen in Matlab. Klar, für
Matlab gibt es massenhaft Bibliotheken, aber dafür ist
das Zeug relativ langsam. Ich hätte keine Lust, immer auf
den Rechner zu warten.

Zeit-
verschwendung ist für mich eher, wenn das Problem
anliegt, eine 50x50 Matrix zu diagonalisieren, der
Betreffende aber statt Matlab zu nehmen erst mal
anfängt mit C rumzubasteln.
Für sowas gibt es im Internet massenhaft OpenSource
Bibliotheken (die nicht selten von den kommerziellen
Tools auch benutzt werden). Die bindet man ein und
fertig.

Und an der Uni kann jeder Fachbereich sich entsprechende
Toolkits entwickeln, so daß nicht jeder wieder bei
Null anfangen muß.

Wenn Matlab der moderne
Taschenrechner ist, ist das halt so. Rummoralisieren
a la "wir haben früher alles mit dem Rechenschieber
gemacht" halt ich für wenig angebracht, Pferdekutschen
und Petrollampen sind auch out...
Was nützen mir Tools, die viel Geld kosten und die mich
nur behindern?

cu, Marco
 
Marco Budde <mb-news-a@linuxhaven.de> writes:

Rolf Bombach wrote:

Wichtig sind vorallem die standardisierten Geräteschnitt-
stellen.

Das hängt aber auch sehr stark von der Anwendung ab oder?

Jedes Gerät, auch wenn es die gleiche Funktion
erfüllt,

Was bei vielen Meßgeräten aber nicht der Fall sein dürfte.

will ja proprietär wieder einmal ganz anders
angesprochen werden. Da kann man auch viel Zeit verlieren,

Daß man mit Labview schneller zum Ziel kommt, glaube
ich ehrlich gesagt nicht. Die paar Zeilen proprietären
Code sind IHMO überhaupt kein Problem.
.... zumal wenn man nicht regelmaessig alle 1000000ns mal einen ADC
auslesen will sondern zu zufaelligen Zeiten (ntervalle im bereich
einige us) eineige zehntausend ADCs und TDCs auslesen will...

--
Dr. Juergen Hannappel http://lisa2.physik.uni-bonn.de/~hannappe
mailto:hannappel@physik.uni-bonn.de Phone: +49 228 73 2447 FAX ... 7869
Physikalisches Institut der Uni Bonn Nussallee 12, D-53115 Bonn, Germany
CERN: Phone: +412276 76461 Fax: ..77930 Bat. 892-R-A13 CH-1211 Geneve 23
 
Marco Budde wrote:
Wichtig sind vorallem die standardisierten Geräteschnitt-
stellen.

Das hängt aber auch sehr stark von der Anwendung ab oder?
Allerdings. Ich schildere hier Beobachtungen, nicht
Meinungen, BTW. Und da ist mir halt aufgefallen, dass
früher beim Wechsel eines Spektrometers eine längere
Analyse des vorhandenen, natürlich nicht dokumentierten
Sourcecodes eines längst verschollenen Doktoranden
nötig war. Anschliessend mussten irgendwelche Codeteile,
manchmal Assembler, manchmal Fortran und schlimmeres
geändert werden. Nach dem 100stern Test ging es dann
wieder, so nach einigen Wochen. Jetzt wird die neue
Softwareschnittstelle geladen und gut is.

Daß man mit Labview schneller zum Ziel kommt, glaube
ich ehrlich gesagt nicht. Die paar Zeilen proprietären
Code sind IHMO überhaupt kein Problem.
Schon mal mit ner Hamam*ts* Streak camera gearbeitet?

bis man herausgefunden hat, mit welchen Befehlen in
welcher Reihenfolge das Ding das tut, was im Prospekt
steht. Auf Anleitungen ist erfahrungsgemäss auch bei
namhaften Produkten kein Verlass.

Meinen Support Erfahrungen nach lesen viele Kunden sowieso
nie die Anleitung =:).
Nicht mal der Hersteller hat sie offenbar gelesen :-]

Naja, wer mit Geräten rumturnt, nimmt Labview,

Vor allem die Leute aus dem Fertigungs- bzw. Meß- und
Regeltechnikbereich scheinen total auf Labview zu stehen.
Liegt vermutlich daran, daß die Leute nicht programmieren
können.
Müssten sie? Die meisten Leute, die heute Auto fahren,
haben von der Technik keine Ahnung und hätten anno 30
keine Chance gehabt, die Prüfung zu bestehen, so what.

wer mit
Formeln murkst, Maple oder dergleichen, und wer mit
Zahlen werkelt, nimmt Matlab. Warum auch nicht.

Weil diese Tools teuer und langsam sind? Krank sind doch auch
Simulationen komplexer Algorithmen in Matlab. Klar, für
Matlab gibt es massenhaft Bibliotheken, aber dafür ist
das Zeug relativ langsam. Ich hätte keine Lust, immer auf
den Rechner zu warten.
Dafür gibt's immer schnellere Rechner ;-].
Zeit-
verschwendung ist für mich eher, wenn das Problem
anliegt, eine 50x50 Matrix zu diagonalisieren, der
Betreffende aber statt Matlab zu nehmen erst mal
anfängt mit C rumzubasteln.

Für sowas gibt es im Internet massenhaft OpenSource
Bibliotheken (die nicht selten von den kommerziellen
Tools auch benutzt werden). Die bindet man ein und
fertig.
Muss man sich aber gut auskennen. Es ist leider auch
unheimlich viel Schrott zweifelhafter Provenienz darunter.
Ich hab jetzt schon oft gehört: "Hätt ich doch gleich
das teure kommerzielle Produkt gekauft statt erst
ein halbes Jahr open-source Sachen durchzutesten".
Dieser krampfhafte darf-nix-kosten-Wahn treibt dann
sonderbare Blüten. Alle möglichen guten Programme
werden wie auch immer auf C umgestrickt, mit zweifel-
haften Resultaten, siehe gewisse SPICEs. GAUSSIAN
soll selbst bei garantiert echtem nativen C 3x langsamer
als die Fortran-Version sein, bei maschinenkonvertierten
Sachen eher 10x langsamer. Das ist dann für mich
ähnlich krank wie Matlab.

Und an der Uni kann jeder Fachbereich sich entsprechende
Toolkits entwickeln, so daß nicht jeder wieder bei
Null anfangen muß.
Das erklärt aber nicht, warum die Uni dann doch lieber
so was wie Matlab zur Verfügung stellt und nicht ein
eigenes Toolkit. Vielleicht ist das bei dem Plattformen-
salat auch gar nicht so einfach. Und irgendwie ist mir,
als wäre die tatsächliche Situation an vielen Fachbereichen
dem Publikum nicht ganz klar, um es mal schonend auszu-
drücken. Selbst an Hochschulen, welche, wenn auch nur
knapp, in den world to 25 liegen. Hoffe, muss nicht noch
genauer werden ;-). Es ist durchaus üblich, dass da
genau ein Doktorand "simuliert", und der nächste dann
mangels Overlap wieder bei Null anfangen muss.

Wenn Matlab der moderne
Taschenrechner ist, ist das halt so. Rummoralisieren
a la "wir haben früher alles mit dem Rechenschieber
gemacht" halt ich für wenig angebracht, Pferdekutschen
und Petrollampen sind auch out...

Was nützen mir Tools, die viel Geld kosten und die mich
nur behindern?
_Dir_ nichts, da du dir a) die entsprechenden Gedanken
machst und dir b) zu helfen weisst. Das ist beim durch-
schnittlichen Studi, Gott sei's geklagt, leider nicht
der Fall. Von einem gewissen Alter an ist deine Haupt-
funktion rumzulaufen und aufzupassen, dass die Studenten
nicht für viel Geld und viel Zeit das Rad neu erfinden.

--
mfg Rolf Bombach
 
Hallo,

Martin Petrson <mp345@hotmail.com> schrieb:

hat schon mal jemand einen USB-Portbaustein mit Labview verwendet? Es
sollen 8 digitale I/O vorhanden sein, einzeln als Ein- oder Ausgang
verwendbar; ein paar analoge I/Os wären auch nicht verkehrt aber nicht
unbedingt notwendig.

Der IO-Warrior ist ja aine Idee aber bietet leider keine Labview-dll und
den Umweg über C kann ich nicht einschätzen.
Auf der CD und auch als Download auf www.codemercs.com findet sich in
dem so genannten SDK etwas versteckt eine DLL, die auch für Labview
einsetzbar ist und alle Grundfunktionen bietet. Ich hab selber ein
paar VIs dafür geschrieben. Bei Interesse Mail an gerd_roethig at web
dot de.

Ciao

Gerd
 

Welcome to EDABoard.com

Sponsor

Back
Top