topic Re: Simple TCP Messaging (STM) in Components

Simple TCP Messaging (STM)

Doug_S — Thu, 20 Sep 2007 16:23:42 GMT

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

Re: Simple TCP Messaging (STM)

Auden — Thu, 20 Sep 2007 17:49:10 GMT

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

Re: Simple TCP Messaging (STM)

Doug_S — Thu, 20 Sep 2007 19:29:26 GMT

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

Re: Simple TCP Messaging (STM)

dtraxler — Thu, 18 Oct 2007 22:52:55 GMT

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

Re: Simple TCP Messaging (STM)

Doug_S — Fri, 19 Oct 2007 21:46:09 GMT

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

Re: Simple TCP Messaging (STM)

dtraxler — Tue, 23 Oct 2007 12:52:42 GMT

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

Re: Simple TCP Messaging (STM)

Lucy — Mon, 29 Oct 2007 10:42:53 GMT

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

Re: Simple TCP Messaging (STM)

Doug_S — Mon, 29 Oct 2007 14:32:57 GMT

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

Re: Simple TCP Messaging (STM)

Lucy — Mon, 29 Oct 2007 15:18:49 GMT

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

Re: Simple TCP Messaging (STM)

Doug_S — Tue, 30 Oct 2007 04:37:01 GMT

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.

Re: Simple TCP Messaging (STM)

Garcas — Fri, 04 Jan 2008 16:04:51 GMT

I am developing a DAQ application (just streaming for a fixed period of time since a trigger arrives) that will run in a PXI-8105 embedded controller and use a PXI-6115 DAQ card. The application will operate in a headless configuration receiving commands remotely thorugh a TCP/IP connection to the PXI8105 using a HTTP based protocol.

Someone will develop the remote (client) side in someother language (not LabVIEW), but I have to develop the server side in my application to receive the commands, act as ordered and respond with the data

I wonder if STM can be of any help to develop this HTTP Server or if I should start from zero and use the TCP/IP functions provided with LabVIEW. I am using LabVIEW 8.5

Thanks for your help

Re: Simple TCP Messaging (STM)

Christian_L — Mon, 07 Jan 2008 15:10:07 GMT

Garcas,

If you need to develop an HTTP server you should use the low level TCP/IP functions, and not use STM. STM is a higher level protocol based on TCP/IP, designed to transfer packets of data or commands between two systems. It includes specific header information in each packet that identifies the contents of the packet. Because of this protocol specific content, you can not use it to create the HTTP protocol. In effect STM is in parallel to HTTP, as both protocols are based on TCP/IP.

However, STM is designed specifically for applications like you describe. So if possible, you may want to consider using STM instead of HTTP for your solution. STM is an open protocol and you can implement an STM client in any programming language that supports TCP/IP communication.

Re: Simple TCP Messaging (STM)

Garcas — Mon, 07 Jan 2008 16:24:35 GMT

Thanks Christian, it's what it looked to me but I wanted to be sure I wasn't missing something before starting from scratch. My problem is that using HTTP is an application requirement, so I cannot do anything. Is there anything around so I don't have to start from 0? I read some threads that in the "old" Internet Toolkit there was an HTTP server, but I guess it didn't come with the complete code so I could modify it to my specific needs

Anyhow I think STM it's a great tool... and free ! So congratulations to the authors. I'll definitively copy some ideas

Re: Simple TCP Messaging (STM)

Brian_K. — Wed, 28 May 2008 18:33:30 GMT

I know this question was posted in September 2007, but:

@Auden wrote:
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

I have an example of how to implment a STM client in CVI (ANSI C). It is attached below. What you do is open "STM Example.lvproj" and run the STM Server Example.VI on a real-time target (you will need to change the IP address in the project). Then open the STM for CVI client.cws. Run that example.

Even if you are not using CVI, the STM_Comm.c and STM_Convert.c should be a good starting point.

Re: Simple TCP Messaging (STM)

DirkW — Wed, 29 Oct 2008 17:43:12 GMT

I have a problem with STM to work in my startup EXE running on a cFP 2120 controller. I do not get connection to this EXE. Everything works fine and as expected if i start and deploy it from my LabVIEW development environment. What is the problem with the Executable? Is there anything I need to install on my target system, that is not coming with the Executable?

Any comment is highly appreciated.

DirkW

Re: Simple TCP Messaging (STM)

Christian_L — Tue, 04 Nov 2008 23:10:43 GMT

Dirk,

STM does not require anything special to run in an executbale as it is completely based on TCP and written in LV code.

It sounds like there is an issue establishing a TCP connection to your executable or some other fundamental issue. Can you ping the cFP controller at the IP address that you are using for your TCP connection?

Re: Simple TCP Messaging (STM)

Jack_A. — Wed, 17 Dec 2008 21:07:55 GMT

I am posting a beta version of the next revision of the STM library. Attached below is a .zip file which can be unzipped to the user.lib directory.

The major changes in this version of STM are the additon of serial and UDP as communication mechanisms along with TCP/IP. There are also changes to the API to make the VIs easier to use.

We would like to hear your feedback (regarding either features or bugs) with this version of STM. Please post any feedback on this forum.

Note that the documentation and examples are not yet finished.

Thanks,

Jack

Re: Simple TCP Messaging (STM)

Marc Blumentritt — Mon, 19 Jan 2009 15:30:32 GMT

Hi,

funny thing you posting a beta of a new version of the STM tools, since I just did some small optimizations over christmas on the published STM tools. Some things you changed already, but I have two remarks on the code (s. attachment).

A question: is this version of STM only for LabVIEW 8.5 and newer?

Thanks for your great work.

Regards

Marc

Re: Simple TCP Messaging (STM)

Jack_A. — Fri, 23 Jan 2009 19:46:16 GMT

Hey Marc -

Thanks for the feedback....I've already implemented your recommendations into the next build of STM. It should be on the web soon.

Yes, STM 2.0 will only be supported in LabVIEW 8.5 or later. We will keep the current version of STM on the web if you need to use a previous version of LabVIEW.

-Jack

Re: Simple TCP Messaging (STM)

Marc Blumentritt — Tue, 27 Jan 2009 07:40:24 GMT

Jack A. wrote:
Yes, STM 2.0 will only be supported in LabVIEW 8.5 or later. We will keep the current version of STM on the web if you need to use a previous version of LabVIEW.

OK, than I do have one more small patch (s. attachment).

Oh, and one more idea for you. I would recommend using LabVIEW classes for supporting different communication protocols like TCP, UDP or seriel. I think classes would be more flexible and could be easier extended to other communication methods. Well, just an idea.

Thanks for STM. While it is very simple, it is a powerful tool and I would have never thought about it doing communication this way.

Regards,

Marc