TCP Error 61

[stars_n_moons22]

Hi Everyone!

I am running two Labview exes on a server PC. These two exes are communicating with different bits of hardware over TCP Connections.

I am having problems with one of the executables TCP Connection to a printer.

I will be able to send commands from the exe to the printer to print labels for hours on end and then suddenly I get an error saying that the label failed to print. (I don't log that specific TCP error at the moment.)

At this point usually, several other printers running from this exe will all experience the same problem and stop printing.

If I close down and then restart the exe that deals with those printers, I get a TCP Error 61 when I do an initial startup connection to a MySQL Database that I am using. The error is described as Serial port parity error or The System could not allocate the necessary memory. I'm not sure whether to believe this error or not since the PC has plenty enough memory.

But this means that my exe will not even startup.

If I close both the exes that are communicating over TCP and restart them, I get no errors and my printers start printing labels again.

After this had happened a couple of times, several hours apart, I was a bit flummoxed as to the root of the problem.

So, Great Labview Gurus, do you think that this problem is:

1. more likely to be caused by something happening in the program (BTW The printing code has been used for over a year with no changes and this is the first time I've seen this problem) or

2. a strange memory error on the PC or

3. some other funny thing happening on the network when my printer first reports an error or

4. Something completely different

Many thanks in advance for any help or advice!

Sam

Labview 7.1.1

MySQL DB 4.1.16

Windows Server 2003

[Louis Manfredi]

Hi Sam:

Welcome to the forum!

I've had a slightly similar problem communicating with a proprietary instrument over TCP. My client's instrument uses a postage-stamp size "web widget" purchased off-the-shelf from another vendor to handle all his TCP traffic. The firmware for that widget seems to have a bug-- If my Labview program opens a connection to the widget ten times, it will crash on the eleventh connection with a TCP error. Seems that the widget can only have ten tcp processes open at once, which shouldn't be a problem, except that when my program sends the message to close the TCP session, the widget ignores the message and leaves the session open. Cycling power to the widget is an effective work-around.

Perhaps you've got something similar going on? Has the printer firmware changed-- either because of a hardware change, because of a firmware update which you know about, or perhaps even a firmware update that happened automatically behind your back? (Not to be paranoid, but if something is connected to the 'net, and keeps its firmware in flash, it is possible that the manufacturer updated the firmware without telling you....)

Not at all sure my experience is at all relevant to your problem, but for what its worth....

Best Regards, Louis

[stars_n_moons22]

Hi Louis,

Thanks for the welcome note, I've been a lurker for a while but not posted before.

Thanks for the lead on the Printer flash firmware, I'll look into that. I don't think they update themselves but since I don't control them I'm not sure how they do it so it's good to be a bit paranoid under the circumstances!

As for the TCP connections build up, each time I connect to one of the printers, I open the TCP Connection, squirt the data down the line and then use the TCP Close connection.

I guess that the printer might not have closed it's connection properly but then the next time I tried to connect to it wouldn't I have got an Error 66 - The network connection closed by the peer? Also why would the refusal of a connection by 1 printer cascade down to all my other printers?

Could this have been caused by some kind of distruption on the network which would mean that the printers never saw me close the TCP Connections and so would not allow me to connect again (Assuming that they only allow 1 TCP Connection at a time)?

Thanks very much for your kind help - it's been very useful

Sam

[Tom Limerkens]

Do you keep your TCP connection to the printers open?

Or is it closed each time something is sent to the Printer?

I once had the same kind of problem when all the TCP ports

at the server side wer in the 'CLOSE_WAIT' state.

This was the result when the Server application communicated with

a slave every 1.5 seconds, and opened and closed the TCP connection

each time. Because I did not specify the 'Server side' port, LabVIEW chooses the next

free port.

But because the previous port was still in the 'CLOSE_WAIT' state, Labview

alocated a new one, and within a few hours no port was free anymore.

Specifying which port is to be used by the 'Open TCP socket' solved the problem.

Don't know the if this is could cause the error 61 though.

Maybe there has been an increase in the number of printjobs?

Did you ever ran netstat when the printserver hung ?

("netstat -a" in command prompt to view all open socket connections.)

Another interesting tool to analyse network traffic : packetyzer.

Success, Tom

[Louis Manfredi]

As for the TCP connections build up, each time I connect to one of the printers, I open the TCP Connection, squirt the data down the line and then use the TCP Close connection. ...

...wouldn't I have got an Error 66 -...

Sam

Hi Sam:

-- I did it that way on my first pass of the program I mentioned, and it crashed after 10 packets of data. So I changed my program to only do TCP Close connection when it was completely done. After that, it would only crash after ten runs of my program.

-- To be honest, can't recall exactly which error I get when this happens (don't have the client's hardware here to try) might well have been an error 65 rather than an error 61.

-- As I said, not at all sure my experience is at all relevant to your problem, but it does sound at least a little similar.

Best Regards, Louis

[stars_n_moons22]

Thanks for the input Tom and Louis.

To answer your questions Tom, I am opening and closing the TCP connections each time I send something to the printer.

Also, there aren't more printjobs but there seems to be alot more network traffic than previously and I haven't tried to monitor the number of socket connections using netstat only the number of socket connections on my MySQL database. - BUT I will definately be monitoring them now!

From what you have both said i think one of two things might be happening.

1. As I open a seperate TCP connection and port each time I connect to my printer, I end up using too many ports and no more ports can be allocated so I can't communicate to the printers anymore until I clear out all the unused ports by restarting my apps.

OR

2. On one call to the printer, I fail to close the TCP Connection succesfully to the printer so the next time I try to connect to the printer, it throws me out as it thinks it already has a connection established waiting to be used.

I think that this might be more likely as there has been a rewiring of the network recently and from other projects in the same area, it looks like one side of the network (including where my printers are) is getting completely overloaded at certain points of the day. I think that when one of these overloads happens, it interferes with closing the TCP Connection to the printers and stops me from establishing any new connections.

I think my next stop will be to monitor all the socket connections using netstat and also to try to check out all the network traffic with packetyzer and try and see what exactly is happening with the TCP connections when this happens again.

Then I will probably think about how I could manage keeping the TCP connection to the printers open all the time rather than opening and closing each time.

Thanks to both of you for all your help and relating your similar experiences - it's been invaluable in getting my little grey cells working in the right direction! (And has saved me from another day of and :headbang: !)

Cheers!

Sam