LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TCP error 57

I'm getting error 57 from a TCP Write, sporadically. I can believe that it might have overlapped with another such call from another part of the program. But I'm reading the documentation for TCP, and it just isn't very explicit about this whole subject.

 

I'm hoping someone can enlighten me. Once I call TCP Write, what has to be true before I can call it again from another portion of code? Just that it returns?

Would a Semaphore be a good way of protecting this, or would it be unreasonably time-consuming to lock and unlock every time?

 

Once I get into this state, there doesn't seem to be any easy way to get out of it. Any further calls return the same error message. Is there some way to break out of this situation, to clean things up without terminating and reopening the connection?  In one of the related posts I read something about timeouts, but I'm not sure how that applies.

 

0 Kudos
Message 1 of 7
(2,495 Views)

Are you trying to have multiple places in your code communicate to the same device?  If that is the case, then I would go with a Queued Message Handler set up.  This way the QMH will take care of the communications and the queue will force the different parts to behave.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 7
(2,486 Views)

This should not backup unless you are having the TCP listener disconnect due to network issues?  Any timeout should be long enough for the TCP write buffer to empty enough for your message.  The fact that it seems to permanently lock up shows a disconnection issue.

 

You might want to detect this, close the connection and other references and then re-open it.  There are some "Robust TCP/IP" VIs that I believe David Moore wrote that are a good starting point for a reliable connection.  Download them from the JKI VI Package Manager and take a look at that structure.  It is designed to handle disconnects and reconnects.  I based some fairly robust code on those.

LabVIEW ChampionLabVIEW Channel Wires

0 Kudos
Message 3 of 7
(2,482 Views)

@sth wrote:

You might want to detect this, close the connection and other references and then re-open it.  There are some "Robust TCP/IP" VIs that I believe David Moore wrote that are a good starting point for a reliable connection.  Download them from the JKI VI Package Manager and take a look at that structure.  It is designed to handle disconnects and reconnects.  I based some fairly robust code on those.


Where is the package for that?  I would really like to look at it, but I'm not able to find it anywhere.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 4 of 7
(2,473 Views)

My very bad misattribution.  I apologize a lot to Jack Hamilton another old time programmer who actually made the "Robust TCP/IP" VIs.  They are quite old but TCP/IP hasn't changed much.  

 

http://www.labuseful.com/plugins.html#tcp

 

LabVIEW ChampionLabVIEW Channel Wires

0 Kudos
Message 5 of 7
(2,417 Views)

Hi Joymaker,

Before using the synchronization functions such as semaphores ,i have some basic questions for you.

Question#1)Are you writing any fixed length data to TCP Write.vi in all places in your code ?

 

Question#2)Did you wire any timeout to that VI (please note that default timeout is 25 msec )? If the data is taking more time  ,then the TCP Write.vi will be busy and it wont allow any other writes to same port.

 

Unfortunately 'Robust TCP/IP" VIs are too old to be loaded in LabVIEW (atleast in 2017 version)

 

Regards,
Srikrishna


0 Kudos
Message 6 of 7
(2,407 Views)

@srikrishnaNF wrote:

Unfortunately 'Robust TCP/IP" VIs are too old to be loaded in LabVIEW (atleast in 2017 version)


Mass compiled in 8.2.1, which you can open with anything newer.  I haven't looked at the code enough to make an opinion on it.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 7 of 7
(2,402 Views)