LabView als Demo oder Lightversion

Die Studentenversion gibt es in D unter 100Euro. Du brauchst einen Nachweis (Imma-Bescheinigung). Download online bei NI. Wenn Du in eine Fach (Uni)-Bibliothek gehst, gibt es LabView B=FCcher mit CD und Ser.Nr. Aktuell ist, glaube ich, Labview 8.2. (Ich w=FCrde nicht unter 7.0 anfangen) Gru=DF Ulli

Reply to
ludwig zweck
Loading thread data ...

|> Beispiele?

Case-Statements passen überhaupt nicht zur grafischen Programmierung. Man muss manuell die Ausahlmöglichkeiten durchklicken, um einen Überblick zu bekommen, das das Ding macht. Und dass beim Ausdruck pro Auswahl eine Seite produziert wird, finde ich auch nicht wirklich wartungsfreundlich.

Oder Stringverarbeitung zur Ansteuerung von Geräten über GPIB/TCP etc. Da ist Datenflussprogrammierung (erst recht grafische) einfach das falsche Mittel. Aber wenn man nur einen Hammer hat...

Das Problem ist halt, dass der an sich gute Gedanke von LabView im Laufe der Zeit zur Wollmilchsau geworden ist, weil wohl jeder Anwender hier und da noch was Spezielles wollte.

|> Wie bei allen Implementierungen kann man am Code sehr schön erkennen ob |> der Entwickler sich VORHER Gedanken gemacht hat.

Code? Ich sehe da nur kleine und grosse Blöcke, die man mit einer Drahtspule verdrahtet. Und die nudelt gern absonderliche Wege, die man von Hand schön machen muss. Zum Finden einer Vergrösserungsfunktion bin ich wohl zu blöd, am Laptop macht es damit nicht wirklich Spass... |> > Labview wird wohl das zukünftige Asbest in der Regelungstechnik ;-) |> > |> |> Da bin ich anderer Meinung.

Es hat seinen Grund, dass beim Entwurf digitaler Schaltungen (auch nur Datenfluss mit impliziter Parallelität) Schaltpläne schon fast völlig ausgestorben sind und durch textuelle Beschreibungen (Verilog/VHDL, ...) ersetzt wurden. Sicher gibt es noch Sonderanwendungen (Blockdiagramme zur Verdahtung im Toplevel), aber Text vereinfacht doch einiges, was algorithmische Beschreibung angeht.

--
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
 Click to see the full signature
Reply to
Georg Acher

Dass die Beschreibungssprachen inzwischen die andern Modellierungsmethoden fast vollständig verdrängt haben liegt wohl nicht daran, dass sie generell besser wären.

Zum Einen sind sie in. Die meisten Praktikanten und Diplomanden (warum schreibt man die einen mit "t" in der letzten Silbe, die anderen dagegen mit "d"? Scheint mir vollkommen unlogisch), die ich in unserer Firma getroffen habe, woll(t)en sich die Finger nicht an Hardware schmutzig machen. Die frönen lieber dem postmateriellen Basteln. Und Stromläufe sind für die identisch mit Hardware. Ebenso ist es mit den Leuten, die einigermaßen frisch als Ingenieur bei uns arbeiten. Manch einer würde auch viel lieber andere herumkommandieren und hat Angst, sich beim Löten die karrierefördernde Krawatte zu verbrennen. So sterben die graphischen Modellierungsmethoden langsam aus.

Zum Anderen gibt es bisher noch keinen Standard für die Dateiformate, die für z.B. Stromlauf oder Zustandsdiagramm nötig wären. Wenn man in einem Programmpaket mal anfängt, zu zeichnen, ist man auf dieses Paket festgelegt. HDL-Designer versteht die Stromläufe und Statusdiagramme von ISE nicht, genausowenig wie die beiden die vom Altera-Tool verstehen (und umgekehrt). Deshalb lässt man es eben bleiben.

Dessen ungeachtet gibt es genügend Fälle, in denen die Beschreibungssprachen nicht das optimale Mittel sind, vor allem, was die Wartbarkeit betrifft.

Einen Phasenkomparator Typ 2 (der mit den beiden FlipFlops und dem Und-Gatter) erkennt man im Stromlauf auf Anhieb, ohne auch nur genau hinzusehen. In VHDL muss man da schon sehr genau nachdenken, was die zehn Zeilen Code wohl bedeuten könnten (ja, ich weiß, manche quetschen das au "elegant" in zwei Zeilen -- und es ist überhaupt nicht mehr wiederzuerkennen).

