[VB6] Output via MSComm heeft Checksum nodig

[Ciqniz]

Ik ben bezig een machine aan te sturen via de COM-poort in VB6. Nu heb ik alles gereed, maar de uiteindelijke aansturing krijg ik niet aan de praat.

Ik heb een uitgebreide handleiding er bij gekregen, maar 1 ding vat ik er niet uit.

Om een opdracht te geven moet ik de volgende regel in de output zetten:

code:

STX a HT b HT opdracht CR LF checksum ETX

waarbij,

STX het startsein is;
a het Taaknummer van het apparaat is;
HT een separator is;
b het Taaknummer van de software is;
HT nogmaals een separator is;
opdracht de opdracht aan de machine is;
CR LF een verplichte carriage return linefeed is;
checksum de checksum is;
ETX is er om het einde van de opdracht aan te duiden.

Checksum wordt op de volgende manier gebruikt (ik citeer uit de handleiding):

Checksum: Checksum with four digits (calculated with all characters excluding ETX)

Checksum is uiteindelijk HEX dus, ze geven voor de aardigheid ook een voorbeeldje:

code:

STX e HT o HT RESULTBOX CR LF 0CC4 ETX

e en o snap ik even niet, dit moeten decimale getallen zijn, als ik dit van HEX naar DEC omreken kom ik uit dat e 14 is en o -1. Als ik dan de mogelijkheden zie, kan e alleen een waarde van 1 tot 4 zijn en 0 van 10 tot 18.

Waar ik het meeste mee zit, waar haalt hij de checksum vandaan? 0CC4 is omgerekend 3268 in DEC. Dus waar komt dat vandaan die 3268? Dat komt niet overeen met zijn idee van een checksum, zoals eerder stond uitgelegd, volgens mij.

Ik denk dat ik op de checksum dus vast loopt (want uiteraard krijg ik die machine niet aan de praat). Of misschien e en o, of in het vorige voorbeeld, a en b.

Kan iemand die checksum verklaren eventueel?

Voor diegene die het interesseren, het apparaat is een Berthold Centro LB 960, maar weet bijna zeker dat je daar niks aan hebt.

[farlane]

Alle karakters bij elkaar opgeteld ?

[Ciqniz]

Uiteraard, dat als eerste. Inclusief spaties, exclusief spaties, heb de hele opdrachtregel zonder spaties uitgevoerd en ook aan de hand daarvan de checksum ingevoerd, maar het mag allemaal niet baten!

Maar lijkt mij ook stug, want als ik die 0CC4 omreken komt dat op 3268, geloof me, zoveel tekens staan er niet in die ene opdracht

[Verwijderd]

checksum: crc32 (of crc16), het zal geen md5 hash oid zijn met 4 bytes, dus waarschijnlijk een crc variant.

[ Voor 62% gewijzigd door Verwijderd op 09-07-2004 17:05 ]

[Ciqniz]

Misschien dat hier iemand wijzer van wordt:

Als,

0x02 = STX
0x09 = HT
0x0D = CR
0x0A = LF
0x03 = ETX

wat is 0CC4 dan?

Denk alleen dat dit niet klopt...

Edit:

kan ik eventueel 0x02, 0x09 enz. bij elkaar optellen?

[ Voor 17% gewijzigd door Ciqniz op 09-07-2004 17:10 ]

[Verwijderd]

moet die o geen 0 zijn ??

[Ciqniz]

Verwijderd schreef op 09 juli 2004 @ 18:04:
moet die o geen 0 zijn ??

Lijkt me niet, er staat echt een O, en 0 zou ook niet logisch zijn aangezien 0 ook niet in het lijstje voorkomt... En 0 Dec. is ook 0 Hex

[MSalters]

STX is inderdaad een enkel ASCII karakter, Start Transmission . HT is op dezelfde manier Horizontal Tab (9), en CRLF zijn natuurlijk twee control karakters.

Er zijn meerdere checsum algoritmes; welke zou vermeld moeten zijn. Ik zou zelf denken aan optellen van alle ASCII waardes, modulo 65536 (simpel te doen in device, crc16 is moeilijker)

[ Voor 43% gewijzigd door MSalters op 09-07-2004 19:20 ]

[pkouwer]

meestal is de CRC een checksum van de gehele string minus STX, CR en LF. Staat wsl. ook in de handleiding. is het geen XOR-functie ?

[MSalters]

XOR is onhandiger dan optellen, omdat het makkelijker door een twee-bit fout wordt beinvloed (tenminste voor RS-232). Ik heb het om heel eerlijk te zijn ook nog nooit gezien.

[farlane]

