 |
|
|
|
Topic: RS-232 incoming data not correctly read
|
| By: Roger | Posted on: Jun 12 2014 at 06:15:35 AM | Background: About 2 years ago, I downloaded an evaluation copy of Scomm32 for testing on Win 7 64-bit CPUs which my other OCX (Netcomm) did not support. My EXE was not deployed since then since we convinced our customers to revert to 32-bit. Earlier this week we decided to look at Scomm32 again since more and more people are using USB to Serial port converters that used high COM port numbers and running on 64-bit.
Connection environment: Windows 7 32-bit connected to digital weighing scale with continuous streaming data coming in.
Status: Works great with 5 out of 6 brand scales, including Mettler Toledo, Ohaus, Sartorius, Presica (Taiwan-generic), Cardinal. Facing big problem with the 6th brand, HBM.
Testing done on Hyperterminal-like program, and data seems to be coming in fine in a continuous stream, e.g., "--------- kg G A--------- kg G A--------- kg G A"
The "A" just represents a (Asc 10) so we have 19 characters followed by a CR terminator.
But in my program, all I'm receiving is a string of question marks : ??????????
Relevent code portions (don't worry about the syntax, it's not Microsoft)
----------------------
Function : InitiatePort
If NOT bPortOpened
Call ax1.PropSetCommPort( nPortID )
Call ax1.PropSetSettings( strProtocol )
Call ax1.PropSetRThreshold( nZero )
Call ax1.PropSetInputLen( nZero )
If ax1.PropSetPortOpen( bTRUE )
Call ax1.PropSetInputMode( nZero )
Main logic :
Loop Main
Call InitiatePort2
Call ax1.PropGetInput( vVariant )
Call vVariant.GetString( dfCurrInput )
Set nCt = 1
If strIndicator = 'MT'
Else If strIndicator = 'UW'
Else If strIndicator = 'OH'
Else If strIndicator = 'CD'
Else If strIndicator = 'ST'
Else If strIndicator = 'HB'
Set nMax = SalStrTokenize( dfCurrInput, '', CR, strParsed )
'This parses a -delimited data string into strParsed, an array each of
which element should store "--------- kg G " but shows as
"???????????????????????????" instead inside dfCurrInput. Even the CR is
not visible
| |
| By: Guest | Posted on: Jun 13 2014 at 10:06:25 PM | | The question marks usually indicate a parity error. Is the scale using 7bits even parity? | |
| By: Guest | Posted on: Jun 14 2014 at 01:43:55 PM | | Yes it is, we always set the scales and the software protocol to 7, Even, 1 | |
| By: Guest | Posted on: Jun 16 2014 at 08:19:23 PM | In that case i would suggest setting the ocx to 8, None, 1 which will make it ignore parity errors but you'll need to programmatically strip the parity bit if set. You strip the parity bit simply by
If n > 127 then n = n - 128 | |
| By: Roger | Posted on: Jun 17 2014 at 02:13:11 AM | Alright, I'll try this out (I've always set E,7,1 for all other indicators), but in the meantime, how is it possible that Terminal programs can show the streaming data correctly, whilst my commands can't? Would the Terminal program be using some other kind of DLL and would it make any difference over an OCX?
| |
| By: AnotherGuest | Posted on: Jun 17 2014 at 08:51:03 PM | Hyperterminal (I think) uses the Windows Telephony API whereas the OCX (and other 3rd party OCXs use the Win32 API.
It may be that the scales is causing framing errors that hyperterminal knows what to do with - or maybe hyperterminal is simply ignoring parity and framing errors - much like stripping the parity bit as somebody else suggested. | |
| By: Roger | Posted on: Jun 19 2014 at 06:15:07 AM | | To the "Guest" that suggested a Parity change to None,8,1, thank you ever so much. That solved the problem totally which came as a total surprise. Never did I suspect once that a simple thing like parity could have caused this. | |
|
