Not-Aus-Funktion bei LabView

Da ich nicht Programmierer bin hinkt der Vergleich, ich bin Elektriker/Elektroniker, ich verstehe Schaltungen und kann sie entwerfen. Zu meiner Zeit gehörte programmieren nicht zur Ausbildung und auch später nicht.

Siehe oben. Ich will für meine Steuerung/Regelung/Hausautomation nicht programmieren lernen, dazu bin ich zu alt/habe keine Lust.

Nicht für mich, das Programmieren wäre für mich fast ünmöglich und das Zusammenmalen finde ich nicht aufwendig(ich habe mir bis jetzt nur Softwire etwas angesehehen, nehme aber an das Labview ähnlich ist) und die gemalene Schaltung aussagekräftig, im Gegensatz zu so komischen geschriebenen Zeilen.

Ernst

--
Was ist TOFU? Wieso finden die anderen meine Artikel schwer zu lesen?
TOFU steht für "Text Oben, Fullquote Unten". Das ist eine Unart, die einen
nicht nur in dieser Newsgroup, sondern im ganzen Netz unbeliebt macht.
Lies "Wie zitiere ich im Usenet?": http://www.afaik.de/usenet/faq/zitieren/.

Matthias Baur schrieb:

Über einen Automaten, der NOT-AUS als Zustand kennt. Übrigens sollten sich per NOT-AUS in einer zentralen Ausgaberoutine alle relevanten Steuersignale auf definierten Wert setzen lassen.

Gruss Udo

z.B. Prüfstände. Ich habe mal einen mitprogrammiert, da löste "Notaus" auch in der ersten Variante die Drehzahlvorgabe "Null" aus. Da der Prüfstand ziemlich großzügig dimensioniert war führte das dazu daß sich der Prüfling zerlegte. Der Bugfix war dann halt die Drehzahl zwar extrem schnell aber dennoch "definiert langsam" herunterzufahren.

Wenn die Verbindung zum Steuerrechner unterbrochen worden wäre hätte der Motor auch keinen Strom bekommen und wäre dann wohl recht langsam zum Stillstand gekommen. Ich weiß nicht ob dieser Fall gezielt betrachtet wurde. Das ist alles zu lange her.

Wie ich schon schrieb: was man in wenigen Stunden entwickelt.

Nö. Es gibt Werkzeuge, die einem helfen, Probleme zu lösen, und es gibt welche, die einen dabei eher behindern. Hierzu würde ich ganz eindeutig Labview zählen.

Grafische Programmierumgebungen haben keine Vorteile, auch wenn die Marketingabteilungen das Laien gerne versuchen einzureden.

Wenn man etwas Know-How hat, behindert das alles nur.

Vor allem sind grafische Geschichten total unübersichtlich. Ein VI mit 10 Anschlüssen ist doch kaum zu überblicken.

C-APIs bekommst Du auch an jeder Ecke.

Wer unwillig ist, soll IHMO @home bleiben und anderen Leuten nicht ihre Zeit mit solchen Schrott stehlen.

cu, Marco

--
E-Mail: mb-news-blinuxhaven.de
Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de

Bin ich ja!

Verstehe ich nicht, spielt auch keine Rolle, ich mache das für mich.

Ernst

--
Was ist TOFU? Wieso finden die anderen meine Artikel schwer zu lesen?
TOFU steht für "Text Oben, Fullquote Unten". Das ist eine Unart, die einen
nicht nur in dieser Newsgroup, sondern im ganzen Netz unbeliebt macht.
Lies "Wie zitiere ich im Usenet?": http://www.afaik.de/usenet/faq/zitieren/.

Komisch, wieso sind dann so "einfache" Programme so teuer? Was verstehst du unter "wenigen Stunden"?

Ernst

-- Was ist TOFU? Wieso finden die anderen meine Artikel schwer zu lesen? TOFU steht für "Text Oben, Fullquote Unten". Das ist eine Unart, die einen nicht nur in dieser Newsgroup, sondern im ganzen Netz unbeliebt macht. Lies "Wie zitiere ich im Usenet?":

Hallo,

Am 21.06.2004 20:04 schrieb Marco Budde:

Und das ist deiner Meinung nach nur mit textuellen Programmierumgebungen möglich? Eine Meinung die ich nicht teile.

Vergiss nur nicht, dass nicht jeder deine Programmierkenntnisse besitzt. Dich mögen sie behindern, anderen mögen sie helfen, das war alles was ich sagen wollte.

Und andere Marketingabteilungen versuchen mir einzureden, ich komme nur mit textuellen Programmiersprachen weiter. So will halt jeder sein Zeug verkaufen. Gut ist der dran, der beide Segmente bedienen kann, z.B. Agilent mit seinem VEE Paket und seinem T&M Toolkit.

Was ist etwas Know-How? Ich fand es sehr einfach mit VEE diverse Geräte zur Kommunikation zu übereden, ohne mich erstmal um lästige Programmieraufgaben zu kümmern, z.B. Speichermanagement und GUI. Damit war es mir erstmal möglich das Problem schnell zu lösen und ein erstes Ergebnis zu präsentieren. Ich will natürlich nicht verschweigen, dass einem irgendwann diverse Features andere Porgrammiersprachen vielleicht fehlen. Aber um schnell einen Test zwischendurch zu realiseren ist VEE sehr gut geeignet, vor allem weil es sich auf Messtechnik spezialisiert und für viele Anwendungsfälle schon eine Lösung parat hat, speziell auch im Bereich der Visualisierung.

Eine Funktion mit 10 Parametern ist auch nicht sehr übersichtlich. So hat alles seine Vor- und Nachteile.

Aber bei VEE suche ich das Gerät mit dem Intrumentmanager lege ein kleines Direct-IO Objekt an und kann schon mittels SCPI (wenn es das Gerät unterstützt) kommunizieren. Einfacher gehts nicht und auch sehr einfach von nicht hauptberuflichen Programmierer einsetzbar.

Entschuldige, aber nicht jeder der VEE oder etwas anderes benutzt tut dies die ganze Zeit. Diese Leute haben meist eine andere Haupttätigkeit. Diese Leute würde ich nicht unbedingt als unwillig bezeichnen sondern eher unter Zeitdruck.

Ich will hier niemanden missionieren zu graphischen Programmiersprachen zu wechseln, aber deine prinzipiell ablehnden Haltung kann ich gar nicht verstehen, da sie am Ziel vorbei geht. Du benutzt deine textuellen Sprachen, ich benutze beides und ein anderer nur eine graphische Sprache. Wenn jeder sein Ziel erreicht, ist daran nichts verkehrt.

MfG

Stefan

--
Dreams are free, but you get soaked on the connect time.

Am Mon, 21 Jun 2004 20:04:39 +0200 schrieb Marco Budde:

Ich komme in wenigen Stunden mit LabVIEW garantiert viel weiter als in C!

Auch Computer machen Probleme und du benutzt trotzdem einen. Mich hat LabVIEW noch nie bei einer Problemlösung behindert. Es kommt sicher vor, daß mal was nicht gleich auf anhieb klappt aber die Fehlersuche ist recht komfortabel.

Natürlich haben grafische Programmierumgebungen vorteile! Kauf dir mal ne Maus und einen Farbmonitor und du wirst es selber merken!

Stimmt nicht allgemein. Evtl. bei dir.

Da kommt es wohl wie immer auf den Programmierer an!

Ich bin auch unwillig mich mit C herumzuschlagen wenn ich die anstehende Aufgabe mit einem Bruchteil von Knoffhoff und Zeit mit LabVIEW lösen kann.

Gruß Peter

Vielleicht, vielleicht auch nicht, kann ich von hier aus natürlich nicht sehen. Aber auch Anderes braucht Zeit, viel Zeit. Ich hab jetzt schon viele Generationen Doktoranden kommen und gehen gesehen. Und alle hielten sich für Programmierer und mussten da ihre Duftmarke hinterlassen. Und jeder hatte genau so viel Zeitmangel, dass es zwar für das Programm, nicht aber für die Dokumentation gereicht hat. Und irgendwann ändert sich die Hardware, Rechner oder die angesteuerten Geräte, und dann? Es ist beinahe unmöglich innert irgend einer nützlichen Frist das Programm zu analysieren und zu ändern. Nach eigener Erfahrung geht das sogar noch mit Fortran besser als mit C, letztere Sprache fördert Unübersichlichkeit und Lesbarkeits- behindernde "Individualität" durch ihre unsägliche nicht- Orthogonalität beträchtlich. Mit Sprachen der vierten Generation sieht das anders aus, sowohl bei Rechner/OS Wechsel wie beim wechsel der angeschlossenen Geräte (dank genormter Schnittstellenmodule).

Sprachen der dritten Generation sind da nicht hilfreich. Mit denen muss man dem Rechner sagen, _wie_ er etwas machen muss, nicht _was_ er machen muss.

IMHO gibt es Leute, die können/wollen nicht von 24x80 monochromen Zeichen wegkommen. Man erkennt sie an nichtssagenden aber diffamierenden Schlagworten wie "klicki-bunti" oder "Mausepileptiker". Ich hab's jedenfalls geschafft. Ich konnte anno Tobak auch den Bootloader in die PDP8 auswendig eintoggeln, aber irgendwie trauere ich dieser Zeit nicht nach. Chinesisches Sprichwort sagt; wenn der Sturm der Veränderung bläst, errichten die einen Mauern, die andern Windmühlen.

Das sehe ich auch so, zugegebenermassen. Andererseits Quizfrage: Was war denn die erste grafische Programmiersprache, zu einer Zeit, als es noch keine Rechner gab und niemand wusste was das ist?

Allerdings. Ich habe eher den Eindruck, dass die Esotheriker ihre Felle davonschwimmen sehen und langsam um ihren Job bangen. IT ist keine Technik der Zukunft, solange sie soviel Arbeitsplätze bindet. Viele finden das zwar toll, diese Arbeitsplätze "Dank" blosser Existenz der Computer, allerdings war die künstliche Schaffung von letztendlich unproduktiven Arbeitsplätzen nie eine Stütze der Wirtschaft.

--
mfg Rolf Bombach