LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 10-07-2010, 06:39 AM   #1
Schadrach
LQ Newbie
 
Registered: Dec 2007
Posts: 10

Rep: Reputation: 0
Serial port transfer ending early?


I have a new problem tied to the same system as in http://www.linuxquestions.org/questi...l-port-836155/. Apparently when I send the output from

Code:
wget -q -O- http://<IP address>/<filename>.asp?LID=12345 |dos2unix
to /dev/ttyS0 (whether via > /dev/ttyS0 or via > <somefile> then cat somefile > /dev/ttyS0) it only transfers part of the data. Instead of receiveing:

Code:
<]01Y425X472 Y55X50F0 Y110X50F0 Y165X50F0 Y220X50F0 Y55X250F0 Y275X50F0 Y330X50F0 Y330X180F0 Y330X180F0 Y385X50F0 Y385X330F0 Y275X290F0 Y330X290F0>
<0501175
OX-31160/XCM6090
Y-BFW-7155-A34A-SH1
Y-7155-BFW-16
AREA Y
NONE
.
. .
 
. 1 OF 5
12345
.
.>
<0501175
OX-31160/XCM6090
Y-BFW-7155-A34A-SH1
Y-7155-BFW-16
AREA Y
NONE
.
. .
 
. 2 OF 5
12346
.
.>
<0501175
OX-31160/XCM6090
Y-BFW-7155-A34A-SH1
Y-7155-BFW-16
AREA Y
NONE
.
. .
 
. 3 OF 5
12347
.
.>
<0501175
OX-31160/XCM6090
Y-BFW-7155-A34A-SH1
Y-7155-BFW-16
AREA Y
NONE
.
. .
 
. 4 OF 5
12348
.
.>
<0501175
OX-31160/XCM6090
Y-BFW-7155-A34A-SH1
Y-7155-BFW-16
AREA Y
NONE
.
. .
 
. 5 OF 5
12349
.
.>
as an example, it only seems to get the first 3 data blocks and then part of the fourth, as in:

Code:
<]01Y425X472 Y55X50F0 Y110X50F0 Y165X50F0 Y220X50F0 Y55X250F0 Y275X50F0 Y330X50F0 Y330X180F0 Y330X180F0 Y385X50F0 Y385X330F0 Y275X290F0 Y330X290F0>
<0501175
OX-31160/XCM6090
Y-BFW-7155-A34A-SH1
Y-7155-BFW-16
AREA Y
NONE
.
. .
 
. 1 OF 5
12345
.
.>
<0501175
OX-31160/XCM6090
Y-BFW-7155-A34A-SH1
Y-7155-BFW-16
AREA Y
NONE
.
. .
 
. 2 OF 5
12346
.
.>
<0501175
OX-31160/XCM6090
Y-BFW-7155-A34A-SH1
Y-7155-BFW-16
AREA Y
NONE
.
. .
 
. 3 OF 5
12347
.
.>
<0501175
OX-31160/XCM6090
Y-BFW-7155-A34A-SH1
It drops at exactly the same spot regardless of how I send the output from the PC to /dev/ttyS0. Is there some trick to prevent it from simply dropping the serial connection midway through?

Does it matter that the device takes upwards of 30s per data block to process them and cannot store all of the data on the machine itself (it holds ~2 at a time)? This wasn't a concern when I was using a windows machine for this purpose, simply directing the output "> COM1:" worked perfectly fine, it simply paused and fed more data when the machine was ready.
 
Old 10-07-2010, 10:22 AM   #2
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,396
Blog Entries: 2

Rep: Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908
There are a number of behaviors that a serial port may have, inherited from its roots as a terminal attachment interface, and which individually or collectively may contribute to the effects you are seeing. Are there any escape sequences embedded in the data? Bytes that would invoke software flow control (XON/XOFF)? Is the serial port configured to use line oriented input/output? How does the serial port respond to its input (data from the attached device)? Sorting out these kinds of issues can be tricky.

You can see/set the serial port configuration with the stty command.
Code:
stty -F /dev/ttyS0 --all
--- rod

Last edited by theNbomr; 10-08-2010 at 02:07 AM.
 
Old 10-07-2010, 12:53 PM   #3
Schadrach
LQ Newbie
 
