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!
Erst mal: Dein Stop-Button steht auf "Switch when pressed". Könnte beim nächsten Aufruf bedeuten, dass der Button immer noch auf True steht.
Dann: Wieso unter den VI-Properties -> Execution -> Run when opened gewählt?
Und jetzt zur weiteren Fehleranalyse: Die fehlt mir schwer (bzw. ist unmöglich), da ich nicht weiss, was du in deinem "SpannungTask0" definiert hast. Könntest du da mal normalen DAQmx-Code erzeugen? Am besten über RechteMaustaste auf Task->Generate Code->Convert To Express VI und danach das Express VI in normalen Code wandeln (rechte Maustaste->NI-DAQmx erzeugen).
Dann kann man (auch ohne deine Hardware) schon mal etwas besser Fehleranalyse betreiben.
So, und jetzt rate ich doch noch einmal: Ich gehe mal davon aus, dass die Erhöhung deines Eingangssignals, dass du erfasst, recht langsam ist. Deshalb langt es wohl, immer per Software-Timing einen Messwert einzulesen. Ich hab dir mal was gebastelt:
ich weiß das es groß is. und ich wußte auch das euch das mißfällt. aber es ist mein erstes LV-programm. (und vielleicht auch das letzte)
klar würde ich vieles anderes machen wenn ich am anfang soviel gewußt hätt wie ich jetzt weiß. aller anfang is eben schwer!
im endeffekt is doch nur eins wichtig: einer muß durchblicken. und das bin ich! ich blick durch!
und die eigentlich version is 1.1 die einwandfrei läuft und ihren job erledigt. version 1.2 oder wenn das mit dem auto-kalli für top-hihi klappt dann v1.3 ist schon die kür!
ach und nochwas. ich hab ne krakelige schrift, mein zimmer ist immer unordentlich, also werd ich auch kein primäres interesse an geraden verbindungslinien haben!
das blockdiagramm schaut sich niemand nach mir mehr an. das frontpanel muß passen und es muß zuverlässig seinen job machen. und das tut es soweit!
so, nun wieder zum fachlichen:
schön zu erfahren das es ein element "im gültigen bereich" gibt, das hatt ich mir immer selber gebastelt. wer weiß was es noch alles gibt, von dem ich keine ahnung hab
Also nach ein paar kleinen Anpassungen (dev2, und anschlußkoniguration pseudodifferentiell) läufts prima! mein problem was ich hatte tritt hier nicht auf!
zudem ist die "taktsteuerung" der schleife von 100ms ne gute idee. da werd ich mal sehen ob ich das vielleicht noch höher drehen werde. denn das signal muß ja mind.diese zeit im geforderten bereich liegen oder? somit kann man doch sehr schnelles ansteigen was diesen bereich nur kurz kreuzt als abbruchbedingung ausschließen oder?
' schrieb:im endeffekt is doch nur eins wichtig: einer muß durchblicken. und das bin ich! ich blick durch!
Wieso stellst du dann hier Fragen?
' schrieb:also werd ich auch kein primäres interesse an geraden verbindungslinien haben!
Aber du hast offenbar ein Interesse daran, dass andere dir helfen! Findest du nicht, dass du von deiner Seite aus alles tun solltest, um es potentiellen Helfern so einfach wie möglich zu machen? Wieso sollte einer Interesse daran zu haben, dir zu helfen, wenn er erst nen riesigen Aufwand betreiben muss, durch deinen Code durchzusteigen? Hier arbeiten alle "ehrenamtlich" mit...oft während der Arbeitszeit...da bleibt für Codepflege anderer Leute keine Zeit (und Lust). Wenn du sauber programmieren würdest...vielleicht würdest du dann tatsächlich durchblicken!
' schrieb:das blockdiagramm schaut sich niemand nach mir mehr an. das frontpanel muß passen
Vielleicht ein wenig zu kurzfristig gedacht...ich kenn zwar deinen speziellen Anwendungsfall nicht...aber ich bin sicher, wenn du in 3-4 Monaten nochmal auf dein chaotisches BD guckst, siehst du gaaaaaaanz alt aus.
Das FP ist absolute Geschmackssache...aber die riesige LED ist einfach nicht schön...hüstel...
Gute Besserung!
Achim
"Is there some mightier sage, of whom we have yet to learn?"
"Opportunity is missed by most people because it is dressed in overalls and looks like work." (Thomas Edison)
Developer Suite Core -> LabVIEW 2015 Prof.
2006
EN
71083
Deutschland
SubVi-Probleme
Amen!
' schrieb:Wieso stellst du dann hier Fragen?
Aber du hast offenbar ein Interesse daran, dass andere dir helfen! Findest du nicht, dass du von deiner Seite aus alles tun solltest, um es potentiellen Helfern so einfach wie möglich zu machen? Wieso sollte einer Interesse daran zu haben, dir zu helfen, wenn er erst nen riesigen Aufwand betreiben muss, durch deinen Code durchzusteigen? Hier arbeiten alle "ehrenamtlich" mit...oft während der Arbeitszeit...da bleibt für Codepflege anderer Leute keine Zeit (und Lust). Wenn du sauber programmieren würdest...vielleicht würdest du dann tatsächlich durchblicken!
Vielleicht ein wenig zu kurzfristig gedacht...ich kenn zwar deinen speziellen Anwendungsfall nicht...aber ich bin sicher, wenn du in 3-4 Monaten nochmal auf dein chaotisches BD guckst, siehst du gaaaaaaanz alt aus.
Das FP ist absolute Geschmackssache...aber die riesige LED ist einfach nicht schön...hüstel...
Gute Besserung!
Achim
-------------------------------------------------------------------------- Bitte stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort !!
--------------------------------------------------------------------------
' schrieb:Also nach ein paar kleinen Anpassungen (dev2, und anschlußkoniguration pseudodifferentiell) läufts prima!
Das kommt von diesen #!@grrrr-Tasks, ich kann ja, wie schon mehrfach gesagt, nicht wissen, was da bei dir schon als Code drin steht.
' schrieb:mein problem was ich hatte tritt hier nicht auf!
Schön für dich. Wobei mir auf Grund der nicht vollständig möglichen Analyse nicht klar ist, welche Änderung von mir dir jetzt geholfen hat.
' schrieb:zudem ist die "taktsteuerung" der schleife von 100ms ne gute idee. da werd ich mal sehen ob ich das vielleicht noch höher drehen werde. denn das signal muß ja mind.diese zeit im geforderten bereich liegen oder? somit kann man doch sehr schnelles ansteigen was diesen bereich nur kurz kreuzt als abbruchbedingung ausschließen oder?
Vorsicht, mein Bsp. liest nur 1 Messwert pro Schleifendurchlauf ein, und überprüft dann, ob dieser eine Wert innerhalb der Grenzen liegt! Natürlich kannst du die Schleife auch noch etwas schneller machen, aber immer daran denken: das ist jetzt ein reiner Software-Takt, der nicht garantiert mit dieser Geschwindigkeit laufen muss. Wenn Windows zu viel zu tun hat, kann der Takt auch langsamer sein.
Und zu den anderen Punkten zwecks BD, da kann ich mich nur meinen Vorschreibern anschließen.
MfG, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
' schrieb:im endeffekt is doch nur eins wichtig: einer muß durchblicken. und das bin ich! ich blick durch!
Eine sehr mutige Aussprache und ich weiss aus eigener Erfahrung, dass selbst wenn man viel sauberer programmiert nach ein paar Monaten manchmal das grosse Kopfkratzen beginnt.
Zitat:ach und nochwas. ich hab ne krakelige schrift, mein zimmer ist immer unordentlich, also werd ich auch kein primäres interesse an geraden verbindungslinien haben!
das blockdiagramm schaut sich niemand nach mir mehr an. das frontpanel muß passen und es muß zuverlässig seinen job machen. und das tut es soweit!
Dein Programm wäre nicht das erste, das über viele Jahre in regelmässigen Upgrades, Anpassungen und Erweiterungen endet und die Person die dann das pflegen darf wird mehr oder weniger laut über Dich ausrufen und Dich am liebsten zum Mond schicken.
Persönlich hatte ich schon öfters das "Vergnügen", solche Applikationen zu debuggen und sauber zum Laufen zu bringen, nachdem sie einige Jahre vor sich hingekränkelt haben.
Zwar halte ich mein Fluchen dabei im stillen Kämmerlein, aber manchmal ist es einfach nicht ganz zu vermeiden dem Kunden deutlich zu machen dass der grössere Teil der Upgradekosten durch das Gebastel des ursprünglichen Programmierers nötig ist.
' schrieb:Krass!! Wieviel m<sup>2</sup> hat denn das VI??
Ein Tip meinerseits (und wohl der meisten hier im Forum):
Ein VI sollte NIE größer als eine Bildschirmgröße sein. Den Rest einfach in SubVIs packen. Und eine Statemachine würde (nach dem ersten Überfliegen) bei Dir auch echt was bringen.
Zu Deinem eigentlichen Problem kann ich Dir gerade nicht weiterhelfen, weil ich relativ wenig Zeit habe.... Heute Abend kann ich aber evtl. mal drüberschauen.
Gruß Markus
mh, diese Aussage ist doch auch grenzwertig hehe.
Bidlschirmgröße != Bildschirmgröße
....man nehme ein 19" TFT Setup und dann im Vergleich z.b. meinen Kollegen mit 2x22".....is göttlich für labivew chaos welches trotzdem noch überblickbar ist/wirkt....
kurzum: der kern is richtig, aber machs nicht an bildschirmgrößenm fest
Developer Suite Core -> LabVIEW 2015 Prof.
2006
EN
71083
Deutschland
SubVi-Probleme
Kannst es Dir ja auch an die Wand projezieren und dann mit einer Hebebühne Deine VIs suchen.......
Was ich meinte war ja wohl klar..... Klein und kompakt. Man soll halt nicht scrollen müssen......... und das trifft bei einer Bildschirmgröße zu. Was da der einzelne für einen Bildschirm hat ist da prinzipiell egal.
Gruß Markus
' schrieb:mh, diese Aussage ist doch auch grenzwertig hehe.
Bidlschirmgröße != Bildschirmgröße
....man nehme ein 19" TFT Setup und dann im Vergleich z.b. meinen Kollegen mit 2x22".....is göttlich für labivew chaos welches trotzdem noch überblickbar ist/wirkt....
kurzum: der kern is richtig, aber machs nicht an bildschirmgrößenm fest
gruss
fidel
-------------------------------------------------------------------------- Bitte stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort !!
--------------------------------------------------------------------------
wer weiß was es noch alles gibt, von dem ich keine ahnung hab
