Establish TCP connection in SIT framework

[DinaDemara]

I am using LabVIEW 8.6 with Simulation Interface Toolkit (SIT) running a model on PXI.  I need to establish communications between host and driver that are unrelated to the Model.  I am having issues establishing a TCP connection.  I have tried 3 different port addresses (6342, 7342 and 55555), carefully avoiding 6011. IP address (on driver side) is the address for the host PC.   I used TCP Communicator - Active.vi and TCP Communicator - Passive.vi as examples.  The Host vi (Passive side) hangs at TCP Listen, waiting for connection.  If I run the Driver vi along with "TCP Communicator - Passive.vi", communications are established.  Is there something SIT is doing on the host side that is preventing this communication?

[Aldo_A]

Hi DinaDemara,

You should be able to use SIT and communicate via TCP.

1. Make sure that you are performing your TCP functionality outside of the control loop in SIT. Preferably, implement your TCP functionality in a separate VI outside of the SIT control loop.

2. I highly recommend for you to use the two NI Example Finder VIs called Simple Data Client.vi and Simple Data Server.vi to test your network. After you get these two VIs to communicate successfully, adapt them to your application.

3. Turn off all firewalls to test.

Let me know if you are still having problems.

[DinaDemara]

This doesn't work either, with the identical symptoms.

1) Simple Data Client.vi and Simple Data Server.vi with Client deployed to PXI and Server running on localhost communicates fine,

2) Add Simple Data Client as a call from top level driver (PXI) code not in sequence with any of the other code, just independently floating on the diagram  Run driver code.  Run Simple Data Server.vi on host.  This communicates fine.

3) Add Simple Data Server as call from top level host.  This automatically deploys driver.  Server hangs waiting for listen.

[Aldo_A]

Hi DinaDemara,

Thanks for the update. From your description, I believe the behavior is expected since the SIT driver contains the control loop and introducing TCP communication at that level will cause unexpected behavior (TCP comm is not deterministic). Is there a reason why (2) is not acceptable for your application?

[DinaDemara]

I need to be able to run the SIT generated (and subsequently modified) host code in order to monitor and control the model execution.  I checked step 2 just as an intermediate point to be able to ensure that at least one side worked.

[Aldo_A]

Hi DinaDemara,

We recommend that you don't alter the SIT driver code because introducing new routines will cause weird behavior and introduce issues such as the one you are seeing. My suggestion is to try the (2) approach where TCP comm is independent from the SIT driver. I understand that will require some re-architecture of the code (communication between processes) but it sounds like this is going to be the best option.