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!
du machst da ein paar Standard-Anfängerfehler. Du schreibst beispielsweise auf den Port ein Komando, wartest 10ms und erwartest dann adhoc eine Antwort. Was machste denn, wenn von der z.B. 10Byte langen Antwort erst 7 Byte im SS-Puffer angekommen sind. Dann schickst du irgendwann (nach der Summe deiner Wartezeiten) ein neues Komando und liest 10ms später den Rest der 1. Antwort und den erten Teil der nächsten.
Hallo Marko,
danke für deine Antwort. Ich bin auch Anfänger ;-)
Aber zum Problem: Bis jetzt klappt es eigentlich ganz gut und ich empfange immer alle (19) Bytes. Wenn mal ein Rest bleibt bzw. nur der Anfang empfangen wurde, wollte ich diese eigentlich mit der Case-Struktur verwerfen (da es diese Werte dann nicht gibt!). Ich lese ja alle 300ms und habe damit ausreichend Zeit beim überfahren 2-3 mal zu lesen. Da ist dann immer was ordentliches dabei ;-)
Aber wie kann ich es denn besser machen? Dein Tip?!
(13.10.2014 07:37 )jg schrieb: Noch ein Tipp:
"Bytes at Port" bei gleichzeitiger Verwendung des "Termination Char" in der VISA-Kommunikation ist in der Regel überflüssig und kontraproduktiv.
Gruß, 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!
wenn du irgendwelche Stuss-Daten liest, dann gehst du in den Standardcase und der entspricht dem Case 0000.
Feste Wartezeiten sind immer schlecht und taugen i.d.R. nur für genau diesen Anwendungsfall. Besser ist es, ein Abschlusszeichen zu definieren und nur ein KO-Timeout zu kreieren, damit sich das ganze nicht festbeißen kann. Wenn du kein Abschlusszeichen definieren kannst, weil es keins gibt, dann die zu erwartende Byteanzahl mit einem hinreichend großen TO lesen.
