For debugging you could also... Have a perl program open the tty port, and open a named pipe for i/o. anything coming in from the pipe, convert it to CHAR() equiv and append it to a file then write it to the tty port anything coming in from the tty, convert it to CHAR() equiv and append it to another file then write it to the named pipe.
Have the UD program read/write to the named pipe instead, this way you will have a file of exactly what came and went. one caveat, if you stop the UD program, you will need to restart the perl program to re-establish the pipe. when the UD program stops, the pipe is broken. George >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] Behalf Of Ed Clark >Sent: Tuesday, March 01, 2005 4:51 PM >To: [email protected] >Subject: RE: [U2] [UD] LINE.ATT for attaching serial line > > >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/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
