Not-Aus-Funktion bei LabView

[Stefan Ohrmann]

Hallo,

Am 20.06.2004 09:26 schrieb Marco Budde:

Für simple Steuerungen, die man in C/C++ in wenigen
Stunden runterschreibt, braucht man in Labview Tage
oder Wochen. Dieses ganze Zusammengemale von Schaltungen
ist einfach wahnsinnig aufwendig und IHMO vor allem
total unübersichtlich.

Was ist simpel? Diese Aussage ist genauso falsch, wie zu behaupten mit
VEE/LabView geht es schneller. Meiner Meinung nach haben die grafischen
Programmierumgebungen ihre Stärken in der vielfältigen
Geräteunterstützung im Bereich GPIB. Damit lassen sich auch durch
ungeübte/unwillige Programmierer schnell Tests automatisieren und
Datenlogger erstellen.

MfG

Stefan

--
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not Eureka! (I found it!) but rather, 'hmm.... that's
funny...'
- Isaac Asimov

 

[Ernst Keller]

On Sun, 20 Jun 2004 09:26:18 +0200, Marco Budde <mb-news-a@linuxhaven.de>
wrote:

Ernst Keller wrote:

cu, Marco (der sich immer wieder wundert, warum die Leute solche
Produkte einsetzen, Gruppenzwang ?)
Was verwendet man dann deiner Ansicht nach um eine Softwaresteuerung/Regelung
zu machen wenn man nicht programmieren kann?

Was macht ein Tischler, der keine Kreissäge, Stichsäge
usw. bedienen kann?

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.

Du sprichst genau das Kernproblem an, warum die Leute
glauben, solche Tools benutzen zu müssen: es fehlt einfach
das Know-How für das eigene Handwerkszeug. In vielen
Bereichen ist es heute einfach notwendig, eine
Programmiersprache zu beherrschen.

Siehe oben. Ich will für meine Steuerung/Regelung/Hausautomation nicht

programmieren lernen, dazu bin ich zu alt/habe keine Lust.

Für simple Steuerungen, die man in C/C++ in wenigen
Stunden runterschreibt, braucht man in Labview Tage
oder Wochen. Dieses ganze Zusammengemale von Schaltungen
ist einfach wahnsinnig aufwendig und IHMO vor allem
total unübersichtlich.

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/.

 

[Udo Piechottka]

Matthias Baur schrieb:

Noch eines fällt mir gerade ein:
Wie kann man mehrere parallel laufende WHILE-Schleifen mit nur einem
Stop-Button steuern? Mit lokalen Variablen geht es zwar - allerdings
ist dann kann Latch-Schaltverhalten mehr zulässig.

Ü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

 

[Emil Obermayr]

On Fri, 18 Jun 2004 16:22:51 +0200, horst-dieter wrote:

Hast du ein konkretes Beispiel?

Bei Steuerungen muß immer mit Unterbrechung zum Steuerrechner gerechnet
werden.

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.

 

[Marco Budde]

Stefan Ohrmann wrote:

Was ist simpel?

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

Diese Aussage ist genauso falsch, wie zu behaupten mit
VEE/LabView geht es schneller.

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.

Meiner Meinung nach haben die grafischen
Programmierumgebungen ihre Stärken

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.

in der vielfältigen
Geräteunterstützung im Bereich GPIB.

C-APIs bekommst Du auch an jeder Ecke.

Damit lassen sich auch durch
ungeübte/unwillige Programmierer schnell Tests automatisieren und
Datenlogger erstellen.

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

cu, Marco

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

 

[Ernst Keller]

On Sun, 20 Jun 2004 14:43:57 +0200, Marco Budde <mb-news-a@linuxhaven.de>
wrote:

Ernst Keller wrote:

Geprüft und verworfen(bin zu alt),

Was hat das bitte mit dem Alter zu tun? Es gehört nun einmal
zu vielen heutigen Berufen, daß man täglich neue Dinge lernen
muß. Wer das nicht will, geht am besten in Rente.

Bin ich ja!

ich will nicht Programmieren, sondern
Schaltungen zeichnen/entwerfen.

Sehr effizient für den Arbeitgeber.

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/.

 

[Ernst Keller]

On Mon, 21 Jun 2004 20:04:39 +0200, Marco Budde <mb-news-a@linuxhaven.de>
wrote:

Stefan Ohrmann wrote:

Was ist simpel?

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

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?": http://www.afaik.de/usenet/faq/zitieren/.

 

[Stefan Ohrmann]

Hallo,

Am 21.06.2004 20:04 schrieb Marco Budde:

Stefan Ohrmann wrote:

Was ist simpel?

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

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

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.

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.

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

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.

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

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.

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

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

in der vielfältigen
Geräteunterstützung im Bereich GPIB.

C-APIs bekommst Du auch an jeder Ecke.

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.

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

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.

 

[Peter Zeitz]

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

Stefan Ohrmann wrote:

Was ist simpel?

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

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

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.

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.

Grafische Programmierumgebungen haben keine Vorteile, auch
wenn die Marketingabteilungen das Laien gerne versuchen
einzureden.
Natürlich haben grafische Programmierumgebungen vorteile! Kauf dir mal ne

Maus und einen Farbmonitor und du wirst es selber merken!

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

Stimmt nicht allgemein. Evtl. bei dir.

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

Da kommt es wohl wie immer auf den Programmierer an!

Wer unwillig ist, soll IHMO @home bleiben und anderen Leuten
nicht ihre Zeit mit solchen Schrott stehlen.
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.

cu, Marco

Gruß
Peter

 

[Rolf Bombach]

Peter Zeitz wrote:

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

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).

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.

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.

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.

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

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.

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

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?

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

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.

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