Messdaten in Protokoll speichern

Hallo Pferdchen,

Zitat:Theoretisch könnte ich die For-Schleifen mit dem Mittelwert dahinter auch weglassen, ich häng ja ein Gewicht dran und messe die Kraft, da sollte der Kraftwert bei einem Gewicht ja sowieso konstant sein, aber ich dachte mir, das ich das sicherheitshalber 100 Werte nehme und mittle, um eventuelle Fehler wie z.B. nen Luftstoß oder sowas abzuschwächen.

Um also Umwelteinflüsse zu filtern, dachtest du dir, nehme ich einfach 100 Messwerte und mittele die. Gar nicht mal verkehrt - nur die Lösung ging dann in die Binsen!
Du nimmst 100 MessWerte innerhalb einer (geschätzten) Mikrosekunde, also viel schneller, als es überhaupt zu Umwelteinflüssen kommen kann und unter Garantie auch viel zu schnell für den verwendeten Sensor und deine DAQ-HW. Schon mal darüber nachgedacht? Nicht, das wir dich nicht darauf hingewiesen hätten, z.B. in Beitrag #2, #6, #8 und #9...

Zitat:Das sagt mir leider garnichts, bin noch absoluter Labview Anfänger

Dagegen kann man was tun: Lesen!

(22.03.2012 14:38 )GerdW schrieb:  Hallo Pferdchen,

Beitrag#2, zweiter Stichpunkt ist weiterhin gültig: deine Mittelwert-Bildner sind Blödsinn.

Weiterhin:
- fast alle lokalen Variablen lassen sich durch Drahtverbindungen ersetzen, siehe Bild (nur zur Veranschaulichung, da kann noch mehr aufgeräumt werden)
- deine Datei-Formatier-Schleife ist Blödsinn, siehe Bild
- deine Sequenzstruktur ist größtenteils Blödsinn, da man alles mittels Dataflow regeln kann

Zum Mittelwert hab ich ja in meinem vorigen Beitrag schon was geschrieben.

- Zum Ersetzen der lokalen Variablen:
Ich weiß ja, das es guter Stil wäre, aber hab ich nicht die Race Conditions (was ja scheinbar das Problem bei den lokalen Variablen wäre) durch die Sequenzstruktur und die 'An/Aus-Schalter' zum Krafteinlesen umgangen?
- Mir war klar, das mein Datei-Schreibe Prozess nicht der schönste ist, aber er ist doch akzeptabel, oder? Ich werde es aber wohl zu deiner Version umschreiben, danke.
- Die Sequenzstruktur benutze ich halt, um Race Conditions durch die Variablen zu vermeiden, ich lasse mich gern belehren falls ich da was falsch verstehe.

Gruß,
UnbekanntesPferd

---

zuerst mal, ich hab deine letzte Nachricht noch nicht gelesen, als ich meine letzte verfasst hab

(23.03.2012 15:42 )GerdW schrieb:  Hallo Pferdchen,

Um also Umwelteinflüsse zu filtern, dachtest du dir, nehme ich einfach 100 Messwerte und mittele die. Gar nicht mal verkehrt - nur die Lösung ging dann in die Binsen!
Du nimmst 100 MessWerte innerhalb einer (geschätzten) Mikrosekunde, also viel schneller, als es überhaupt zu Umwelteinflüssen kommen kann und unter Garantie auch viel zu schnell für den verwendeten Sensor und deine DAQ-HW. Schon mal darüber nachgedacht? Nicht, das wir dich nicht darauf hingewiesen hätten, z.B. in Beitrag #2, #6, #8 und #9...

Ah, ok, ich wusste nicht, dass es nur eine Mikrosenkunde ist. Wenn ich also eine Wartezeit von ein paar Millisekunden pro Schleifendurchlauf nehmen würde, wärs in Ordnung?

Zitat:Dagegen kann man was tun: Lesen!

Werd ich wohl auch noch machen, ich hatte nur nicht vor mich schon tief in Labview einzuarbeiten, bevor ich mein erstes VI schreibe

Hallo Pferdchen,

Zitat:Ah, ok, ich wusste nicht, dass es nur eine Mikrosenkunde ist.

Ich weiß ja nicht, wie schnell dein PC ist, aber moderne Rechner schaffen es, pro Sekunde Gigabyte im RAM zu verschieben. Oder glaubst du etwa, dein Programm läuft immer so langsam wie im Highlight-Modus?

Zitat:Wenn ich also eine Wartezeit von ein paar Millisekunden pro Schleifendurchlauf nehmen würde, wärs in Ordnung?

In Ordnung würde ich es nicht nennen, eher quick&dirty. Aber quick&dirty scheint genau dein Stil zu sein: "Die Sequenzstruktur benutze ich halt, um Race Conditions durch die Variablen zu vermeiden" heißt übersetzt soviel wie: "Statt es richtig zu programmieren, packe ich halt immer mehr Strukturen in mein VI und mache es immer unübersichtlicher, es wird schon irgendwie funktionieren"...

Zitat:ich hatte nur nicht vor mich schon tief in Labview einzuarbeiten, bevor ich mein erstes VI schreibe

Jetzt bist du ja schon mittendrin beim Progrmmieren, also zählt diese Ausrede nicht mehr: "Ich wollte durchaus noch zur Fahrschule gehen, hatte aber keine Lust dazu, bevor ich mich in mein eigenes Auto reinsetze." Viel Spass noch...

Zitat:Ich weiß ja nicht, wie schnell dein PC ist, aber moderne Rechner schaffen es, pro Sekunde Gigabyte im RAM zu verschieben. Oder glaubst du etwa, dein Programm läuft immer so langsam wie im Highlight-Modus?

Dass es nicht so langsam ist, wie im Highlight Modus, ist mir schon klar, mir war nur nicht bewusst, dass es so schnell ist.

Zitat:und mache es immer unübersichtlicher

Ich sehe ja ein, dass es oft mit "unnötigen" Sequenzstrukturen unübersichtlich wird, aber bei diesem VI hier, finde ich als Einsteiger die Sequenzstruktur + lokale Variablen deutlich übersichtlicher als den Austausch der lokalen Variablen durch diverse Verbindungen.

Zitat:In Ordnung würde ich es nicht nennen, eher quick&dirty

Was wäre denn an dieser Stelle besser?

Zitat:"Ich wollte durchaus noch zur Fahrschule gehen, hatte aber keine Lust dazu, bevor ich mich in mein eigenes Auto reinsetze."

Wenn ich beim Programmieren Fehler mache, wird, im Gegensatz zum Straßenverkehr, aber niemand ums Leben kommen.

(24.03.2012 02:42 )UnbekanntesPferd schrieb:  Wenn ich beim Programmieren Fehler mache, wird, im Gegensatz zum Straßenverkehr, aber niemand ums Leben kommen.

Bis du einen Prüfstand mit z.B. einem Hydraulik-Zylinder mit Fmax >= 250 kN programmierst. Dann sagst du das auch nicht mehr so einfach.

Gruß, Jens

Ok, da hast du schon recht, ich sollte es ändern zu:
Wenn ich momentan beim Programmieren Fehler mache, wird, im Gegensatz zum Straßenverkehr, aber niemand ums Leben kommen.
(Ich bin HiWi an der Uni, momentan programmiere ich mit LaView eigentlich nur zur Übung und wenn ich am Lehrstuhl mal richtig programmiere, arbeiten wir eigentlich nur mit relativ kleinen Kunststoffproben, da treten keine soo großen Kräfte auf)

Anzeige

Hallo Pferdchen,

Zitat:Ich bin HiWi an der Uni, ... wenn ich am Lehrstuhl mal richtig programmiere, arbeiten wir eigentlich nur mit relativ kleinen Kunststoffproben, da treten keine soo großen Kräfte auf

Aus eigener Erfahrung weiß ich, dass an Unis die Arbeitssicherheitvorschriften-Einhaltung gern mal an die HiWis in Eigenverantwortung "delegiert" wird, aber wenn du deine Arbeitsbeschreibung schon selbst mit lauter Relativierungen durchsetzt, scheint hier Blauäugigkeit in Reinkultur vorzuliegen. Laut deiner Beschreibung gefährdest du mit Vorsatz auch noch andere Personen - das wird von keiner Haftpflichtversicherung gedeckt!

Da kann man nur "Viel Glück weiterhin" wünschen!

Tut mir leid, aber ich muss noch weiter blutgrätschen, aber du lieferst zu viele Steilvorlagen:

Zitat:wenn ich am ... mal richtig programmiere

Wie wir an deinen Versuchen gesehen haben, ist von "richtig" bisher nicht viel zu sehen. Und du hattest dich auch als sehr beratungsresistent gezeigt (es brauchte 5 konkrete Hinweise, bis du überhaupt eingesehen hast, etwas falsch programmiert zu haben) - alles keine guten Voraussetzungen, wenn es um das Leben (oder zumindest die Gesundheit) von Kollegen geht...

Zitat:Laut deiner Beschreibung gefährdest du mit Vorsatz auch noch andere Personen

Ich finde diese Unterstellung ziemlich unverschämt. Das VI das ich hier, wie du es sagst "quick and dirty", geschrieben habe, bewegt keine Maschine, im schlimmsten Fall wird ein Kraftsensor neu kalibriert/nicht neu kalibriert obwohl er in Ordnung/nicht mehr in Ordnung ist. Zusätzlich hab ich es 'nem wissenschaftlichen Mitarbeiter gezeigt, der hat drüber gesehn und es war in Ordnung.
Es ist das erste VI, das ich geschrieben hab und du unterstellst mir, ich würde bei VIs, die im Fehlerfall Menschen gefährden, genauso "quick and dirty" vorgehen.
Meine Aussagen von vorher, dass keine Menschen verletzt werden, hat sich halt auf VIs wie dieses bezogen.

Zitat:Wie wir an deinen Versuchen gesehen haben, ist von "richtig" bisher nicht viel zu sehen.

Wie gesagt, es ist mein erstes VI. War bei euch das erste VI direkt in Ordnung?

Zitat:Und du hattest dich auch als sehr beratungsresistent gezeigt (es brauchte 5 konkrete Hinweise, bis du überhaupt eingesehen hast, etwas falsch programmiert zu haben)

Man kann es durchaus beratungsresistent nennen. Ich hab halt einfach nicht verstanden warum das, was ihr mir als Fehler gennant habt, falsch ist.
Wenn ich es richtig verstanden hab, war doch z.B. das 100 Werte ohne Timing auslesen und Mittelwert bilden nicht völlig falsch, sondern nur unnötig.
Gleiches gilt doch für lokale Variablen+Sequenzstruktur statt lange Verbindungen. Verbindungen wären schöner, aber meine Lösung ist doch auch nutzbar.

Du scheinst das Prinzip des Datenflusses nicht richtig bzw nur ungenügend zu verstehen, etwas worauf die ganze Programmierung mit LabVIEW basiert. Ich würde dir persönlich dringenst empfehlen dich nochmal genau damit zu befassen.

Gerd war vielleicht etwas strenger, als ich es ausgedrückt hätte. Prinzipiell bin ich jedoch seiner Meinung, falls du nichts mehr an deinem VI ändern willst so ist und bleibt es eine Quick'n'dirty-Lösung mit hoher Fehleranfälligkeit.

Gerade WENN es sich um ein erstes VI handelt sollte man anstreben es möglichst gut zu machen um möglichst viel daraus zu lernen. Das dies nicht beim ersten Mal klappen wird ist eine Tatsache und stellt auch kein Problem im Forum selbst dar (wie ich aus eigener Erfahrung weiss).

Problematisch ist es, wenn man um Hilfe bittet und anschliessend jeden gut gemeinten Rat in den Wind schlägt.

Falls du dich tatsächlich verbessern willst, so versuch doch die vorgeschlagenen Änderungen so umzusetzen wie du sie verstehst. Damit zeigst du guten Willen und und lernbereitschaft, welche sehr warscheindlich vorhanden sind. Nur durch diese Posts auf persönlicher Ebene wird es für den Betrachter schwer diese zu erkennen.

Fehler machen ist kein Problem, es jedoch nicht zu versuchen schon

Gruss Marc