Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
07.09.2006, 07:17 (Dieser Beitrag wurde zuletzt bearbeitet: 07.09.2006 07:18 von Pascal.)
ich habe ein kleines Problem. Ich habe ein Programm (siehe Anhang) geschrieben, dass Motoren über Fequenzumrichter steuert. Hier werden mit DO und AO Werte für die Motoren vorgegeben. DAs Programm funktioniert zwar, aber wie ich schon mitbekommen habe, solle man ja den DAQmx Task starten und beenden außerhalb von der Schleife machen. Ich habe allerdings z.B. den AO auslesen in ein SubVI gepackt, um das Programm übersichtlicher zu machen. WEnn ich jetzt das Hauptprogramm starte, wird ja andauernd der Task gestartet, der WErt ausgelesen und wieder beendet. Kann das Probleme geben? Gibt es hierfür eine bessere Lösung? WEnn ich jetzt noch die ganzen Fehlerstatus der einzelnen SubVIs auslesen und mit Stopp verbinde, dann kann ich ja gar nichts mehr erkennen.
noch ne anmerkung. reicht die zip datei runterzuladen!
das Programm funktioniert. Das ist doch schon was.
Es ist übrigens nicht verboten einen Task ständig zu starten und wieder zu beenden. Dafür aber vielleicht nicht schön programmiert.
Die Sollwertvorgabe (50 Hz etc.) kannst Du aber anders programmieren.
So wie ich das sehe könntest Du jetzt mehrere Sollwerte gleichzeitig vorgeben, wenn mehrere Schalter gedrückt sind.
Das kannst Du umgehen wenn Du einen Enum (FP-Palette -> Ring&Enum) verwendest, und an diesen eine Casestruktur anschließt. Damit kannst Du die 4 Case-Strukturen durch eine ersetzen.
Alternativ kannst Du auch Optionsfelder verwenden.
Ich hab Dir ein kleines Beispiel angehängt.
Da wäre es dann ohne weiteres möglich statt des Physikalischen Kanal die TaskId an das SubVI zu übergeben und den Task außerhalb des VI zu Starten und zu beenden.
ich habe ein kleines Problem. Ich habe ein Programm (siehe Anhang) geschrieben, dass Motoren über Fequenzumrichter steuert. Hier werden mit DO und AO Werte für die Motoren vorgegeben. DAs Programm funktioniert zwar, aber wie ich schon mitbekommen habe, solle man ja den DAQmx Task starten und beenden außerhalb von der Schleife machen. Ich habe allerdings z.B. den AO auslesen in ein SubVI gepackt, um das Programm übersichtlicher zu machen. WEnn ich jetzt das Hauptprogramm starte, wird ja andauernd der Task gestartet, der WErt ausgelesen und wieder beendet. Kann das Probleme geben? Gibt es hierfür eine bessere Lösung? WEnn ich jetzt noch die ganzen Fehlerstatus der einzelnen SubVIs auslesen und mit Stopp verbinde, dann kann ich ja gar nichts mehr erkennen.
noch ne anmerkung. reicht die zip datei runterzuladen!
Pascal
Das schreit geradezu nach einer "Functional Global" ["Action Engine"].
danke für eure Antworten. Das mit den Optionsfeldern ist gut, da hätte ich auch selber drauf kommen können. Die "Action Engine" muss ich mir mal genau anschauen, sieht nicht ganz so einfach aus.
Pascal
08.09.2006, 11:22 (Dieser Beitrag wurde zuletzt bearbeitet: 08.09.2006 11:23 von cb.)
danke für eure Antworten. Das mit den Optionsfeldern ist gut, da hätte ich auch selber drauf kommen können. Die "Action Engine" muss ich mir mal genau anschauen, sieht nicht ganz so einfach aus.
Pascal
schaus dir schnell an
wenn man's mal begriffen hat, dann möchte man das nicht mehr missen.
nur EIN Vorteil gegenüber "herkömmlicher LV Programmierung" sei genannt: man spart sich ohne Ende Drähte, weil die Daten, die das VI braucht in dem VI selber gespeichert werden (in dem NICHT initialisierten Shift-Register). Die Instanzen des VIs lassen sich (sofern das vom Programm-Ablauf her möglich ist) als SubVI kreuz und quer durch das Programm verteilen, ohne, dass man immer die Drähte überall durchschleifen muss. Das Datenfluss-Prinzip kann man trozdem nutzen, weil ja noch der Error-Cluster da ist ...
und mal ehrlich, bei DEN KUPFERPREISEN HEUTZUTAGE ... das LOHNT SICH
Mehr Infos zu dem Thema gibt es auch in der Application Note "mltithrd.pdf" (YourLabVIEWDirmanualsmltithrd.pdf)
ich hab mir die Action Engine mal angesehen.
Das sieht sehr interessant aus. Nach dem zweiten mal hinsehen hab ich dann auch begriffen wie es funktioniert.
Ich werde das demnächst mal verweden und sehen wie ich mit dem Ansatz zurechtkomme.
Die Idee ist eigentlich genial!
Die "Action Engine" ist eigentlich nichts weiter als eine "Functional Global":
die Idee geht zurück zu LabVIEW 2. Da gab es noch keine globalen Variablen. Irgend ein findiger Programmierer hat damals entdeckt, dass man ein nicht initialisiertes Shift-Register dazu verwenden kann Daten zwischenzuspeichern.
Ich hab mal ein Demo zum Thema Functional Globals programmiert: klickste hier