Registered: Dec 2007
Posts: 10

Original Poster
Rep: Reputation: 0
Output from the command you gave:

Code:
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke
I used "cat testdata > /dev/ttyS0" with the contents of the second code block in my original post in the file testdata and it goes through until the fourth block that starts <0501175 with no problems, at that point it chokes. For very short jobs (less than 4 data blocks), it works fine. It chokes at the same spot regardless of which project's data I feed it, as well.

The data being sent to the port always consists of alphanumerics, -<>.]/\, and newlines. Most other characters are not printable by the plate embosser so we filter output of them on the web server, including a few substitutions such as IN for " and FT for '.

UPDATE: Got it working by fiddling with the stty setings. Final wokring settings were:

Code:
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke
though those also required that I not pipe my wget through dos2unix. Apparently the serial port driver itself was altering my newlines in an inconvenient way.

Most of that was the result of
Code:
stty -F /dev/ttyS0 raw

Last edited by Schadrach; 10-07-2010 at 01:59 PM.
 
Old 10-13-2010, 11:36 AM   #4
Schadrach
LQ Newbie
 
Registered: Dec 2007
Posts: 10

Original Poster
Rep: Reputation: 0
OK, maybe not so solved.

If I use any variety of flow control, it has the issue above, with varying numbers of data blocks (2-5) before it cuts off depending on whether I'm using XON/XOFF(ixon) or hardware(crtscts) flow control. If I disable both, it will go about 5-6 data blocks, and then loop through those ~20ish times, before ending with a buffer overflow error.

I looked up the data on the machine itself, and all it has regarding serial port config is that it needs to be 9600 baud, 8 data bits, 1 stop bit, no parity. That unfortunately doesn't help much, as far as why the connection seems to constantly get cut off early unless I disable flow control completely, which has more disasterous results.
 
Old 10-13-2010, 12:52 PM   #5
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,396
Blog Entries: 2

Rep: Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908
What are you using to monitor the serial data output? As I understand the problem, you have an external serial device, and it requires time to digest various elements of the serial data stream. How are you able to ascertain whether or not the data is actually being transmitted on the serial cable, or whether it is being inhibited somehow in hardware &/or software? Does the device display the data stream? Have you tried sending data to another dumb terminal, just to confirm that there is nothing interfering with the transfer? While doing so, it might be illuminating to exercise Xon/Xoff, to see how it behaves. There does exist a quasi-Xon scheme, where a receiving device issues Xoff, and then any other byte sent (not necessarily Xon) is expected to be interpreted as Xon. I don't know if the Linux serial driver is capable of supporting this, but I am wondering if your device is trying to use it. You should be able to test that using a dumb serial terminal (like a Linux box running C-Kermit or minicom). You can also use such a terminal to send data, and something like C-Kermit can probably be more flexible about providing flow control and pacing on transmit, than can the bare port driver.
On what device are you seeing the buffer overflow error? Are those the exact words displayed? Can you break your data into smaller blocks (file per block), and send them one at a time, with short pauses interleaved? This may artificially pace the process to a rate acceptable to your device. If using hardware flow control, you must have a cable that it wired accordingly. Sometimes, cables are made with loopbacks just to satisfy the driver that it is always okay to send.

--- rod.
 
Old 10-14-2010, 07:00 AM   #6
Schadrach
LQ Newbie
 
Registered: Dec 2007
Posts: 10

Original Poster
Rep: Reputation: 0
The device doesn't so much display the data, as emboss it in metal. In the example data given above, the first block in <> is formatting data, describing the size of a piece of plate being used, and the position at which to put each data field (it's measured in motor steps, which are different for the horizontal motor than the vertical motor) as well as which font to use (which is always 0 as this machine has only a single wheel). Each subsequent block describes the contents of a single plate, arranged according to the format block.

