Ansteuerung ThermostatPlus / Eppendorf

' schrieb:Und versuche anhand der Doku zu verstehen, warum das Demoprogram diese 04 24 20 ... sendet, was diese zu bedeuten haben.

Ich hab das mal gemacht.

Zum Endgerät gesendet wird (in Hex) 04 24 20 30 30 31 05. Das bedeutet:
04 und 05 sind quasi Blockmarkierungen (warum erst 04 und nicht 05 ist mir allerdings schleierhaft). 04 und 05 muss immer so sein.
24 und 20 sind Typ und Subadress und müssen auch immer so sein.
30 30 31 ist das Kommando 1 "Get_Version". Das Kommando muss als immer als Zahl mit vorlaufenden Nullen übergeben werden. Also z.B. SET_NOM_TEMP3 = 30 31 33 = "013".
Hingesendet wird also immer (so vermute ich mal): 04 24 20 x x x 05. Wobei jedes x aus 30 .. 39 sein kann.

Vom Endgerät kommt die Antwort: 02 30 30 31 3D 32 2E 30 33 03 10
02 und 03 sind Blockmarkierungen. Wie das mit der 10 ist, weiss ich nicht mehr genau.
30 30 31 3D ist "001=" und liefert den Wert 32 2E 30 33, also "2.03".

Das Endgerät wurde also nach der Version gefragt und hat mit 2.03 geantwortet.

Die Sendepakete sehen also wohl so aus: 04 24 20 xx xx xx 05 für Lesen (Get_...) von Parametern und 04 24 20 xx xx xx 3D yy yy yy yy 05. Wobei yy aus 30..39 (Ziffern), 2E (Dezimalpunkt) oder ?? (Minuszeichen) sein kann. Die Empfangspakete sehen analog aus zum oberen Beispiel.

Was ich hier noch laut Beschreibung vermisse ist ACK bzw. NAK


Versteht sich von selbst: Ohne Gewähr.

Anzeige

wow,feinfein....verstehe! Jetzt gibt das auch alles sinn,das werd ich dann morgen gleich mal versuchen!

Aber schon mal ein rießen dankeschön an euch..primaprima *freu*


Schönen abend!

' schrieb:Ich hab das mal gemacht.

Ja das hat mich auch gereizt, ist doch fast wie ein Sudoku lösen oder so.

' schrieb:Was ich hier noch laut Beschreibung vermisse ist ACK bzw. NAK

"normalerweise" ist
ACK = 6 ; positive Bestätigung
NAK = 21 ; negative Bestätigung

Gruss
Roland

' schrieb:OK. Kann die DLL nicht hochladen... vielleicht kann ich die jemandem per mail schicken,der sie dann für mich hochladen kann/versucht!?

Du kannst alles hochladen, wenn Du die Forensoftware austrickst. Einfach abc.dll umbenennen in abc.dll.txt

' schrieb:Du kannst alles hochladen, wenn Du die Forensoftware austrickst. Einfach abc.dll umbenennen in abc.dll.txt

@Lucki: Hast du Beitrag #7 gelesen? Hat sich inzwischen geändert, dll geht jetzt direkt. Ansonsten hast du natürlich recht...

Danke@Lucki!!!



Also,ich hab es mal Versucht.Eigendlich müsste es ja funktionieren,ist ja alles ganz logisch was "IchSelbst" da rausgefunden hat...........aber............es geht nicht!

Wenn ich Parity auf "Even" hab,kommt wieder die Fehlermeldung: "Error -1073807253 occured at VISA read in Thermostat.vi" und dann noch "VISA:(Hex 0xBFFF06B)A"

Wenn ich jedoch entgegen der Beschreibung und des Demo-Programms "none" als Parity nehme,kommt keine fehlermeldung und das was mir geschickt wird,kann ich auch lesen und zwar "0400015"!!

"04h" = "EOT"-> Ende der Übertragung,Empfangsstation geht in den wartezustand
"000" hab ich keine ahnung

"15h" = NAK!....is dann die "000" vielleicht der Fehlercode von dem NAK!?


Schön tag euch allen!

' schrieb:Wenn ich jedoch entgegen der Beschreibung und des Demo-Programms "none" als Parity nehme,kommt keine fehlermeldung

Du kannst aber nicht none benutzen - dein Protokollanalyser sagt eindeutig: "Parity: EVEN".

Zitat:und das was mir geschickt wird,kann ich auch lesen und zwar "0400015"!!

So wie das da steht - also 0400015 - ist das nicht eineindeutig. Ist das jetzt die Hexanzeige eines Strings oder die ASCII-Anzeige? Als Hex wäre es 0x15, 0x00, 0x40 - auf jeden Fall fehlt ein Zeichen, da hex eigentlich immer ein Vielfachen von 2 sein sollte. Als ASCII sind es aber sieben Ziffern.

Außerdem: Hast du zwischen Schreiben und lesen eine Pause gemacht. Ich tippe mal auf 250ms.

[*nachdenk*]