MSalters schreef op 10 juli 2004 @ 09:46:
XOR is onhandiger dan optellen, omdat het makkelijker door een twee-bit fout wordt beinvloed (tenminste voor RS-232). Ik heb het om heel eerlijk te zijn ook nog nooit gezien.

XOR checksums komen vrij veel voor in heel simpele ascii protocollen. Vaak bedacht door iemand die niet van het bestaan van betere methoden afweet.

Anywayz, een CRC lijkt me stug voor zo een simpel protocol. Je zult echt de handleiding van het protocol moeten hebben of in ieder geval voorbeelden van hoe het zou moeten.

[Ciqniz]

farlane schreef op 11 juli 2004 @ 16:27:
[...]


XOR checksums komen vrij veel voor in heel simpele ascii protocollen. Vaak bedacht door iemand die niet van het bestaan van betere methoden afweet.

Anywayz, een CRC lijkt me stug voor zo een simpel protocol. Je zult echt de handleiding van het protocol moeten hebben of in ieder geval voorbeelden van hoe het zou moeten.

Een voorbeeld heb ik gegeven (zie hieronder nogmaals:)

code:

STX e HT o HT RESULTBOX CR LF 0CC4 ETX

[ Voor 8% gewijzigd door Ciqniz op 13-07-2004 10:47 ]

[farlane]

KreaToh schreef op 13 juli 2004 @ 10:46:
Een voorbeeld heb ik gegeven (zie hieronder nogmaals:)

code:

STX e HT o HT RESULTBOX CR LF 0CC4 ETX

Ik zou graag een voorbeeld hebben van de data die over de seriele lijn gaat, dus alle karakters als nummers weergegeven.

Dit zou je kunnen afluisteren met een tool als sermon

http://www.softcities.com/Serial-Monitor/transfer/11283.htm

[Ciqniz]

Ok, ik heb de Sermon Monitor gedraaid... Wat dus het geval is, er is ook een bestaand stuurprogramma met alle commando's, test-runs voor de labs en alle berekening inclusief uiteindelijke raw-data output voor excel. Dit programma werkt echter niet lekker, vandaar dat er met VB6 een nieuw programma geschreven wordt. De documentatie voor het schrijven van een eigen stuurprogramma zit wel bij dat apparaat, maar zoals in de OP en verder staat; is dit niet voldoende, ik kom er echt niet uit.

Als ik dat programma het commando Unload plate opgeef, geeft hij de volgende request in Sermon aan:

code:

02 65 09 6F 09 52 45 50 4F 52 54 0D 0A 45 30 43 43 03

Oftewel:

code:

.e.o.REPORT..E0CC.

Zover ik weet kan ik hier helemaal niks mee. Wel ben ik er achter dat de beschreven manier (zie OP) niet zal werken, dit komt precies zo uit in Sermon.

Het is dus nu niet alleen de checksum waar ik problemen mee heb...

[Ciqniz]

Update:

C-Style string:

code:

\x02e\to\tREPORT\r\nE0CC\x03

échte ASCII-string:

code:

e  o   REPORT
E0CC

Hoe krijg ik die ASCII-string nou goed in VB?

[Maasluip]

Je bedoelt hoe je een ascii 2 in een string in VB krijgt?

Visual Basic .NET:

 sString = chr(2)

Dus je hele string wordt:

Visual Basic .NET:

 sString = chr(2) & "e" & vbTab & "e" & vbTab & "REPORT"_
 & vbTab & vbNewline & "E0CC" & chr(3)

Nu ga ik er even vanuit dat \t het tab karakter en \n het newline karakter is en dat die in vb als zodanig gedefinieerd is. Anders ook even de ASCII waarde opzoeken en invullen.

[edit]
Oh, ik zie dat in je vorige post de string ook in ASCII staat. \t is dus chr(9) en \n is chr(13)+chr(10) .

[ Voor 22% gewijzigd door Maasluip op 06-08-2004 11:48 ]

[Ciqniz]

Maasluip schreef op 06 augustus 2004 @ 11:47:
Oh, ik zie dat in je vorige post de string ook in ASCII staat. \t is dus chr(9) en \n is chr(13)+chr(10) .

Thx

Nu zit ik alleen toch weer met die checksum, E0CC klopt volgens mij niet. Ik zie dat dit 224 (Char) of 52448 (Long) is, maar weet niet aan de hand waarvan dit berekend is. Ik kan er nog steeds niet uitkomen wat in hemelsnaam de checksum zou moeten wezen

[Maasluip]

E0CC is 57548 decimaal, volgens de windows calulator tenminste.

De meest simpele vorm van checksum is de waarde van alle karakters optellen (dus 02 + 65 + ... ), maar dan kom ik maar tot 2DB.
Misschien eens zoeken op checksum algorithm op google? Kan zijn dat je daar wat hints krijgt. Anders de firma die dat apparaat gemaakt geeft aanspreken.

[Maasluip]

En ik ben je nu echt helemaal uit de brand aan het helpen (lazy friday afternoon). Ik wilde tot de conclusie komen dat het geen CRC16 is, totdat ik zag dat ik een fout maakte en \r\n las als \t\n. Toen ik de goede string in een CRC16 generator gaf kreeg ik als checksum CCE0 terug. Dat is dus E0CC maar dan de bytes omgedraaid.

Conclusie: je checksum is simpele (...) CRC16.
De string die je moet ingeven is dus zoals de handleiding zegt de hele string exclusief ETX (en exclusief je checksum uiteraard want die heb je nog niet). Je begint bij de STX dus.

Er zijn op google voldoende voorgeprogrammeerde VB formules voor CRC16 te vinden. Die mag je zelf vinden

Ah, en ik zie nu ook waarom je E0CC 52448 noemt. CCE0 is 52448.

edit:
waarom doe ik nu geen edit?

[ Voor 9% gewijzigd door Maasluip op 06-08-2004 13:33 ]

[glashio]

• Deze codes hebben in VB namespaces :
• Chr(10) = vbLf
• Chr(13) = vbCr

Resource ( deze VBscript CONSTANTS komen overeen met VB )

[farlane]

Maasluip schreef op 06 augustus 2004 @ 13:30:
En ik ben je nu echt helemaal uit de brand aan het helpen (lazy friday afternoon).
Conclusie: je checksum is simpele (...) CRC16.

Netjes dat je deze meneer uit de brand het geholpen.

( Ik kan me alleen niet voorstellen dat dit niet in de specs staat )

[Ciqniz]

Allereerst, ontzettend bedankt mensen , met name Maasluip

Ik ben er achter gekomen dat dit de juiste manier is om de machine aan te spreken:

Ten eerste wordt de poort geopend:

code:

MSComm1.PortOpen = True

Daarna meteen moet het volgende commando gegeven worden:

code:

MSComm1.Output = Chr(2) & "e" & Chr(9) & "o" & Chr(9) & _
 "REPORT" & Chr(13) & Chr(10) & "E0CC" & Chr(3)

Vervolgens kunnen we beginnen.
De volgende code zorgt er voor dat de plaat uit de machine schuift:

code:

MSComm1.Output = Chr(2) & "e" & Chr(9) & "o" & Chr(9) & _
 "UNLD" & Chr(13) & Chr(10) & "1B37" & Chr(3)
MSComm1.Output = Chr(2) & "e" & Chr(9) & "o" & Chr(9) & _
 "RUN" & Chr(13) & Chr(10) & "25ED" & Chr(3)
MSComm1.Output = Chr(2) & "e" & Chr(9) & "o" & Chr(9) & _
 "REPORT" & Chr(13) & Chr(10) & "E0CC" & Chr(3)
MSComm1.Output = Chr(2) & "e" & Chr(9) & "o" & Chr(9) & _
 "LGSTS" & Chr(13) & Chr(10) & "8DB4" & Chr(3)
MSComm1.Output = Chr(2) & "e" & Chr(9) & "o" & Chr(9) & _
 "RUN" & Chr(13) & Chr(10) & "25ED" & Chr(3)

Waarbij "UNLD" hierboven staat voor het ontladen van de plaat dus.

Vervolgens moet de plaat ook weer terug de machine in:

code:

MSComm1.Output = Chr(2) & "e" & Chr(9) & "o" & Chr(9) & _
 "CHLD" & Chr(13) & Chr(10) & "91C1" & Chr(3)
MSComm1.Output = Chr(2) & "e" & Chr(9) & "o" & Chr(9) & _
 "RUN" & Chr(13) & Chr(10) & "25ED" & Chr(3)
MSComm1.Output = Chr(2) & "e" & Chr(9) & "o" & Chr(9) & _
 "REPORT" & Chr(13) & Chr(10) & "E0CC" & Chr(3)
MSComm1.Output = Chr(2) & "e" & Chr(9) & "o" & Chr(9) & _
 "LGSTS" & Chr(13) & Chr(10) & "8DB4" & Chr(3)
MSComm1.Output = Chr(2) & "e" & Chr(9) & "o" & Chr(9) & _
 "RUN" & Chr(13) & Chr(10) & "25ED" & Chr(3)

"CHLD" staat hier dus voor het laden van de plaat terug de machine in.

Bovenstaande stukjes code bevatten allemaal de correcte Checksum! (grotendeels te danken aan Maasluip).

Nu zou het officieel moeten werken, echter doet het nog niks.

Ik weet eigenlijk wel bijna zeker dat het aan de instellingen ligt van het MSComm-Control (MSComm1).

Kan iemand mij misschien vertellen welke instellingen ik het beste kan gebruiken (buffergrootte enzo onder andere)?
Alle instellingen staan nu op default.

[ Voor 23% gewijzigd door Ciqniz op 11-08-2004 17:10 . Reden: oeh, had de lay-out vern**kt! ]

[Ciqniz]

farlane schreef op 07 augustus 2004 @ 10:24:
[...]


Netjes dat je deze meneer uit de brand het geholpen.

( Ik kan me alleen niet voorstellen dat dit niet in de specs staat )

Dit staat écht niet in de specs vreemd genoeg, zelf drivers schreven is maar matig ondersteund, maar het standaard meegeleverde programma voldoet écht niet .

[farlane]

Aangenomen dat je commsettings goed staan, je de goede kabel hebt en je crc functie correct werkt ( ik neem aan dat je die inmiddels hebt ) zou je een timing probleem kunnen hebben. Probeer eerst het hele bericht samen te stellen en dan pas door te geven aan je comm control. Moet je misschien handshaken ? Heb je er een converter tussen zitten die handshaking verwacht ?
Als het helemaal niet lukt, zet dan een scope op de kabel en run het originele programma. Bekijk de timing van send / receive en rts / cts. Kijk waar jouw app de mist in gaat.

Mijn ervaring is dat het vrij lastig is om met de ms comm control stabiele communicatie op te zetten ( betekent 24/7 aktief zonder rare toestanden ).

BTW Buffergroottes hoef je normaal gesproken niet aan te komen.

[Edit]

Kijk ook ff of je je componentje in de goede modus ( ascii / binair ) hebt staan. Weet zo ff niet meer hoe het ding heet. Zet je handshaking op de verkeerde instelling, dan kan het zijn dattie wat tekens aanziet voor een XON of XOFF )

[ Voor 15% gewijzigd door farlane op 11-08-2004 19:10 ]

[Ciqniz]

Ondertussen ben ik na heel veel pijn en moeite in contact gekomen met een van de programmeurs van de originele software (uit Duitsland). Deze heeft mij een aantal instellingen kunnen vertellen, zoals: MSComm1.Settings = "38400,n,8,1".

Ook heeft hij laten weten dat er geen (getimede) pauzes nodig zijn tussen de commando's door. Wél belangrijk is dat er na elk commando iets ontvangen moet worden. Dus na MSComm1.Output = blaat moet Text1.Text = MSComm1.Input komen bijvoorbeeld.

Een reden waarom ik nog geen ontvangst krijg van de machine kan misschien komen omdat ik verkeerd zit met Hardware Flow Control, maar snippets/tutorials over Hardware Flow Control vind ik eigenlijk alleen maar in C... Ik heb eigenlijk alle mogelijke settings nu wel geprobeerd in VB met het MSComm-Control.

Iemand misschien een idee hoe Hardware Flow Control te beheren in VB(6)?

[EDIT:]
Het werkt!

De volgende instellingen toegepast op MSComm-control:

code:

MSComm1.CommPort = 1
MSComm1.Settings = "38400,N,8,1"
MSComm1.InputLen = 0
MSComm1.RThreshold = 1
MSComm1.Handshaking = comRTSXOnXOff
MSComm1.RTSEnable = True

Daarbij heb ik alle pauzes verwijderd tussen de commando's door, het draait nu perfect!

Bedankt allemaal voor jullie hulp!

[ Voor 20% gewijzigd door Ciqniz op 18-08-2004 14:34 ]

[farlane]

KreaToh schreef op 18 augustus 2004 @ 11:12:
Iemand misschien een idee hoe Hardware Flow Control te beheren in VB(6)?

Je kunt RTS handmatig hoog/laag maken. Waarschijnlijk kun je oo wel een commevent krijgen op cts.

code:

...
MSComm1.Settings = "38400,N,8,1"
MSComm1.RThreshold = 1
.....

Dit betekent dus wel dat je 38400 / 10 keer per seconde een event gaat krijgen dattie een karakter binnenkrijgt. Lijkt me niet wat je wil. Beter is het om met een timer te checken of je karakters hebt binnengekregen.
Bovendien zitten er wat haken en ogen aan het werken met comm events en de mscomm control.