So, you've got a line of code something like
SEND ACK: TO PORT ELSE GOTO DISASTER:
and the POS is seeing other stuff besides your ACK? If you left out the
colon after the ACK then you will be sending extra line feeds--you might
want to check that. You also might want to check and replace the serial
cable going from the systech to your com port--if there's a short in it, one
end or the other can see echoed or trash characters.
And, speaking of echo, do you have an ECHO OFF in your program? The GET that
you're using to look for the ENQ might be echoing back what the POS sends.
I seriously doubt you need the DELAY. It sounds like the DELAY would be used
if you were talking to a named pipe, but not for a standard serial
connection. I'm assuming here that the serial connection is full duplex.
Do you have a dumb terminal or pc with terminal emulation that you could
connect to your com port and to the systech so that you might step through
the protocol manually and see what's really going back and forth, without
having to rely on tech support to tell you what they think they are getting?
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Dana Baron
Sent: Tuesday, March 01, 2005 3:47 PM
To: [email protected]
Subject: RE: [U2] [UD] LINE.ATT for attaching serial line
Ed Clark wrote:
>So, 2 questions: first, are you seeing the ENQ (and is there any associated
data with the ENQ?);
I'm seeing the ENQ fine. Unfortunately, I need to work with Squirrel support
to help debug this, but they report that they're seeing my ACK embedded in
other data, things like CR LF, etc, but the data is not consistent. They
look only at the first character and if its not an ACK, they ignore it. Once
I changed to use DELAY, Squirrel recognized the ACK on the first try.
> second, what is the baud rate/parity of the systech, and where are you
setting it? If you are getting the ENQ and sending an ACK that's
unrecognized, maybe you've got the wrong parity.
It seems that the baud and parity are all fine since I can see the data
correctly at both ends, it just isn't matching the protocol, and as I said
above the data I'm sending is getting mixed up with other stuff. And the
DELAY parameter on the LINE.ATT helps sort things out, at least for the
first SEND.
>Finally, it sounds like your POS is using tcp to talk to the systech, and
then you're using serial for the systech to talk to unidata. Would it be
possible to use tcp sockets and go directly from the POS to unidata without
the impediment of a serial link?
I've explored that option with Squirrel (the POS brand), and unfortunately
it's a no go. I can't understand why not in this day and age, but I'm
playing with their toys.
Thanks for the follow-up questions.
Dana Baron
System Manager
Smugglers' Notch Resort
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
