Announcement: there is an English version of this forum on Hallo Leute Eine While-Schleife wird ja mit einer festen Zeit abgetastet. Ich möchte allerdings eine variable Abtastrate haben. Also z.B. das erstmal wird die While-Schleife nach 3s durchgefüht und danach z.B. nach 10s. Ich hab aber keine Ahnung wie man das in Labview umsetzen kann? Zur Info noch: Die Werte werden durch eine Textdatei eingelesen und sind somit in einem Array hinterlegt. Vielen Dank für die Hilfe LG
Beitrag #6824966 wurde von einem Moderator gelöscht.
Beitrag #6824991 wurde von einem Moderator gelöscht.
Beitrag #6825021 wurde von einem Moderator gelöscht.
Hallo Johannes, im Prinzip kannst du in der While-Schleife einen Warte-Befehl einfügen, dessen Verzögerung du mit den Werten deines Arrays fütterst. https://zone.ni.com/reference/en-XX/help/371361R-01/glang/time_dialog_and_error_func/ Das Wait until next ms Multiple ist z.B. sehr üblich, um den Zeitablauf von Schleifen zu kontrollieren. Und natürlich kannst du den Eingabewert so groß setzen, dass er auch mehrere Sekunden abdeckt. Allerdings ist es in den meisten Fällern eher unüblich, die Schleifen wirklich nur alle paar Sekunden einmal weiterlaufen zu lassen. Das kann zwar ok sein, aber du musst dir bewusst sein, dass dann eben wirklich ein paar Sekunden lang nichts aus dem Schleifeninhalt ausgeführt wird (z.B. auch keine Aktualisierung von Anzeigen oder odergleichen). Oft wird es vielleicht sinnvoller sein, die Schleife in einem festen Zeitraster auszuführen (z.B. alle 10ms) und innerhalb der Schleife über einen Zähler entscheiden zu lassen, ob beim aktuellen Schleifendurchlauf eine bestimmte Aktion durchgeführt wird, die eben nur bei 3s oder bei 10s durchgeführt werden soll. @ c-hater: das Niveau deines Beitrags ist wirklich unterirdisch.
Achim S. schrieb: > Das Wait until next ms Multiple ist z.B. sehr üblich, um den Zeitablauf > von Schleifen zu kontrollieren. Und natürlich kannst du den Eingabewert > so groß setzen, dass er auch mehrere Sekunden abdeckt. Und weil das missverständlich war: das wait until next ms multiple wartet ja auf ganze Vielfache der angegebenen Verzögerungszeit. Wenn du da von Zyklus zu Zyklus die Zeit ändern willst, wird es tatsächlich eine etwas umständliche Rechnerei. Wenn du also nicht die Variante mit festem Zeitraster und Zähler wählen sondern wirklich die Schleife mehrere Sekunden lang lahmlegen willst, dürfte ein Wait(ms) für dich einfacher einsetzbar sein.
Johannes T. schrieb: > Eine While-Schleife wird ja mit einer festen Zeit abgetastet. > Ich möchte allerdings eine variable Abtastrate haben. Also > z.B. das erstmal wird die While-Schleife nach 3s durchgefüht > und danach z.B. nach 10s. Ich hab aber keine Ahnung wie man > das in Labview umsetzen kann? Naja, ich würde die Schleife mit 1s Wiederholrate programmieren und als erstes IN der Schleife prüfen, ob im aktuellen Durchlauf ein Wert erfasst werden soll oder nicht. Die gewünschten Zeiten müssen natürlich in einem Array o.ä. stehen. Das sollte sich in jeder beliebigen Sprache ausdrücken lassen.
c-hater schrieb im Beitrag #6825021: >> Das Niveau Deines Posts ist unterirdisch. > > Das sagst du, aber frag' mal eine Geistig Gesunden... Ungenießbare Mischung aus inhaltlicher Debilität und zielloser Aggressivität im Ausdruck. Also alles wie immer. Ich kann nur Jake Harper zitieren: "Such Dir Hilfe!"
Beitrag #6825082 wurde von einem Moderator gelöscht.
Beitrag #6825094 wurde von einem Moderator gelöscht.
c-hater schrieb im Beitrag #6825082: > Mein Gott, das sind doch alles abolute Trivialitäten. Offenbar doch nicht so ganz... > Und wieder stört diese Hochsprache... Schwachsinn. Der Kern des Problems liegt darin, dass die gängigen Hochsprachen 1. für Berechnungen (Algorithmen) auf 2. sequentiellen Maschinen optimiert sind. Eine Steuerungsaufgabe ist aber, wie Du richtig erkannt und formuliert hast, kein "Algorithmus", eben weil es insgesamt gesehen nicht darauf ankommt, "mit endlich vielen Schritten ein Ergebnis" zu erzielen. Das hast nichts mit Hoch- oder Maschinensprache zu tun, sondern damit, dass die "richtigen" Informatiker traditionell die Steuerungstechnik als Arbeitsbeschaffungs- maßnahme für debile Elektriker ansehen. Die üblichen Programmiersprachen werden somit für Aufgaben eingesetzt, für die sie nicht geschaffen sind. Das Ergebnis sind GUIs, bei denen zu den unmöglichsten Zeiten die Maus einfriert, oder Videokonferenzsysteme, bei denen dasselbe mit der Bildübertragung passiert.
Auch wenn es der überlaute Affe aus der Computersteinzeit nicht verstehen mag: Echtzeitverhalten ist nicht eine Frage der Programmiersprache sondern der verwendeten Hardware und des Betriebssystems. Für LabView gibt es dazu passend die LabView-RT Systeme. Egon D. (egon_d) >Das hast nichts mit Hoch- oder Maschinensprache zu tun, >sondern damit, dass die "richtigen" Informatiker >traditionell die Steuerungstechnik als Arbeitsbeschaffungs- >maßnahme für debile Elektriker ansehen. Da hast du schon einen wahren Punkt angesprochen: PCs sind historisch eher auf statische, zeitlose Berechnungen und Arbeitsweisen ausgelegt. Echtzeiverhalten wie Video und Ton sind dort eher künstlich überlagert. Nimmt man hingegen Embedded Systeme, wie sie millionenfach in Autos eingebaut sind und auf unseren Straßen herum fahren, sind die meistens in C programmiert oder der Code mit einem Simulink Codegenerator (Motorsteuerung) generiert. >Die üblichen >Programmiersprachen werden somit für Aufgaben eingesetzt, >für die sie nicht geschaffen sind. Wobei man anmerken muss, dass Echtzeisysteme in der Mehrheit mit höchster Wahrscheinlichkeit in C programmiert sind. Dort kommen dann Timer uns Synchronization Points zum Einstatz, was dem weiter oben angesprochenen "Wait-Until-Multiple" nahekommt.
Vielleicht hilft Dir das: https://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/con_select_timed_struct_timing/ https://zone.ni.com/reference/en-XX/help/371361R-01/glang/create_timing_source/ Ich habe schon zu lange nicht mehr mit LV gearbeitet, kenne aber das Problem von früher her. Mit der Timng source lässt sich Deine Routine triggern. Vielleicht lässt sich Dein Problem damit zufriedenstellend lösen.
Ähh Jungs,... macht mal langsam. Soweit ich das verstehe, ist der TO Anfänger im LabVIEW. Weil Wartezeiten sind Bassiswissen in LabVIEW (LabVIEW nutzt die Wartezeiten um derweil die CPU an andere Prozesse weiter zu geben) Er redet von Sekunden, da wird ganz bestimmt kein Echtzeit OS benötigt. Seid nett zu Ihm, das grafische programieren muss auch erst verinnerlicht werden. 1. Eine Schleife läuft in LabVIEW mit maximal möglicher Geschwindigkeit. Wenn da keine Wartezeit (oder ähnliches) verbaut ist, so braucht die eine Schleife eine ganze CPU mit 100% Last. 2. Die Wartezeit wird intern genutzt um die CPU an andere Prozesse abzugeben. Damit kann das OS z.B. die CPU in Pause schicken. 3. Die einfachste Möglichkeit ist die Wartezeit oder die oben genannte "Wait until next ms Multiple" 4. Während der Wartezeit wird nichts verarbeitet. Sämtliche Bedienelemente funktionieren zwar, bewirken aber nichts. 5. Schleifen können auch nebeneinader liegen. Die werden parallel abgearbeitet. (Wie exakt parallel entscheidet LabVIEW) Was bedeutet, während die eine Schleife gerade wartet, kann in der anderen Schleife z.B. auf Bedinelemente reagiert werden. 6. Das mit den Warteschleifen ist für kleinere Sachen gut geeignet. Das skaliert leider nicht ganz sauber. Bei größeren Programmen (ab ca. 2m² Quellcode oder so.) muss man sich dann eher mit Ereignissen oder den angesprochenen "timing source" befassen. Wie gesagt, bei größeren Sachen. Wer das bracht, ist dann aber schon weit genug um zu sehen warum er das jetzt doch braucht.
Angehängte Dateien:
Benutze die timed loop schleife. da gibts einen eingang der dt heist, da kannst du die wartezeig gleich anpassen für den nächsten druchlauf. gruess soundso
LabView ist echt die Pest. Das wird häufig an Universitäten benutzt und spiegelt genau die Arbeitsweise wieder: Chaos bis zum Abwinken und die Nachfolger müssen neu programmieren weil unlesbar.
Gerd schrieb: > Da hast du schon einen wahren Punkt angesprochen: PCs sind historisch > eher auf statische, zeitlose Berechnungen und Arbeitsweisen ausgelegt. > Echtzeiverhalten wie Video und Ton sind dort eher künstlich überlagert. > Nimmt man hingegen Embedded Systeme, wie sie millionenfach in Autos > eingebaut sind und auf unseren Straßen herum fahren, sind die meistens > in C programmiert oder der Code mit einem Simulink Codegenerator > (Motorsteuerung) generiert. Du hast auch noch nie in der realen Welt gearbeitet, oder? In Produktivsystemen mit Simulink generierter Code?! Bitte bitte verdiene dein Geld mit etwas anderem.
c-hater schrieb im Beitrag #6825082:
> Und wieder stört diese Hochsprache...
Nö, die stört überhaupt nicht.
Im Gegenteil, sie hilft enorm, einen ordentlichen Scheduler (z.B. im
Timerinterrupt) zu implementieren und diesem einen Callback mit der
gewünschten Verzögerungszeit zu übergeben.
Eine Hochsprache ist nicht dazu da, alle Eventualitäten voraus zu ahnen.
Sie soll einfach nur das Werkzeug sein, um beliebige Tools (Libs)
komfortabel zu implementieren.
Assembler kann das nur extrem umständlich und wird daher von
professionellen Programmierern schon lange nicht mehr eingesetzt.
Assembler kennt keine Variablen, Funktionen, Argumente usw. und kümmert
sich nichtmal um den Stack. Assembler ist wie ein offenes Scheunentor
für jegliche Arten an Programmierfehlern. Er kann nur Mnemonics
übersetzen und nichts weiter.
Das Schimpfen auf die Hochsprache ist völliger Humbug, aber so kennen
wir Dich. Laß Dir mal was neues einfallen, das langweilt nur noch.
Und hör endlich auf, den gleichen Psalm wieder und wieder runter zu
beten. Wir haben ihn schon vor vielen Jahren von Dir gelesen.
Dennis H. (Gast) 21.09.2021 08:58 >LabView ist echt die Pest. Das wird häufig an Universitäten benutzt und >spiegelt genau die Arbeitsweise wieder: Chaos bis zum Abwinken und die >Nachfolger müssen neu programmieren weil unlesbar. Jetzt müsstest du noch zeigen, dass an den Universitäten mit anderen Programmiersprachen kein Chaos erzeugt wird. Bei LabView gilt: Man muss es können. Anfänger produzieren leicht unwartbaren Code wie mit jeder anderen Programmiersprache auch. Im übrigen wird LabView nicht nur an Unversitäten verwendet, sonst könnte National Instruments seinen Umsatz von 1.35 Millarden nicht halten. Wenn du in einer Bastelbude arbeitest, wirst du's eher nicht bekommen in grösseren Konzernen ist es sehr verbreitet. >Gerd schrieb: >> Da hast du schon einen wahren Punkt angesprochen: PCs sind historisch >> eher auf statische, zeitlose Berechnungen und Arbeitsweisen ausgelegt. >> Echtzeiverhalten wie Video und Ton sind dort eher künstlich überlagert. >> Nimmt man hingegen Embedded Systeme, wie sie millionenfach in Autos >> eingebaut sind und auf unseren Straßen herum fahren, sind die meistens >> in C programmiert oder der Code mit einem Simulink Codegenerator >> (Motorsteuerung) generiert. >Du hast auch noch nie in der realen Welt gearbeitet, oder? Vielseitig und lange, deshalb habe ich auch viel mehr Erfahrung als die lautstarken Praktikanten hier. >In >Produktivsystemen mit Simulink generierter Code?! Bitte bitte verdiene >dein Geld mit etwas anderem. Quack hier mal nicht so laut rum. Ich war bei der Motorsteurungsentwicklung eines namhaften Herstellers in einem Nachbarbereich, dehalb weiß ich so ungefähr, was da drinn ist. Während des Dieselskandals gab's mal einen Hacker, der eine der Boschsteuerungen analysiert hat und dort den generierten Simulink Code beschrieben hat.
Gerd schrieb: > Im übrigen wird LabView nicht nur an Unversitäten verwendet, sonst > könnte National Instruments seinen Umsatz von 1.35 Millarden nicht > halten. > Wenn du in einer Bastelbude arbeitest, wirst du's eher nicht bekommen in > grösseren Konzernen ist es sehr verbreitet. Jepp. Warum wohl: Weil in größeren Konzernen überproportional viele Entscheider einfach mal keine Ahnung haben. Das ist so, weil kleinere Firmen sehr schnell pleite sind, wenn sie sich solche Entscheider leisten wollen würden. Es kann sich also niemals eine für die Statistik signifikante Menge kleinerer Firmen ansammeln, die nutzlos LabView verwenden. Das heißt natürlich nicht, dass es solche Firmen nicht doch gäbe (typisch mit nur einem Entscheider, der allerdings auch wenig bis keine Ahnung hat). Die sind dann aber eben typisch sehr eng gebundener Zulieferer eines großen Konzerns. Quasi also eigentlich nicht wirklich Firmen mit einiger Entscheidungsfreiheit, sondern auf Gedeih und Verderb auf ihren Haupt- (oder sogar einzigen) Kunden ausgerichtet. Aber auch die gibt es typisch nicht allzu lange. Wenn die Konzern-Seilschaften wechseln (was auch in sehr großen Konzernen gelegentlich passiert), dann sehen sich diese Firmen sehr schnell mal der Situation ausgesetzt, dass ihr Kundenbestand und erwartbarer Umsatz in absehbarer Zukunft auf (nahezu) Null fällt. Allein die Lizenzkosten für LabView sorgen dann sehr schnell dafür, dass die Firma auch sehr schnell zahlungsunfähig wird. Denn, anders als Mitarbeiter, kann man die nicht in Kurzarbeit schicken. Also vom Steuerzahler bezahlen lassen. Aber die FDP wird's auch dieses Problem irgendwann noch richten...
Peter D. schrieb: > Nö, die stört überhaupt nicht. > Im Gegenteil, sie hilft enorm, einen ordentlichen Scheduler (z.B. im > Timerinterrupt) zu implementieren und diesem einen Callback mit der > gewünschten Verzögerungszeit zu übergeben. Und du glaubst ernsthaft, das Task-Scheduling in Hochsprache besser geht? Dann wäre wohl zu fragen, warum praktisch alle RTOS das dann doch im Kern in Asm abhandeln... Alle doof, außer du?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.