VB Forum / General / August 2004

Yes... :)

Impossible to tell remotely.  I'd suggest getting a serial port analyzer
and determining precisely what is occurring on the offending machine(s)
first...

Hi,

On 99% of the computer this works just fine.  On the occasional computer the
scheme fails, for some reason the echo just breaks down.  It appears that
the computer either doesn't send out a character in the middle of a stream
of characters or it just fails to receive the echo.  Could this be hardware,
could it be a driver, are that any settings for the RS232 port that could
cause this?
<<

These sorts of problems are almost always related to one of two issues.

1.  There is a timing problem that your program logic does not anticipate.
2.  There is a more serious logical problem that gets exposed only in
marginal situations.

Both of these require examining the program logic in detail, and to use
external tools to aid the debugging is a useful step.

AFAIK, there "should" be no issue with hardware, driver, or settings that
might cause this.

Dick

Hi Mike,

1) What is the baud rate you are operating at?

2) How long is the serial cable that you are using?

3) Does the piece of hardware use a MAX232 or similar type of RS-232
transceiver IC?

You might be running marginally if the cable is long (extra cable
capacitance) and you are running at a very high baud rate.

A few things that *might* be worth your time investigating.

1) As a test, do you have the liberty to lower the baud rate at both ends?
If so, you might want to try this -- if the problem goes away, it *might* be
related to the cable length and its capacitance and the baud rate you are
running -- but always keep an open mind when troubleshooting however.

2) Perhaps you could use another computer to emulate the hardware device
(the piece of equipment your company makes) from a communications
perspective. This would effectively eliminate the hardware device from the
equation (divide and conquer) and you could then see if you are still
experiencing the same problem.

Best regards,

Ken Pergola

make certain the rs232 protocol cd/rts/cts/rts/dsr is properly setup on the "bad" machines

some modem setups automatically assume full sync operation/ others will take shortcuts and "leave out" some handhsake signals to
simulate "improved speed"  (good for handshakng with crc/challenge, but bad for hardware equipment that can only see/expect distinct
data streams)

never assume the setups are identical on all machines ports just because they work ok on internet  or lan connects.  dedicated comms
to hardware devices can be picky and truly unforgiving.

perhaps u may use a method to step down the rate when problems arise, just as dialup modems do when connecting , to ensure reliable
data connects to phone lines ( & they can be affected by weather/line noise/RF interference that degrade signal patency)

--

Best regards,
Hapticz

STOP STOP STOP STOP STOP STOP STOP STOP STOP
<>><<>><<><>><<><>><<>><<><>><<>><<>><<>><<>><<>

I had a problem which only turned up on one type of machine

Using the APIs to read and write to the COM port, on the 'faulty' type
of machine I got buffer overruns, even though I was explicitly waiting
for the CTS before sending each character.

Eventually I reckoned that the machine was running so fast that the
CTS was not getting lowered before I checked it again.

The problem was eventually 'solved' by a timing loop before sending
each character.

I am fairly sure that it was a case of the PC running faster than the
hardware.

Your problem might be something similar.