Außerdem: Die Fehlermeldung Framing-Error heißt nicht zwangsläufig, dass das Parity falsch ist. Es gäbe auch folgenden Fall. Das Endgerät kann an einen Bus angeschlossen werden. Demzufolge muss es die Ausgangsleitung auf Tristate schalten. Wenn das Endgerät was senden soll, muss es die Leitung aktivieren. Dieses Deaktivieren bzw. Aktivieren bewirkt einen Framingerror (guckst du Grundlagen RS232)! Um den zu löschen sendet das Original-Programm über Purge TxClear und RxClear (was man normalerweise nicht macht). Durch das Abschalten des Busses kann das 0x10 kommen, das im Protokollanalyser zu sehen ist.

Ich schlage folgendes Vorgehen vor: Versuche, Visa so zu konfigurieren, dass alle Fehler ignoriert werden - wenn das geht. Die DÜ machst du wie folgt: Daten senden - 250ms Warten - Daten lesen - alle Puffer lsöchen. Die Errorausgänge der Visa-VIs gibst du zur Kontrolle auf ein Anzeigeelement. Das VI, in dem sich die Visa-VIs befinden, stellt du (unter Einstellungen - Ausführung) ein auf "Keine automatische Fehlerbehandlung".

Wenn das mit dem Bus stimmt, tritt der Framing-Error grundsätzlich auf und muss quasi ignoriert werden.

' schrieb:Danke@Lucki!!!
Also,ich hab es mal Versucht.Eigendlich müsste es ja funktionieren,ist ja alles ganz logisch was "IchSelbst" da rausgefunden hat...........aber............es geht nicht!

Wenn ich Parity auf "Even" hab,kommt wieder die Fehlermeldung: "Error -1073807253 occured at VISA read in Thermostat.vi" und dann noch "VISA:(Hex 0xBFFF06B)A"

Wenn ich jedoch entgegen der Beschreibung und des Demo-Programms "none" als Parity nehme,kommt keine fehlermeldung und das was mir geschickt wird,kann ich auch lesen und zwar "0400015"!!

"04h" = "EOT"-> Ende der Übertragung,Empfangsstation geht in den wartezustand
"000" hab ich keine ahnung

"15h" = NAK!....is dann die "000" vielleicht der Fehlercode von dem NAK!?
Schön tag euch allen!

Bitte nicht vergessen: Ich glaube in der Dokumentation etwas von einer Checksumme gelesen zu haben. Das könnte sich noch als tricky herausstellen, obwohl; da wurde auf eine DIN Norm hingewiesen wenn ich mich noch richtig erinnere.

Rolf Kalbermatter

Als Wartezeit hab ich immer 500ms gehabt...aber 250ms machen da auch nix anderes,oda!?

Zitat:Außerdem: Die Fehlermeldung Framing-Error heißt nicht zwangsläufig, dass das Parity falsch ist. Es gäbe auch folgenden Fall. Das Endgerät kann an einen Bus angeschlossen werden. Demzufolge muss es die Ausgangsleitung auf Tristate schalten. Wenn das Endgerät was senden soll, muss es die Leitung aktivieren. Dieses Deaktivieren bzw. Aktivieren bewirkt einen Framingerror (guckst du Grundlagen RS232)! Um den zu löschen sendet das Original-Programm über Purge TxClear und RxClear (was man normalerweise nicht macht). Durch das Abschalten des Busses kann das 0x10 kommen, das im Protokollanalyser zu sehen ist.

Versteh ich nicht ganz! Meinst du vielleicht,dass der Port immer erst vor jedem Senden/Empfangen wieder auf ein Definierten Wert zurück gesetzt werden muss? Oder,dass der Port immer nach jedem Befehl geschlossen werden sollte?

Zitat:Ich schlage folgendes Vorgehen vor: Versuche, Visa so zu konfigurieren, dass alle Fehler ignoriert werden - wenn das geht. Die DÜ machst du wie folgt: Daten senden - 250ms Warten - Daten lesen - alle Puffer lsöchen. Die Errorausgänge der Visa-VIs gibst du zur Kontrolle auf ein Anzeigeelement. Das VI, in dem sich die Visa-VIs befinden, stellt du (unter Einstellungen - Ausführung) ein auf "Keine automatische Fehlerbehandlung".

Also das mit der "Keine autom. Fehlerbehandlung" hab ich gemacht,hat jedoch nix genützt! Und wie konfigurier ich das VISA so,dass alle Fehlermeldungen ignoriert wird?



Noch eine Frage: Wenn ich "04 24 20...." in das String bedienelement eingebe,dann steht nach dem senden "04s24s20s30s30s31s05" als string da! Hab ich da was falsch gemacht?

Zitat:Bitte nicht vergessen: Ich glaube in der Dokumentation etwas von einer Checksumme gelesen zu haben. Das könnte sich noch als tricky herausstellen, obwohl; da wurde auf eine DIN Norm hingewiesen wenn ich mich noch richtig erinnere.

Versteh ich nicht! Bin hier kein mega Checker,der das versteht:Was ist denn eine Checksumme?

Hab das zwar bei Wiki gelesen,jedoch nix in meiner Doku gefunden! Die nützt mir doch nur was,wenn ich was gesendet bekomme,was ich auch lesen kann,das ist ja bis jetzt nicht der Fall!