LabVIEWForum.de

Ja.

Gruß Markus

' schrieb:... habt ihr die Frage auch so verstanden wie ich?

Habe ich mich so unklar ausgedrückt?

' schrieb:Habe ich mich so unklar ausgedrückt?

Nee. Du hast nur das in Worte gefasst, was ich(wir) glaube(n), das Bil zu wollen glaubt.

Ich glaube ja mittlerweile, dass Bil hier auf einen Konflikt stößt zwischen dem was er eigentlich braucht und dem was er uns sagt, was er glaubt das er möchte.

Erstmal danke für eure mühe. hab es jetzt hingekriegt. Sorry

Danke

Gut.

Aber dann lade doch bitte einen Screenshot deiner Lösung hoch.
Bei der Verwirrung ist das verpflichtend.

Gruß SeBa

Hallo SeBa

Das was ich mir zusammen gebastelt habe, hat doch nicht so funktioniert.
Hab mir von dir das übernommen und es funktioniert wie ich es wollte.
nochmals vielen Dank.
sorry

Gruß

' schrieb:Was ist beser sicherer oder wird am meisten Verwendet??

Habe gerade Lust mich hier etwas zu verlustieren und tue das, indem ich jetzt etwas Senf absondere
Was ist besser?
Die größte Stärke von LV ist ja die quasiparallele Verarbeitund des Codes, und LabVIEW empfiehlt - weil das am schnellsten ist - das Programm so zu gestalten, daß man LV das tun läßt. D.h. keine künstlichen Datenabhängigkeiten in Form von Drähten oder Sequenzen herstellen, sondern nur wenn es notwendig ist.
Wenn es also keine Datenabhängigkeiten zwischen Schleife 1 und Schleife 2 gibt, dann ist Deine Idee, erst die Schleife 1 laufen zu lassen und dann Schleife 2, überhaupt nicht begründbar und keine gute Idee. Man sollte diese Entscheidung, was zuerst oder beides zugleich, LV überlassen.
Wenn es aber ein solche gibt, dann sind die beiden Beispiele von SEBA nicht völlig identisch, wie dieses Szenarium zeigt:
Angnommen, innerhalb von Schleife 1 wird die Anzahl von Durchläufen berechnet, die Schleife 2 ausführen soll und an eine lokale Variable übergeben.
Das würde dann mit Beispiel 2 (Sequenzen) funktionieren, nicht aber mit Beispeil 1, weil dort die I32-Variable an der 2.Schleife schon gelesen würde, bevor Schleife 1 überhaupt abgearbeitet wird.

Die optimale Lösung wäre dann ein Modifikation des Beispiels 1: Dies Ergebnis in Schleife 2 sollte nicht in eine lokale Variable geschrieben werden, sondern als Draht herausgeführt und direkt an die 2. Schleife angeschlossen werden. Auf den Errorcluster könnte dann verzichtet werden (Natürlich nur wenn der keine andere Funktion hat als die Datenabhängigkeit herzustellen)

' schrieb:Angnommen...

Ja... angenommen, was wäre wenn?

Deine Annahme ist ja nur eine Annahme, welche nicht aus der Problembeschreibung hervorgeht. Unbeachtet dessen, hast du natürlich Recht was deine Einwände betrifft.
Allerdings waren die Beispiele ja auch nicht unter der von dir angenommenen Voraussetzung erstellt, sondern eine direkte Umsetzung des in Beitrag #1 Geforderten.

Davon abgesehen, wer übergibt denn per lokaler Variable einen Wert von einer For-Schleife in/an die Nächste wenn diese im BD direkt nebeneinander liegen?


Gruß SeBa

' schrieb:Davon abgesehen, wer übergibt denn per lokaler Variable einen Wert von einer For-Schleife in/an die Nächste wenn diese im BD direkt nebeneinander liegen?

Bei Anfängern ist nichts unmöglich, und einzig diese zugegebenermaßen an den Haaren herbeigezogene Annahme macht es plausibel, daß Bill die Schleife 1 unbedingt vor Schleife 2 ausgeführt sehen möchte. Oder fällt Dir ein anderer vernünftiger Grund ein?

Mir fällt ein Grund ein der nicht technischer/logischer sondern emotionaler/menschlicher Natur ist, da der Mensch ja nun einmal ein Gewohnheitstier ist:

Bill hat bisher ausschliesslich textuell programmiert in C oder sowas. Da er dort die volle Kontrolle hat, wann welche Loop ausgeführt wird, auch dann wenn keine Datenabhängigkeit ywischen den beiden besteht, möchte er dies vermutlich auch jetzt haben. Sprich er hat es noch nicht akzeptiert, dass LV hier einen Vorteil bietet und andere Regeln befolgt werden müssen.

Nach meiner Erfahrung kommt eigentlich immer so etwas dabei heraus wenn wir einen C-Programmierer zum ersten Mal auf LV loslassen und er dann versucht etwas aus C-Code zu "übersetzen".