Well, I knew I was doing something wrong.
Thanks for the help.
Jim
------------------
Announcement
Collapse
No announcement yet.
Serial port break detection / ignoring
Collapse
X
-
Originally posted by Paul D. Elliott:
...may be wrong...
------------------
Leave a comment:
-
Just a guess but move the On Error line above the Input$ line.
And it probably only needs to be done once, not within a loop.
unless you're resetting with an On Error GoTo 0. but this last
may be wrong as it's been a while since I've done error handling
in DOS.
------------------
Leave a comment:
-
Okay, what am I doing wrong?
The original problem was that a break would cause an Error 57 at the following line:
[CODE]
XCommand$ = Input$(1,#99)
[CODE]
So I modified it as follows:
[CODE]
XCommand$ = Input$(1,#99)
On Error Resume Next
If (Err <> 57) then
NewCommand$ = NewCommand$ + XCommand$
else
incr BreakCount%
locate 1,1
print BreakCount%
End if
[CODE]
BreakCount% is declared as SHARED at the beginning of the program.
As I understand it, a valid character should be handled correctly, while an error should update the error count at the top left of the page. Instead, I sometimes get a program failure with Error 57 ans the message.
Or am I missing something?
Jim
------------------
Leave a comment:
-
Jim,
I never used BREAKs on a COMM under BASIC, but I do know what it does mean. A break results as a start bit, the data bits, may be the parity bit, and an INVALID stop bit. This stop bit results in an error 57, and is related to the "break" character. You should setup an error trap and receive single chars one by one. If you get that errorr 57 and the char is a NUL, it was a break.
------------------
Leave a comment:
-
Mel -
As an example: from http://wandel.ca/homepage/dswitch/switchdocs.html
"An RS-232 "break" signal is used to obtain the processor's attention. This signal consists of the RS-232 line being continually high (+12V, logical zero) for a period exceeding a normal character time."
In other words, you get a start bit, 8 data bits, and then no stop bit. That's why the serial port flags it as bad formatting.
The command/response protocol is a custom structure, taking advantage of the fact that the server only asks me for data, and all I do is respond to such requests. Requests are simple character strings with a delimiter. Responses are similar.
I guess an error trap is the way to go.
Jim
------------------
Leave a comment:
-
Originally posted by Jim Martin:
...(logic 0 for longer than a word)...
What kind of flow control are you using (Xoff/Xon)?
If nothing else works, try using ON ERROR to trap it.
------------------
Leave a comment:
-
Serial port break detection / ignoring
Howdy, all -
I'm using a serial port to communicate telemetry data to a server, and the server sends a "break" (logic 0 for longer than a word) at various intervals. Of course, PB detects this as a formatting error and terminates the program with an error 57.
I've looked through the manual and can't find mention of a way to disable the function.
Does anyone have any suggestion?
Thanks,
Jim
------------------
Tags: None
Leave a comment: