Components

cancel
Showing results for 
Search instead for 
Did you mean: 

Simple TCP Messaging (STM)

Vincent,

 

Can you describe your hardware and network setup in more detail, please. When you see two acknowledges for the same command, do they come from the same IP address? Do you have any dual or redundant networks in your setup?

 

I tested these examples here and they only receive one command in the normal case. I tested both running on the same laptop, as well as the Command Brodcast running on the laptop, and the Listen and Acknowledge running on a cRIO.

 

I can also run the Listen and Acknowledge on both laptop and cRIO at the same time, in which case each receive the command once, but of course there are two separate acknowledges.

 

Which version of STM are you using? The latest version 3.0.0.6 is avaible on VIPM.

authored by
Christian L, CLA
Systems Engineering Manager - Automotive and Transportation
NI - Austin, TX


  
0 Kudos
Message 91 of 174
(5,884 Views)

Hello,


I have been using STM along with CCC, CVT, and ACM to implement messaging and data from a real time target to a PC HMI.

I have always had trouble with losing my connection and have improved it over the last few months, However I still am disconnecting regularly from my STM read from RT connection.

 

After looking over the STM examples in the example finder I think I have the right idea, the difference is none of these examples will reconnect automatically so I have tried to implement a mechanism to kill the connection and get a new one if the connection fails.

 

This is on a dedicated network with around 15 different devices ranging from PLC IO to scanners and several PCs.

 

I was hoping someone with a lot of experience could take a look and see if there is anything obvious I am missing. The server (RT) side stays online and "connected" but the client will drop out. If I kill the TCP connection on error the RT side doesnt know, but the client will not reconnect to the same socket anymore.

 

Any ideas?

 

Thanks,

Eric T

0 Kudos
Message 92 of 174
(5,754 Views)

I don't know if this is related to your issue, but it was a problem I had with STM that took me over 2 weeks to figure out.

 

I have multiple EXE programs talking to each other on the same PC over localhost (127.0.0.1) using STM.  The system is modular and runs multiple test head (up to 16) with up to 4 EXEs dedicated to each test head (up to 46 EXEs running at the same time).  At startup, the user can decide how many test heads are to be used.  It ran fine if the number of test heads was below 12, but as soon as you try to start the system using 13 test heads or more, we would get TCP "drops" and lost connections. 

 

I spent over two weeks trying to track down the problem, thinking there was some type of TCP buffer overflow or something (since everything was on localhost).  I was about to call NI and remembered from past calls to them, the first thing they would always ask me is , "Are you starving your processor".  Now I THOUGHT there was no way this was an issue as a had two quad-core processors on my motherboard (total of 8 physical cores) running at over 3GHz, BUT decided to monitor their usage at start-up just so I had data to prove to NI that it was not a processor issue.  To my surprise, I discovered I was STARVING THE PROCESSORS AT STARTUP.  The processor would reach 100% usage when I tried to launch all 64 applications at the same time.  So the LV startup process (which I have no control over) would starve the processors and the TCP would not connect because one or more applications were not available. 

 

To resolve the issue, I put in a processor monitor and a delay in the main server.  Now before ANY client EXE is started, the Server checks the processor usage and, it is above 45%, it waits 10 seconds before starting up a client EXE.  This staggers the startups of all the EXEs and now everything works without issue.

 

I don't know if this is what your issue is, but you should at least confirm you are not starving any of your processors on your system when initializing/running your STM code.

Message 93 of 174
(5,747 Views)

Hi MTRU, Thanks for the quick response.

 

 

I went ahead and monitored the HMIs resources and the communications didnt take a dent out the processor. none of my 4 cores go above 10% during startup or shutdown. My memory is well used (6/8 gigs) but doesnt take a hit during startup and doesnt increase over time.

 

It is worth noting that the connection works on startup but will fail eventually or when the HMI is reset. My ideal response would be that the CRIO acts as a headless control system and keeps the server connections waiting even when the HMI is shutdown.

 

My workaround is just to reset the CRIO programmatically but this just doesnt seem like the best way to go about this. 

 

Thanks,

Eric T

 

 

0 Kudos
Message 94 of 174
(5,739 Views)

Eric,

 

I'm sorry (and glad) to hear you do not have any processor issues with your system.  Intermittent network communication issues are such a bear to track down and rectify, I wish you all the best in finding a solution!

0 Kudos
Message 95 of 174
(5,735 Views)

Hi Eric, 

 

In your VI: "Read Message from cRIO", you're not handling any errors returned from the Read Mesage VI. You are simply clearing them, which does not resolve the issue. If there is a connection failure, there should be an error returned from STM Read VI (depending on the type of connection error). Typical errors are 62,64 and 66. See the screenshot below for an example implementation of error handling. When I connection error occurs, I close the connection and attempt to reconnect. 

 

STM Issue.PNG

 

 

Julianne K
Systems Engineer, Embedded Systems
Certified LabVIEW Architect, Certified LabVIEW Embedded Systems Developer
National Instruments
0 Kudos
Message 96 of 174
(5,726 Views)

Hello and Thanks,

 

So my error is always error 66. So I close down the tcp connection and try to open a new one. I have implemented error handling as you show above but the response is the same, if it is an expected error, close tcp and start new one. What could be the reason my connection will not reconnect? a socket open, or because the server still thinks the original tcp socket is open?

 

Eric

0 Kudos
Message 97 of 174
(5,720 Views)

How is your server implemented? Another LabVIEW implementation? Does it allow more than one simultanous connection? Does your server implement proper error handliing, terminate any cnnection that returns any error other than timeout on Wait on Listener?

 

Error 66 is returned by the TCP nodes when the remote side actively has closed down the connection by calling TCP Close. Basically when you properly close down a connection and reopen it and don't get an error from TCP Open but then get error 66 from either TCP Read or TCP Write, this means your server has decided for some reasons that the connection is not desired and has closed it down. So you will need to tell us a lot more about how your application handles connections and where you see error 66 exactly.

 

Rolf Kalbermatter
My Blog
0 Kudos
Message 98 of 174
(5,717 Views)

Hello.

 

I have attached the original files above. 

 

My server is implemented very similar to the CRIO developers guide best practices. once started it connects immediately once the HMI is started. It never throws any errors even when the HMI disconnects. I guess I should expect this since it is the server. Here is a snapshot.

RT.JPG

On the HMI side, I also immediately connect to the server and everything is fine. Once the connection is restarted though I get error 66 (not 56 like I said previously) which states that the Meta Data is incorrect or missing.

 

HMI.JPG

When the HMI reconnects or is restarted this connection no longer works until I also restart the RT. I think that the RT is still looking for the original connection, and cannot connect to a newer one, but im not sure how I am supposed to handle a scenario like this. I have been unable to find an example where a programmatic reconnect happens.

 

Otherwise, I believe this connection only allows one client connection, but I also have several other data connections, a write to HMI connection, A high speed data stream, and the CCC tag connection. All other connections currently self repair when the HMI is restarted.

 

So in conclusion I only recieve error 66 when I restart my client connection and my current method is to clear error 66, close tcp connection and restart a new connection. The new connection will not connect to the server, I am using the same IP and port names for the new connection as the old one.

 

Is this better information?

 

Eric

0 Kudos
Message 99 of 174
(5,709 Views)

Hello,

 

MTRU had it right, troubleshooting this stuff sucks.

 

I was never able to get the reconnect to work well, but I have been able increase the reliability quite a bit.

 

Thanks for the help everyone,


Eric T

0 Kudos
Message 100 of 174
(5,678 Views)