When the data stream gets interrupted, however it does, it's actually difficult to tell until the following attempt to print. For example, if it receives "<0501175" (for example) before it stops receiving, it will not do anything with that data, because it did not receive a complete block. However, it treats everything until it receives and end-of-block indicator ">" as part of that block, so when the next job starts, it interprets the formatting block as part of the data block, and stamps a plate with "0501175" in the position of the first field, and "01Y425X472 Y55X50F0 Y110X50F0 Y165X50F0 Y220X50F0 Y55X250F0 Y275X50F0 Y330X50F0 Y330X180F0 Y330X180F0 Y385X50F0 Y385X330F0 Y275X290F0 Y330X290F0" in the position of the second (it disregards the "<" and "[" as it cannot stamp those characters), then continues to try to stamp the data for that job according to the previous job's format (as it read in this job's formatting as part of the previous job's data).

As far as the quasi XON/XOFF variant, I think that's stty options ixon ixany, if I'm reading man stty right.

The buffer overflow occurs on the plate embosser, reads "BUF OFW" to be exact, and only occurs if I disable flow control entirely (-ixon -ixoff -ixany -ctrscts) on a job longer than ~10 tags, in which it does that whole looping through the same ~6 thing mentioned previously.

The machine in question is a Matica C400 FWIW, it's meant primarily for military-style dog tags, though I'm using it for larger ID tags (about credit card sized) that are a bit more data dense.
 
Old 10-14-2010, 10:39 AM   #7
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,396
Blog Entries: 2

Rep: Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908
Well, it seems clear that the problem is a matter of flow control. Given that a Windows serial terminal was able to get it right, I doubt that it is very complex. I assume the same cable and connector configuration was used on that test as you are using now? My sense is that the device is using hardware flow control, and the cable is not wired appropriately, but this theory doesn't seem to hold if it works in another OS with everything else identical. Have you tried cdtrdsr flow control?

--- rod.
 
Old 11-18-2010, 07:00 AM   #8
Schadrach
LQ Newbie
 
Registered: Dec 2007
Posts: 10

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by theNbomr View Post
Well, it seems clear that the problem is a matter of flow control. Given that a Windows serial terminal was able to get it right, I doubt that it is very complex. I assume the same cable and connector configuration was used on that test as you are using now? My sense is that the device is using hardware flow control, and the cable is not wired appropriately, but this theory doesn't seem to hold if it works in another OS with everything else identical. Have you tried cdtrdsr flow control?

--- rod.
I did try cdtrdsr after you had mentioned it, which didn't help. However I had a very weird ultimate result. I started up statserial to see if I could tell what the port is actually trying to use (see if/which flow control pins were changing).

Interestingly, it appears as though it's using ctrscts as far as watching statserial, but even more strangely, while statserial is running, and only while statserial is running, it works perfectly.

I have no idea why that could even be, doesn't statserial just monitor the port status?
 
Old 11-18-2010, 12:49 PM   #9
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,396
Blog Entries: 2

Rep: Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908
I've never used (or heard of) statserial. If it does reveal information about flow control mechanisms, that should be very useful, although one would hope that it could do so without affecting the measurement (theNbomrs' first rule of T&M: do no harm). I have used, with some success, a tool called serlook. Maybe that provides some help. At least you've been able to confirm that your cabling is capable of supporting a successful transfer.

--- rod.
 
Old 11-19-2010, 07:38 AM   #10
Schadrach
LQ Newbie
 
Registered: Dec 2007
Posts: 10

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by theNbomr View Post
I've never used (or heard of) statserial. If it does reveal information about flow control mechanisms, that should be very useful, although one would hope that it could do so without affecting the measurement (theNbomrs' first rule of T&M: do no harm). I have used, with some success, a tool called serlook. Maybe that provides some help. At least you've been able to confirm that your cabling is capable of supporting a successful transfer.

--- rod.
Ubuntu manpage for statserial: http://manpages.ubuntu.com/manpages/...tserial.1.html

That's really all I know about it, aside from it being one of the first results when I Googled for a way to monitor serial status pins on linux. It must be doing *something* beyond simply monitoring though, but I have no idea what.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
how to transfer and receive file using serial port from my application amit_pansuria Programming 5 06-14-2007 06:27 PM
Source code for file transfer over serial port. nethunter Linux - Networking 2 09-01-2006 03:35 PM
file transfer over serial port. nethunter Linux - Networking 2 02-26-2006 07:54 AM
Serial port transfer tklima Programming 1 01-12-2005 03:13 PM


All times are GMT -5. The time now is 02:54 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration