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!
30.12.2009, 21:41 (Dieser Beitrag wurde zuletzt bearbeitet: 30.12.2009 21:49 von FuxDancer.)
Wow. Du bist echt ein Phänomen, wieder mal bin ich mehr als sprachlos, die Strings werden wirklich den Boolschen Werten zugewiesen.
Ein paar Fragen hätte ich noch:
Am Ende konvertierst du das ganze mittels Typecast auf String. Wenn ich das jetz an mein VISA-Write anhänge, kommt da schon der komplette String mit den 100 oder weniger Nullen und Einsen heraus oder muss ich da noch etwas programmieren?
Ich möchte noch eine Simulation von Fehlern einbauen, denn der Code, den ich hier verwende, kann 1-bit-Fehler korrigieren, 2-bit-Fehler erkennen und bei 3-bit-Fehlern funktioniert das ganze nicht mehr.
Dass möchte ich so realisieren, dass ich bei dem String vor dem Senden einfach, wenn ich einen Taster oder so betätige, 1 bit, 2bit oder 3bit invertiere. Dann sendet nämlich mein Mikrocontrollerprogramm Meldungen an das Programm zurück. Bei 0 Fehler kommt "a", bei 1 Fehler "b" und bei zwei "c". Dann wird halt bei 2 Fehlern eine neue Übertragung angefordert und bei den anderen passiert nichts mehr.
Hier kannst du mal mein jetziges VI sehen, wobei das mit "Rückmeldung 2" sowieso von mir ein Schwachsinn ist, sry.
' schrieb:Am Ende konvertierst du das ganze mittels Typecast auf String. Wenn ich das jetz an mein VISA-Write anhänge, kommt da schon der komplette String mit den 100 oder weniger Nullen und Einsen heraus oder muss ich da noch etwas programmieren?
Durch die Konvertierung entsteht ein Datenstream mit Basistyp Char. Und Char ist eben das, was über die Serielle Schnittstelle übertragen wird. Deine Gegenseite, also der µC (?), empfängt jetzt also lauter Chars. Diese Char sind aber 8Bit breit. Hast du denn schon einen Algorithmus im µC, der aus den 13 8Bit-breiten Chars 10 Stück 10Bit-breite Daten macht?
Ich glaube es wäre besser, jedes der 10 Zeichen zu je 10 Bit als zwei Chars, als mit 16Bit, zu übertragen. Das ist zwar mehr Traffic auf der Leitung, aber einfacher in der Software sowohl beim Codieren wie auch bei Decodieren.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Ich möchte noch eine Simulation von Fehlern einbauen, denn der Code, den ich hier verwende, kann 1-bit-Fehler korrigieren, 2-bit-Fehler erkennen und bei 3-bit-Fehlern funktioniert das ganze nicht mehr.
Dass möchte ich so realisieren, dass ich bei dem String vor dem Senden einfach, wenn ich einen Taster oder so betätige, 1 bit, 2bit oder 3bit invertiere.
Eigentlich ganz einfach:
Ersetze (Teilarray ersetzen) einfach die HammingCodes im Array ArrOfBits durch einen beliebigen, aber falschen Wert.
Außerdem: Alleine die Mustertabelle links zu berichtigen nützt natürlich nichts. Du musst auch die Werte in Array ArrOfChar anpassen. Und "Als Standardwert setzen" nicht vergessen.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
30.12.2009, 22:06 (Dieser Beitrag wurde zuletzt bearbeitet: 30.12.2009 22:07 von FuxDancer.)
' schrieb:Achso, ich verstehe, was du meinst. Nur wie programmiert man das dann in LabVIEW. Du hast das doch bestimmt schon einmal gemacht, nicht?
Nein, gemacht hab ich's noch nicht. Erst jetzt für dich.
Aber: Willst du's nicht erst selbst mal probieren?
Einfach das Array, das im Case "0.." erstellt wird, auf U16 umstellen. Also am Eingang der For-Schleife das Schieberegister, das bisher mit einem Boolschen Array initialisiert wurde, jetzt mit einem U16-Array initialisieren. Und dann ganz einfach die Werte, die beim Indizieren des Array ArrOfBits entstehen, als Array aufaddieren. Den Ausgang der FOR-Schleife einfach noch in einen String konvertieren und zur Kontrolle auf ein String-Anzeigeelement geben, das auf "Hex-Darstellung" steht.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Eigentlich ganz einfach:
Ersetze (Teilarray ersetzen) einfach die HammingCodes im Array ArrOfBits durch einen beliebigen, aber falschen Wert.
Außerdem: Alleine die Mustertabelle links zu berichtigen nützt natürlich nichts. Du musst auch die Werte in Array ArrOfChar anpassen. Und "Als Standardwert setzen" nicht vergessen.
Ja klar, alles brauchst du auch nicht machen, machst mir meistens e alles, wenn ich etwas nicht weiß, aber LabVIEW ist halt von mir mehr als nur eine Schwäche. :/
Ich werd's probiern, wenn ich fertig bin, dann sende ich dir es.
Anzeige
31.12.2009, 10:37 (Dieser Beitrag wurde zuletzt bearbeitet: 31.12.2009 10:39 von FuxDancer.)
Tut mir leid, aber ich bin leider sogar damit überfordert, ich schaffe es noch das Schieberegister mit einem U16-Array zu initialisieren. Das Problem, was ich habe, ist, dass ich nicht weiß, was ich dem "Teilarray" in der Case-Struktur "0.." machen soll. Muss ich hier auch den Datentyp ändern oder eine Konvertierung einfügen?
Und was ich dann mit den Array-Anzeigeelementen "ArrOfBool: x mal 10" und "ArrOfBool: x mal 10" usw.
Oder muss ich das ganze Programmierte zwischen rechten Schieberegister der For-Schleife und der String-Konvertierung weglöschen und direkt auf die String-Hex-Konvertierung fahren, welche dann auf VISA fahrt?
' schrieb:Tut mir leid, aber ich bin leider sogar damit überfordert, ich schaffe es noch das Schieberegister mit einem U16-Array zu initialisieren.
Gehe wie folgt vor:
Ändere zuerst den Typ des "ArrOfBits" (das sind die HammingCodes) in U16. Der ist z.Z. I32. Das kannst du aber, oder? Kontextmenü eines beliebigen Array-Elementes öffnen. Ganz unten Eigenschaften wählen. Dann Datentyp U16 auswählen. Diese Änderung hat keine sichtbare Auswirkung auf das Programm. Es wird immernoch richtig funktionieren.
Danach ersetzt du das leere Array of Boolean, das das Schieberegister initialisiert, durch ein leeres Array of U16: Einfach aus der Arraypalette eine Konstante auf das BD legen und eine Konstante Zahl des Typs U16 hineinlegen. Leer ist ein Array dann, wenn es ausgegraut erscheint (genau: wenn der erste Index ausgegraut erscheint). Nach dem Ersetzen des boolschen durch das U16-Array werden Fehler auftauchen. Sieht zwar blöd aus, ist aber so.
LabVIEW ist nämlich so schlau, jetzt alles von Boolean an U16 anzupassen (das ist so, weil in LV alles polymorph ist) - ohne dass jemand was merkt. Dumm nur, dass eben diese - scheinbaren - Fehler entstehen.
Jetzt machst du einfach alle Fehler einfach weg - indem du alles, was rechts außerhalb der Schleife liegt, radikal löscht. Alles löschen! Das ist aber nur die Hälte der Fehler. Im Case "0.." löscht du auch alles raus. Das ganze Umgewandel in Boolean. - Alles, außer das Element Array erstellen.
Und jetzt muss alles richtig sein (wenn ich nichts vergessen habe). Kein Fehler, auch kein roter Konvertierungspunkt!
Jetzt kannst du am Ausgang des Schieberegisters eine Konvertierung nach String machen und ein String-Anzeigeelement anschließen. Stelle das Anzeigeformat auf Hex ein - und du siehst deine 10Bit in Hexdarstellung.
Zitat:Das Problem, was ich habe, ist, dass ich nicht weiß, was ich dem "Teilarray" in der Case-Struktur "0.." machen soll. Muss ich hier auch den Datentyp ändern oder eine Konvertierung einfügen?
Mit diesem Element machst du gar nichts.
Alleine durch das Ändern des Datentyps im Schieberegister - Polymorphie ! - passt sich alles automatisch an.
Zitat:Und was ich dann mit den Array-Anzeigeelementen "ArrOfBool: x mal 10" und "ArrOfBool: x mal 10" usw.
Zitat:Oder muss ich das ganze Programmierte zwischen rechten Schieberegister der For-Schleife und der String-Konvertierung weglöschen und direkt auf die String-Hex-Konvertierung fahren, welche dann auf VISA fahrt?
Genau.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
So ich habe einmal probiert, dass ich das Ganze ein wenig weiter programmiere, also schon mit Fehlersimulation.
Nur, irgendwie, dass mit meiner Stringkonvertierung, das funktioniert noch nicht, das mit der Fehlersimulation, das habe ich noch nicht ausprobiert.
Schaut euch das ganze bitte einmal an.
Hallo FuxDancer,
zur Klarstellung: Meiner Empfehlung nach einer mathematisch/logischen Entwicklung der Konvertierungsobjekte steht
' schrieb:Also doch eine Tabelle verwenden.
in keinem Wiederspruch. Denn bei der automatisierten Erstellung (Auffüllung) der Codetabelle (deren Verwendung zu mindest bei etwas anspruchsvollerem Konvertierungsmechanismens immer ein Zeitvorteil zu bescheinigen ist) würde
' schrieb:...Im Übrigen: In deiner Tabelle ist das O und das F doppelt.
im Normalfall nicht vorkommen.
Das Konvertierungsverfahren zur Laufzeit ist davon absolut unabhängig zu sehen.
weiterhin viel Erfolg bei der Umsetzung
1Postingempfehlungen, 2Motivation Fragen und Anpassungswünsche per PM werden, gegen Rechnungsstellung gerne beantwortet und realisiert ....wenn's dann doch kostenlos sein soll... bitte hier im LVF unter Berücksichtigung der voranstehenden Links posten.
