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.09.2010, 15:08 (Dieser Beitrag wurde zuletzt bearbeitet: 30.09.2010 15:09 von Bakunin.)
Ich will mir so eine art DIY ADC-Karte bauen...
Ich habe einen Atmega8 (µC) dazu gebracht den internen 10bit-Analog-Digital-Wandler zu nutzen und die aufgenommenen werte per RS232 an den pc zu senden. Dies geschieht andauernd, ohne grosse Aufforderung. (konfigutation: 38400 8n1) (ich habe also das seltene glück dass ich die ausgabe in konfiguration und form beliebig verändern kann, vorgabe ist nur dass ich die baudrate von 38400 behalten will)
Das funktioniert soweit auch ganz gut, mein terminalprogramm sagt genau dass was es soll, nämlich folgendes:
215<r>209<r>226<r>281<r>345<r> usw... (die dezimalzahlen zeigen hier ein rauschen, <r> habe ich zur trennung der zahlen mitsenden lassen)
manchmal kommt allerdings auch mist raus, in gestalt von lauter komischen sonderzeichen, ein framing error halt.
diesen kann ich im terminalprogramm durch ein ziehen des reset an meinem atmega aufheben, danach wird gesendet was gesendet werden soll...
mein problem ist nun das dies bei labview nicht geht- mein Visa Read vi in meinem get10bitfromAtmega.vi sagt: VISA: (Hex 0xBFFF006B) A framing error occurred during transfer.
...und dann ist tote hose. ab und zu bekomme ich auch ein paar werte ausgegeben, dann hängt sich das ganze aber in der while-schleife auf weil angeblich keine "bytes at port" sind.
ich beisse mir an der ganzen sache langsam zie zähne aus und währe für jede hilfe dankbar...
verwendete labview-version ist die 8.6, im anhang auch .jpg
get10bitfromAtmega.vi ist das subvi...
' schrieb:manchmal kommt allerdings auch mist raus, in gestalt von lauter komischen sonderzeichen, ein framing error halt.
Wenn einmal FramingError da war, stimmen dann die Daten auf ewig nicht mehr (bis zum Reset halt)? Dann hast du aber ein Problem mit deiner Atmega-Software/Hardware. Das solltest du zuerst lösen.
Zitat:diesen kann ich im terminalprogramm durch ein ziehen des reset an meinem atmega aufheben, danach wird gesendet was gesendet werden soll...
So solltes es eben nicht sein.
Zitat:mein problem ist nun das dies bei labview nicht geht- mein Visa Read vi in meinem get10bitfromAtmega.vi sagt: VISA: (Hex 0xBFFF006B) A framing error occurred during transfer.
Erstens:
Wenn das Problem an deinem Atmega (Software oder Hardware) liegt, wirst du das mit LV nicht lösen können.
Zweitens:
FramigError (etc.) sind "normale Fehler", die ein Protokoll abkönnen muss. Im einfachsten Fall einfach ignorieren.
Drittens:
In die While-Schleife mit dem "BytesAtPort" sollte eine Wartezeit rein. Mach da mal den Metronom mit 10ms rein. (While-)Schleifen dürfen nicht unendlich schnell laufen ...
Zitat:...und dann ist tote hose. ab und zu bekomme ich auch ein paar werte ausgegeben, dann hängt sich das ganze aber in der while-schleife auf weil angeblich keine "bytes at port" sind.
Das würde mich nicht wundern, wenn der Atmega ....
Noch ein Tipp:
Stell beim Atmega zwei Stoppbits ein - und am PC nur eines. Hast du die Möglichkeit, die RS232-Pegel nachzumessen?
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Erstmal danke an IchSelbst fur die schnelle Antwort!
@Jens: werd mich bemühen.
Den Tip mit dem zweiten Stopp Bit habe ich umgesezt, das macht das Ganze sicherlich etwas Stabiler.
Ich glaube ich habe mich etwas blöde ausgedrückt, der Framing Error im Terminalprogramm tritt nicht zwischen durch, irgendwann in der laufenden Übertragung auf, sondern wenn, dann dierekt wenn ich auf Connect klicke.
Zitat:Zweitens:
FramigError (etc.) sind "normale Fehler", die ein Protokoll abkönnen muss. Im einfachsten Fall einfach ignorieren.
ok, wie bringe ich LabView dazu dass es mich nichtmehr mit Prompts bombardiert?
Die Schleife "BytesAtPort" macht mir momentan am meisten Kopfzerbrechen- lasse ich das Vi (get10bitfromatmega.vi) dauerhaft durchlaufen kommt irgendwann ein Punkt, an dem BytesAtPort=0 ist, und auch bleibt, sodass ich nichtmehr aus der Schleife rauskomme- hatt Jemand da eine Lösung parat? Muss man irgendwie VISA dazu treten das Register neu zu füllen?
Die 10ms warten in der Schleife habe ich jezt temporär eingefügt- ich bin aber eigentlich auf Schnelligkeit aus bei der ganzen Geschichte(daher auch die hohe Baudrate)
30.09.2010, 18:29 (Dieser Beitrag wurde zuletzt bearbeitet: 30.09.2010 18:29 von Lucki.)
' schrieb:Ich glaube ich habe mich etwas blöde ausgedrückt, der Framing Error im Terminalprogramm tritt nicht zwischen durch, irgendwann in der laufenden Übertragung auf, sondern wenn, dann dierekt wenn ich auf Connect klicke.
ok, wie bringe ich LabView dazu dass es mich nichtmehr mit Prompts bombardiert?
Dann ist das die normalste Sache der Welt: Wenn Du beginnst, in den Datenstream hineinzuhören, dann kannst Du weder erwarten, den Anfang eines Datensatzes zu erwischen, noch den Anfang eines Bytes. Letzteres gibt den Rahmen-Synchronisationsfehler (kann sich über mehrere Byte hinstrecken), ersteres einen falschen Datenwert. Das funktioniert nur, wenn Du erst Labview einschaltest, und dann erst den µC.
Oder diese Lösung: Rahmen-Synchronisationsfehler abfangen, bis die Synschronisation erreicht ist, dann ersten Datenwert löschen, da der zugehörige Datensatz wahrscheinlich unvollständig ist.
Zu Prompts kommt es nur dann, wenn am Fehlerausgang eines VIs kein Draht angeschlossen ist. Labview geht dann davon aus, daß der Fehler nicht behandelt wird und zieht die Notbremse mit einem Prompt.
An deinem VI ist viel zu viel Firlefanz, die Benutzung von TermChar ist hier das einzig Wahre, dann wird alles total einfach. Habe der Einfachheit mal alle Lesefehler "behandelt" (Lesen wird wiederholt). Außerdem wird der erst Messwert nicht, wie gerade vorgeschlagen, verworfen.
@Lucky: Vielen Dank! Ich glaube ich habe mich da völlig in die Sache verstiegen- deine Lösung ist natürlich wesentlich eleganter- hatte am Anfang meines Irrwegs nen ähnlichen Ansatz, das ist dann aber recht schnell ausgeufert
Ich denke ich werde deinem Tip gemäss einfach das Programm auf dem Atmega einfach so umstricken, dass ich erst auf Befehl hin (VISA Write String) das dauerhafte Senden an den PC starten lasse.
Ich habe da ein ähnliches Problem mit dem Frame Error (-1073807253):
Während der Kommunikation tritt er gerne mal zwischendurch auf. Ich hatte gehofft, dass ich den Error einfach dadruch beheben kann, dass ich die Schnittstelle im Fehlerfall beende und neu öffne - geht aber nicht, der Fehler bleibt bestehen. Auch wenn ich das Gerät abschalte, bevor ich den Reset versuche.
Hat jemand eine Idee, wie das sein kann und wie ich das beheben kann?
(09.01.2012 14:49 )Soean schrieb: Hat jemand eine Idee, wie das sein kann und wie ich das beheben kann?
Lösung wurde schon genannt, einfach mal den Thread lesen. Das ist kein Fehler in der Software, sondern ein Fehler bei der Übertragung, das kann vorkommen und deshalb mus nicht neu konfiguriert werden. Den Fehler abfangen - hast Du ja schon getan, sonst könntest Du nicht neu konfigurieren. Bei kontinuierlicher Datenerfassung den Datensatz vergessen, bei Master-Slave Übertragung den Datesnsatz neu anfordern. Oder irgendetwas anderes, aber nicht alles neu konfigurieren. Es geht um Schadensminimierung, wenn ein einzelnes Byte fehlerhaft ist, mehr nicht.
Ist jemand dagegen daß Dein anderer Thread gelöscht wird?
Danke für die Antwort!
Der andere Thread kann von mir aus gerne gelöscht werden. Hier noch mal sein Inhalt, der ausführlicheren Fehlerbeschreibung wegen:
Ich habe bei der Kommunikation über RS232 mittels VISA folgendes Problem:
Die Schnittstelle wirft nach einiger Zeit (nicht reproduzierbar, Zeitpunkt nicht vorhersehbar) folgenden Fehlercode aus: -1073807253, und reagiert danach nicht mehr, der Fehler bleibt bestehen.
Da ich die Ursache dafür bisher nicht finden konnte, dachte ich, ich fange den Fehler ab, indem ich die Schnittstelle bei Auftreten des Fehlers beende (VISA Close), 500 ms warte, und wieder neu öffne (ich weiß, auch irgendwie Pfusch...). Der Fehler bleibt jedoch, unabhänig davon, ob das Gerät mit dem kommuniziert wird zum Zeitpunkt dieses "Resets" eingeschaltet oder angeschlossen ist, oder nicht. Erst, nachdem die Applikation komplett beendet und neu gestartet wurde, lässt sich wieder über die Schnittstelle kommunizieren.
Zum Vorschlag von Lucki:
Warum bleibt der Fehler bestehen? Ich würde den Datensatz ja gerne erneut anfordern - geht aber nicht. Die Schnittstelle lässt sich erst wieder verwenden, wenn die Applikation/Entwicklungsumgebung komplett gestoppt wurde, und das Programm neu gestartet.
Ich stehe hier wirklich ein wenig auf dem Schlauch...der Fehler tritt immernoch häufiger mal auf, und ich habe weder die Ursache noch eine Möglichkeit, wie ich die Schnittstelle wieder in Gang kriege, ohne das komplette Programm zu beenden, gefunden.
Hat wirklich niemand eine Idee?
/
VISA Read: Frame Error die 1000te