Ein Zustandsdiagramm verschafft einen direkten Überblick über die Zusammenhänge. Eine Zustandmaschine in VHDL erstreckt sich auch bei nur wenigen Zuständen und Übergängen ganz schnell über viele Seiten und der Überblick ist weg.

Einen Zähler mit vielen Bits/FlipFlops wöllte ich weder als Stromlauf, noch als Zustandsmaschine entwerfen. Dafür ist VHDL oder Verilog sehr viel besser geeignet.

Ich neige dazu, für jeden Zweck das dazu am besten geeignete Werkzeug zu verwenden. Die Beschreibungssprachen sind aber nicht für alles die beste Wahl. Nur -- wie bereits geschrieben -- muss man sie in vielen Fällen trotzdem verwenden, um bezüglich der Werkzeuge einigermaßen flexibel zu bleiben.

Grüße,

Günther

Reply to
Günther Dietrich

Hallo Ludwig,

ludwig zweck schrieb: [...]

aus dem Alter bin ich (zum Gk=FCck) raus ;-)

ich habe jetzt die c't bestellt. Mal sehen, was da auf mich zukommt. Im Prinzip m=F6chte ich das System einfach mal mit dem von mir bereits mehrfach eingesetzten System "WinCC" von Siemens vergleichen. WinCC ist ein m=E4chtiges, aber auch sehr kostenintensives System. Na ja, im Prinzi= p machen ja alle Visualisierungssysteme das selbe, und man kann sich normalerweise relativ schnell in die Systeme einarbeiten, so nach dem Motto: eines gesehen, alle gesehen.

ciao

Marcus

Reply to
Marcus Woletz

Hallo Lutz,

Es muss schon moeglich sein, zum Beispiel eine Station nochmal zu bauen. DAQFactory kostet je nach "Lederausstattung" $199 bis $899. Die mit einer der Versionen erstellten Programme kann man auch auf anderen PCs laufen lassen, wenn man fuer jeden eine Runtime License kauft und die kosten nur $99.

Fuer $2499 bekommt man die volle Developer Suite und dann darf man m.W. ohne Runtime License die ganze Produktion ausstatten. Irgendwie sind da die Preise doch moderater, habe mir mal das Schnupperpaket besorgt. Ist nur schwer zu sagen, was sich durchsetzen wird. Derzeit ist LabView wahrscheinlich noch in Fuehrung, so wie ja auch OrCad trotz hoher Preise immer noch vorn liegt.

--
Gruesse, Joerg

http://www.analogconsultants.com
Reply to
Joerg

Hallo Ludwig,

[...]

Koenntest Du diesen erlauchten Kreis den Grund wissen lassen? Waren da Bugs drin oder fehlten wichtige Dinge? M.W. ist die c't Version 6.1, bin aber nicht sicher.

--
Gruesse, Joerg

http://www.analogconsultants.com
Reply to
Joerg

Hallo Georg,

das

Aber

Ich finde es auch recht teuer.

machen

Datenfluss

und

es

Also hier geht das noch ganz buergerlich mit Schaltbildern. Derzeit mit Eagle.

--
Gruesse, Joerg

http://www.analogconsultants.com
Reply to
Joerg

|> Dass die Beschreibungssprachen inzwischen die andern |> Modellierungsmethoden fast vollständig verdrängt haben liegt wohl nicht |> daran, dass sie generell besser wären.

IMO sind sie für komplexe Systeme besser. Ich habe ~93 angefangen, für FPGAs mit Schaltplänen (Viewlogic) rumzumachen. Am Anfang gehts schnell, gerade weil die ganze 74er-Libs schon da waren. Aber bei aufwendigeren Dingen (Statemachines mit

binär vs. one-hot-Encoding) schon beim Zeichnen festlegt und noch schwer ändern kann. Für reinen Datenfluss ist ein Schaltplan sicher gut, ich mache das beim Design von Pipelinestufen auch, aber nur auf dem Papier. |> Zum Einen sind sie in. Die meisten Praktikanten und Diplomanden (warum |> schreibt man die einen mit "t" in der letzten Silbe, die anderen dagegen |> mit "d"? Scheint mir vollkommen unlogisch), die ich in unserer Firma

