CRC Berechnung: Codebeispiel vorhanden

Hallo,

im Zuge meines Projektes soll ich nun einen Massenflussregler ansprechen. Dabei habe ich keine Treiber oder VIs für diese Geräte gefunden. (Sierra Instruments, Smart-Trak 2) Allerdings ließ sich im Internet eine Dokumentation finden, welche die ASCII Steuerbefehle enthält.

Das hab ich zwar auch noch nicht angewendet, aber in der Anleitung steht, dass jedes Signal aus 4 Byte Steuerzeichen + Einzustellender Wert + CRC+ cr besteht.

Steuerzeichen entnehme ich aus der Doku, Wert weiß ich selber doch dann kommt die CRC. Ich muss also die Prüfsumme für den String berechnen. Dafür ist in der Doku je ein Code für C# und für VB gegeben. Im Forum habe ich Beispiele für die Berechnung gefunden, aber die scheinen bei mir nicht zu funktionieren. Der code wird also wohl kein Standart sein.

Ich selber behersche beide Sprachen nicht und einfaches kopieren mit Anleitung zur DLL erstellung aus dme Internet hat nicht funktioniert. Ich habe den code mir vorgenommen und versucht zu verstehen, um ihn anschließend nachzubauen in LabView. allerdings kann ich mit dem code so nicht viel anfangen, vor allem da "[...] * &H100" und ähnliches mir gar nichts sagt.

Ich wäre sehr dankbar, wenn mir entweder jemand den Code erklären könnte oder mir eine DLL erstellt, die mir dann beim Einbinden in LV eine VI liefert, die mir aus einem gegebenen String den CRC Wert berechnet. Den Code findet man unter dem obigen Link in der Doku. Auch wenn der zweite Weg sicher nicht der beste ist, aber um mich tiefgehend mit C auseinanderzusetzten hab ich eigentlich nicht die Zeit. Also wenn es ohne geht, wäre das naütrlich top.

Außerdem wäre noch die Frage, in welchem Format ich dann die Steuerbefehle an das externe Gerät senden muss. So im "Klartext" wie es in der Doku steht oder muss das vorher in Hex umgewandelt werden? da am anfang der Doku steht, dass alle Reichen bsi auf die beiden CRC-Bytes ASCII sind, würde ich die ASCII Nummern senden, also z.B. wenn in der Doku ein A steht dann eben 65 usw.

Besten Dank fürs lesen,

Takuro

Für gegebenen C-artigen Code kannst du versuchen das im Formulanode umzusetzen.
z.B. so
   
Keine Ahnung, ob das so tut, ist nur 'ne Idee.

OK, das hat mich insofern weitergebracht, dass ich jetzt die CRC in Labview habe.

Unten findet ihr nun meinen aktuellen Stand. Allerdings reagiert das Gerät nicht auf die Einstellung.

Laut Anweisung in der Doku ist der String wie folgt aufgebaut:

!Setf+value+CRC+cr

Ich möchte den Wert '1' übertragen.

Ich dachte, dass ich dies so realisiert habe. In dem Ausgabefeld erscheint 65081. Dies wäre dann die Prüfsumme, aber das sollen nun ja nur 2 Byte sein.

Das Gerät reagiert ohne Probleme auf die mitgelieferte Software, es ist also korrekt verbunden.

Ich hoffe auf weitere Einfälle.

Grüße,

Takuro

VIs zur Checksummen-Berechnung CRC16 gibt es viele, z.B im Labview Portal
In der von Dir genannten Doku ist im entscheidenden Beispiel ein Fehler (Rot):

/* If the string Sinv2.00 is sent through this routine the crc = 0x8f55 */
/* The complete command “Sinv2.000” will look like this in hex
0x53 0x69 0x62 0x76 0x32 0x2e 0x30 0x30 0x30 0x8f 0x55 0x0d */

Man weiß nicht, wie da sonst in der ganzen Doku noch geschludert worden ist. Die Checksummen-Püfung ist eigentlich genormt. Wenn also hier andere Ergebnisse herauskommen als mit dem üblichen CRC16-Algortihmus, dann war das möglicherweise von der Firma gar nicht beabsichtigt.

Anm zu: "In dem Ausgabefeld erscheint 65081"
Es handelt sich hier um die dezimale Darstellung einer U16-Zahl, die definitionsgemäß 2 Bytes lang ist. In HEX wäre das FE39

/* If the string Sinv2.00 is sent through this routine the crc = 0x8f55 */
Genau das kommt aus dem Formula Node raus. Das sieht mir nach nem einfachen Dokumentationsfehler aus.

Herstellerspezifische CRCs gibts doch recht häufig... entweder eigene Polynome (die genormten kann man meist schnell durch probieren) oder ein erfundener Algorithmus der "irgendwas zyklisches" macht (deshalb pauschal als "CRC" deklariert) und die Zahlen solange verwurstet bis es ohne Doku/Beispielcode keinen Spass mehr macht. Das ist dann aber eben gewollt.

Manchmal hilft auch versuchen mitzuloggen was die Herstellersoftware so alles auf die Schnittstelle schreibt und damit zu verifizieren das man selbst die String richtig zusammen gebaut hat.

Hallo,

Dank eurer Tipps hab ich nun mehr verstanden und nun das ganze auch hinbekommen.

Es lag noch an zwei Punkten:

1) Der CRC wird als Hex ausgegeben. Allerdings hat die VI es als String interpretiert und somit beim senden nochmal umgerechnet.

2) Es werden vor dem CRC 2 Leerzeichen ausgegeben. Warum auch immer.

Wenn man das alles behebt, dann funktioniert es. VI siehe unten.

Danke nochmal.

Grüße,

Takuro

(31.05.2011 17:26 )macmarvin schrieb:  Herstellerspezifische CRCs gibts doch recht häufig...

Du hast Recht, und auch hier ist das klar der Fall. Hier wird die U16-Zahl in einen String mit 2 Byte konvertiert, also nicht als hexadezimaler String mit 4 Byte. Das führt zu nicht druckbaren Zeichen. U.a. könnte auch das Steuerzeichen "Zeilenrücklauf" auftreten, und die Zeilenendekennung würde unbrauchbar. Damit das nicht passiert, werden im CRC-Programm die Zeichen 0x00 und 0x0D abgefangen und durch etwas anderes ersetzt. - und das ist auf jeden Fall firmenspezifisch.