Simple TCP Messaging (STM)

[Doug_S]

Post your questions or feedback on the Simple TCP Messaging (STM)  component here.

[Auden]

I have a question:

I have a setup where I am going to be using an NI cRIO-9012 controller, which will be the server.

The controller is to receive TCP/IP messages via the ethernet port from a computer that will NOT use LabVIEW or have anything to do with LabVIEW.

can a VI using STM be used as a TCP/IP server when the client computer does not use STM but jsut the "standard" TCP/IP?

Any tutorial or example you may be able to point me to?

Much thanks

[Doug_S]

This is a question that comes up occasionally. 

The two main issues are

• Converting LabVIEW data structures to C (or whatever) format
• Implementing the STM protocol in a text based language

We have put some effort into solutions for this use case. For example, there was an early version of the simple messaging protocol for Windows and LVRT for PXI and 900x controllers that converted LV data structures to XML for compatibility with non-LV targets.  This approach had some challenges, however.  It required the user to build an XML-capable client or server component.  Over time, new LV targets (PDA, Linux and VxWorks,including the 9012) have been released that do not support XML, so it has been replaced in STM with LV "flatten to string", which is more widely supported.

We do not have a C version of STM, but that would be a nice project for someone when we agree to a solution to the first problem. 

In the meantime, here is a white paper we wrote several years ago that discusses the low-level issues and provides some examples for implementing a messaging protocol directly on top of TCP/IP for heterogeneous systems.  The examples are for LV <=> LW/CVI, but it should cover most of the issues with other targets.  As of this writing, the code download and reference links are live.

Doug

Message Edited by Doug S on 09-20-2007 02:48 PM

[dtraxler]

This is a good library, and should be LabVIEW "standard equipment".

One thing that is missing is more documentation. I see the connections for "Properties" to the connection manager vi (and others) but...don't...quite...get...it...

There is also (I believe) a bug in STM Multi-client Example - Server.vi: In my application, if I let one of the loops write when there are no connections, it never worked again.

David

[Doug_S]

David

The connection properties feature allows you to store persistent state information (active channel, for example) or other connection properties in the Connection Manager VI.  In the Multi-client Example VI, the Active Channel property is used to select the data that is returned to each client.  Connection properties work by storing one or more properties in the connection manager along with each connection reference.  Each client can send a command to set its own properties.  The server Command Parser loop stores the property value  (the Active Channel number in this case) in the connection manager VI.  The medium priority tasks loop retrieves the properties for all connections from the connection manager and uses them to decide how to service each connection.  In the example, it uses the active channel values to index the data to be sent to each connected client.  The properties data type is a cluster typedef, so you can customize it according to your application requirements. 

I was not able to recreate the server behavior that you described.  If you run the example client VI without first running the server, TCP Open Connection will return an error, which causes the client to terminate.  In the server, all STM writes are done in the Medium Priority Tasks loop. The Medium Priority loop is designed to only service active connections, which should prevent any writes from happening until a client connection exists.

Doug

[dtraxler]

Got it.

Modify the typedef then it can contain anything appropriate for the application. Very handy.

As for the problem I mentioned, it may be related to another issue that came up at the same time.

The application I am working on runs on a PXI system, running LVRT, and I noticed that with my project open, and the STM examples open and running, occasionally LV would lose contact with with the PXI. Don't have any more information on that.

Thanks

David

[Lucy]

I'm converting to this method from network published Shared Variables mainly because my CRIO systems will be deployed around the world and I am not happy that I will be able to deploy the variables remotely without Labview Project Explorer installed on the local PC.  I'll be supporting the systems remotely by taking control of the local PC (system GUI)  through a modem or network link. Also I don't have much space left on my 9012 so need to remove the Shared Variable Engine from the CRIO. I am already handshaking & compressing the data to get the bandwidth I need.

My question is that the latest Command Based Architecture example uses shared variable instead of globals. These are not network published, and configured as target relative with RT fifo option. Can I leave these shared variables in or will they still need to be deployed the same as the network published? Would it be safer too use traditional globals and RT fifo vi's.

I found the multi-client server design document easy to follow, but cannot find the examples.

Thanks

Lucy

[Doug_S]

I don't believe that any of the examples included with the STM component use shared variables.  The command-based architecture as been around for several years and has been adapted by a number of content authors for other use cases.  If you can point me to the shared variable example I may be able to clarify what you are seeing.

Component examples install to the <lvdir>\examples folder.  The multi-client/server example can be found in <lvdir>\STM\Multi-clientServer

Doug

[Lucy]

The example I found was in the shipped RT examples -  \LabVIEW 8.5\examples\Real-Time\RT Network Communication\Command Based Architecture  The RT part uses local shared variables.

I still need an answer to the shared variable question - moving to this method and removing network shared variables - should I stop using shared variables completely because of engine size/ deployment issues? Its not just the ones in the example, I was using them already. Perhaps I should post on a different thread?

Thanks I found the STM examples within minutes of posting. Like the previous discussion in this thread, I've puzzled a bit about the properties, but can see they would be useful for controlling data streams. Also I've been thinking about the Meta-data. I understand about naming the comms, but is it necessary to dynamically set the metadata upon connection as this bit is already specific to the project and not generic.

Yet another sub-question: Are examples available using added security and performance measurements with this architecture. The systems are monitoring production continuously and I cannot afford for the comms to fall over! I need to balance good GUI refresh rate with a balanced TCP/IP data flow.

Thanks

Lucy

[Doug_S]

That shipping example appears to be based on an earlier version of the STM example code that was included with the shipping examples for LV 7.x.  The SVs were probably added to the shipping example when they were introduced in LV 8.0.  The latest STM examples do not use shared variables.  Sorry about the confusion.

The general rule is to use SVs wherever they make sense.  STM was created as a high-performance TCP/IP protocol (before SVs existed), and continues to be used as an alternative to SVs in applications that require performance over ease of use.  FYI-  It is possible to create applications (even executables) that deploy SVs programatically.   Specific questions about SVs should probably be posted to a SV-related thread.

Were you thinking about secure sockets, encryption, or some other method of security?  If you could also elaborate on performance metrics that are important (throughput, latency, . .. ) , that would be helpful.  The STM examples do not include either of these capabilities.

Doug.