Die einen machen ein Praktikum, die anderen sind zu diplomieren ;-)

|> getroffen habe, woll(t)en sich die Finger nicht an Hardware schmutzig |> machen. Die frönen lieber dem postmateriellen Basteln. Und Stromläufe |> sind für die identisch mit Hardware. Ebenso ist es mit den Leuten, die |> einigermaßen frisch als Ingenieur bei uns arbeiten. Manch einer würde |> auch viel lieber andere herumkommandieren und hat Angst, sich beim Löten |> die karrierefördernde Krawatte zu verbrennen. |> So sterben die graphischen Modellierungsmethoden langsam aus. |> |> Zum Anderen gibt es bisher noch keinen Standard für die Dateiformate,

Das ist sicher ein wichtiger Grund, da bastelt jeder was proprietäres...

|> die für z.B. Stromlauf oder Zustandsdiagramm nötig wären. Wenn man in |> einem Programmpaket mal anfängt, zu zeichnen, ist man auf dieses Paket |> festgelegt. HDL-Designer versteht die Stromläufe und Statusdiagramme von |> ISE nicht, genausowenig wie die beiden die vom Altera-Tool verstehen |> (und umgekehrt). |> Deshalb lässt man es eben bleiben. |> |> |> Dessen ungeachtet gibt es genügend Fälle, in denen die |> Beschreibungssprachen nicht das optimale Mittel sind, vor allem, was die |> Wartbarkeit betrifft. |> |> Einen Phasenkomparator Typ 2 (der mit den beiden FlipFlops und dem |> Und-Gatter) erkennt man im Stromlauf auf Anhieb, ohne auch nur genau |> hinzusehen. In VHDL muss man da schon sehr genau nachdenken, was die |> zehn Zeilen Code wohl bedeuten könnten (ja, ich weiß, manche quetschen |> das au "elegant" in zwei Zeilen -- und es ist überhaupt nicht mehr |> wiederzuerkennen). |> |> Ein Zustandsdiagramm verschafft einen direkten Überblick über die |> Zusammenhänge. Eine Zustandmaschine in VHDL erstreckt sich auch bei nur |> wenigen Zuständen und Übergängen ganz schnell über viele Seiten und der |> Überblick ist weg.

Ich finde Bubble-Diagramme auch nicht wirklich toll. Erstens kann man die Zustandsübergangsbedingungen bei komplexeren Sachen nicht mehr an die Pfeile schreiben und zweitens ist die Ausgangsfunktion nur bei wenigen Signalen "in-place" notierbar.

Ich hatte mal so ein Ding mit 60 Zuständen, das war dann auch in VHDL nicht toll. Allerdings konnte man in VHDL einen Mikroprogramminterpreter schreiben und damit eine weitere Abstraktionsstufe einziehen. Das geht grafisch dann gar nicht mehr.

|> Einen Zähler mit vielen Bits/FlipFlops wöllte ich weder als Stromlauf, |> noch als Zustandsmaschine entwerfen. Dafür ist VHDL oder Verilog sehr |> viel besser geeignet. |> |> Ich neige dazu, für jeden Zweck das dazu am besten geeignete Werkzeug zu |> verwenden. Die Beschreibungssprachen sind aber nicht für alles die beste |> Wahl. |> Nur -- wie bereits geschrieben -- muss man sie in vielen Fällen trotzdem |> verwenden, um bezüglich der Werkzeuge einigermaßen flexibel zu bleiben.

Ein Killerkriterium für mich ist, dass man mit Text auch "diff" nutzen kann. Fürs Änderungsmanagement (was habe ich gemacht, dass es auf einmal nicht mehr geht...) ist das ideal. Ich wüsste nicht, wie man das vernünftig grafisch machen könnte.

--
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
 Click to see the full signature
Reply to
Georg Acher

|> Ich finde es auch recht teuer.

Naja, wenn es die Aufgabe löst, kann das egal sein. Mein Eindruck ist nur (habe da so ein paar grössere LabView-Projekte "live" gesehen, schon beeindruckend, was damit alles geht), dass man nach einiger Zeit vor lauter Sub-VIs gar nicht mehr weiss, was da wo und wie die Aufgabe tatsächlich löst ;-)

In einem konkrekten Fall, wo auch noch das Verhalten der Anlage zu bestimmen/entwickeln war, wäre irgendeine Interpretersprache (VB, Perl, ...) fürs Rapid-Prototyping ganz sicher besser (schneller) gewesen.

|> Also hier geht das noch ganz buergerlich mit Schaltbildern. Derzeit mit |> Eagle.

Analog ist das IMO auch was anderes, man kann einfach nicht genügend von RCL und den verschiedenen D/T-Kennlinien abstrahieren. Das wäre irgendwie so, als gebe es eine Million verschiedener AND-Funktionen mit zwei Eingängen...

Aber mach mal ein Design mit einigen zig-zehntausend Gattern in Schematics. Geht schon, dauert aber lange und es strengt schon irgendwie an. Ich schraube gerade (allein) an einem FPGA-Design, das liegt jetzt schon so bei ca. 1.6Mio Gattern. Das will ich nicht mehr mit Schematics und 74er-Libs machen. Das Board dazu ist aber in Eagle ;-)

--
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
 Click to see the full signature
Reply to
Georg Acher

Am Mon, 11 Jun 2007 17:22:58 -0700 schrieb Joerg:

Die kostet bei LabView dann zumindest nichts mehr, ist aber ein recht grosser Brocken.

Aber ich wollte keine Lanze für LabView brechen. Ich hatte mich damit beschäftigt, weil immer wieder Kunden nach einer Anbindung fragten.

Und so habe ich dann mal ein VI erstellt.

Lutz

--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im 
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin 
 Click to see the full signature
Reply to
Lutz Schulze

lvdiff!

formatting link

Viel Spa3 damit.... Gru3 Uli

--
Achtung, bitte *nicht* an diese unsinnige Email-Adresse antworten. 
Der Grund: zu viel Spam. Ich lese die NG, in die ich schreibe.
Reply to
Uli Wannek

Was es alles gibt, danke... Das macht aber doch nur eine "textuelle" Differenz, mit der höchstens RCSe was anfangen können, oder? Wenn schon, sollte man im selben Darstellungsbereich bleiben, also die Änderungen in den VIs grafisch darstellen. Das stelle ich mir reichlich schwierig vor, weil sich doch eine ganze Menge in den Properties der verdrahteten Bauteile abspielt, die man im Normalfall gar nicht sieht...

--
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
 Click to see the full signature
Reply to
Georg Acher

Hallo Georg,

was

fürs

Wichtig ist auch, was sich zum de-fakto Standard entwickeln wird. So wie ja auch MS-Word der de-fakto Standard zum Doku-Schreiben ist, koennte es LabView im Messtechnikbereich werden. Dann spielen die Anschaffungskosten eine untergeordnete Rolle. Es kommt dann darauf an, wie schnell man Ingenieure als Consultants bekommen kann, die wenigstens einigermassen in der Naehe sind.

Bisher kannten bei jedem Kunden einige Leute LabView, manche hatten darauf schon mal etwas programmiert, und wenn es damals im Studium war. Als ich gestern bei einem Kunden fragte, of sie DAQFactory kennen, war leider Pustekuchen.

und

Geht

Gattern.

FPGA kann etwas anderes sein. Obwohl ich auch davon einige durch Standard-Logik ersetzt habe, nachdem sie entweder zu teuer oder abgekuendigt wurden. Ich setze FPGA kaum ein, deren Produktionslebensdauer ist meist viel zu kurz. Bei mir muss das fast immer >15 Jahre sein, besser 20 Jahre.

--
Gruesse, Joerg

http://www.analogconsultants.com
Reply to
Joerg

Hallo Lutz,

Tja, massive Werbung zahlt sich eben doch aus. Auch hier kennen viele Leute LabView, doch oft kein einziges Konkurrenzprodukt. Aus dem Grunde ist wohl auch OrCad immer noch der Standard, obwohl Eagle billiger ist und IMHO viel besseren Support bietet. Dass sie keine hierarchischen Strukturen machen wollen, halte ich bei Eagle fuer einen Kardinalfehler, wodurch es bei vielen Projekten auch beim besten Willen einfach nicht einsetzbar ist. Aber das Hauptproblem: Es gibt kaum Werbung und damit kennt es fast keiner. Bei meinen Kunden bisher nicht ein einziger Ingenieur.

--
Gruesse, Joerg

http://www.analogconsultants.com
Reply to
Joerg

Hierarchie und beliebige Attribute sind das, was bei Eagle für "grosse" Projekte fehlt. Name und Wert sind halt nicht alles. Das gabs schon bei dem Uralt-DOS-Viewlogic. Zwar etwas sperrig in der Eingewöhnung, dann aber recht brauchbar...

Und irgendwie habe ich bei Eagle den Trick auch noch nicht geschafft, Bauteile von einer Schaltplanseite auf eine andere zu schieben, ohne das schon gemachte Layout zu löschen...

--
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
 Click to see the full signature
Reply to
Georg Acher

Hallo Georg,

Attribute kommen in der Version 5. Da haben wir alle ordentlich fuer gequengelt. Die Hierarchie haben sie nicht eingesehen und die kommt m.W. auch nicht. Damit schliesst sich Cadsoft aus einem fetten und zahlungskraeftigen Marktsegment aus. Aber irgendwie verstehen sie das nicht. OrCad konnte beherrschte die Hierarchie auch schon in der DOS Version.

Nun ja, dafuer hat man mit Eagle aber eine schoene integrierte Umgebung. Nur dass ich keine Layouts mache...

Da steckt so viel Marktpotenzial drin. Wenn sie denn mehr Werbung und eine Hierarchie bringen wuerden.

--
Gruesse, Joerg

http://www.analogconsultants.com
Reply to
Joerg

Ah, sollte doch auch mal die eagle-NG lesen. Endlich wird eine Variantenverwaltung möglich...

Ja, schade. Würde aber vollständig durchgezogen sicher einen ziemliche Afwand machen. Das muss ja dann nicht nur im Schaltplan sondern auch im Layout gehen (damit man fertig geroutete Subcircuits einbauen kann).

Viewlogic auch. Und es war sogar richtig intuitiv bedienbar, was man vom Rest nicht behaupten konnte...

Ich stelle mir programmässig das Verschieben gar nicht so kompliziert vor. In der Netzliste ändert sich ja nichts nichts.

Tja...

--
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
 Click to see the full signature
Reply to
Georg Acher

Hallo Georg,

Variantenverwaltung

Und wir Consultants koennen endlich gescheite Kunden-Libraries anlegen, mit den ECO Freigabenummern der Kunden.

Das wuerde nicht nur viel Arbiet sparen, es ist in stark reglementierten Industriezweigen sogar "der" Prozess. D.h. die koennen Eagle gar nicht benutzen, selbst wenn sie es wollten.

Ist ein Problem vieler europaeischer Firmen, bis auf den Automobilbereich. Manchmal muss man denen sogar alles aus der Nase ziehen.

--
Gruesse, Joerg

http://www.analogconsultants.com
Reply to
Joerg

In article , "=?ISO-8859-1?Q?G=FCnther?= Dietrich" writes: |> Praktikanten und Diplomanden (warum |> schreibt man die einen mit "t" in der letzten Silbe, die anderen dagegen |> mit "d"? Scheint mir vollkommen unlogisch)

Dann hast Du im Deutschunterricht gepennt.

Transpiranten schwitzen schon, die Transpiranden hingegen sind da noch nicht angekommen...

Sprich: Praktikanten *sind* es schon -- sie üben just ein Praktikum aus.

Diplomanden sind jedoch erst dabei, ihr Diplom zu erwerben. So wie Doktoranden promovieren und Habilitanden sich habilitieren. Sie haben den Zielzustand jedoch noch nicht erreicht.

Nicht alles, was man nicht versteht, ist unlogisch.

Rainer

Reply to
Rainer Buchty

Joerg schrieb:

....

...

Wenn man das Produkt in ein anderes Marksegment hebt, besteht allerdings auch die Gefahr, Begehrlichkeiten zu erwecken.

Wenn Eagle den Weg vieler anderer guter CAE/CAD-Systeme in den Schlund des großen Mento ... öhm Molochs geht, ist auch keinem geholfen.

Viele der von Oliver Bartels betrauerten "toten Pferde" sind ja leider diesen Weg schon gegangen. ;-)

Aus rein technischer Sicht hatten/haben Viewlogic und auch OrCad den Anspruch, in einer ganz anderen Liga zu spielen als CadSoft das mit Eagle offensichtlich vorhat.

Moins Paul

Reply to
Paul Drachner

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.