Simple TCP Messaging (STM)

[Scott_Campbell]

I found were the issue was and have it resolved.  Critical to have timeouts in receive loop set to 0 🙂

[David-Baratheon]

Hi all,

I want to send a letter from a terminal on windows to a sbRIO-9651 and vice versa. 

I believe Simple TCP Messaging (STM) may be the solution I am looking for.

Can anyone recommend a good terminal program that is free (hyper terminal costs money) and recommend a tutorial for setting up the STM communication?

Also, do I need to use a cross over ethernet cable?

[ryank]

Hi there, terminals communicating over an Ethernet connection usually communicate over the Telnet protocol.  Telnet is a somewhat antiquated protocol, and so you won't find a lot of support for it anymore.  If I remember right you can still get a LabVIEW library for it by downloading the Internet Toolkit (http://www.ni.com/download/labview-internet-toolkit-2012/3122/en/) and porting it into whatever version of LabVIEW you are using (which just involves copying the library and opening it in the newer version).

I use Tera Term as my terminal program on Windows, which was still free last I checked.

STM is a protocol developed by National Instruments, and therefore no off-the-shelf program like a terminal is going to speak it.  You could write your own terminal program in LabVIEW that spoke STM and run it as an executable of course.

With modern equipment you ususally don't need cross-over ethernet cables.  Gigabit ethernet ports generally have automatic detection capabilities that will swap the lines (https://en.wikipedia.org/wiki/Medium-dependent_interface#Auto_MDI-X).

[MVidal]

Hi everyone:

I've implemented STM in a machine that gets TCP messages from several devices, it's a kind of central repository. It is based on the "STM Multi-client Example - Server.vi", however adapted to run in a Windows Machine instead an Embedded Device. Everything works great in the lab.

However, at the field, it seems that there is a problem related to its network. Somehow sporadically a message gets truncated (I blame the routers, but that's not important here). So the machine that receives the message keeps waiting for the complete message until the second TCP read inside the "original STM Read function" returns a timeout.

That second timeout is the default 25000 ms of the TCP Read (it can't be changed in the "original STM Read function"). As the devices can send messages at any time, in the event of a truncated message, it is possible (and probable in my scenario) that the receptor device completes a truncated message with data from the next message if that happens during those 25 seconds. Also the remaining data of the message can induce the TCP Read to wait for a really big number leading to that message of "Unavailable resources".

How do you guys manage this cases of incomplete messages? Of course I have to solve that issue with the network, but I would like to go as much as I can on getting a reliable solution. So far, I've thought about this:

• Making a "custom STM Read", to be able to use a lower timeout for the rest of the data after getting the size expected. Ideally it should be zero, so there is no frame for a new message to get its data into the buffer of an incomplete one.
• Implementing a check for a reasonable size for the message could be a good thing, but this device collects messages with sizes between 25 to 500 bytes. And it is always possible to get those values derived from incorrect messages.
• Implementing a check-sum, to avoid the use of corrupted messages.

By the way, I found that the "original STM Read function" is not editable. Is there a way to obtain its source? Far from being lazy, I want to minimize the changes as much as possible.

I really appreciate your guidance.

Thank you in advance. 

[David_Staab]

I heavily edited the library to address this exact issue last year. My fork can be found here: https://github.com/DavidStaab/STMMessaging

And here's further commentary on the issue: https://github.com/NISystemsEngineering/STMMessaging/issues/2

[MVidal]

Thank you David, that's very kind of you sharing this code.

It will take me quite a while to introduce those changes, as it seems I had installed an old and incompatible version of the Library.

Best regards,

Mauricio

[LucianM]

Hello!

I was wondering if anyone else experienced the problem that I have now involving STM on TCP and cRIO(9035). Every time I try to launch the real-time VI from Windows for debugging, I receive error 56 (timeout error) when I try to connect from the UI (which runs on Windows). This happens with my code but also with STM Command Based Communication example. Also, "Waiting for the target to respond" message sometimes appears. However, when RT application is built into an exe, it runs perfectly. I suspected that the port used by me (55555) is used by LabVIEW to preserve communication between front panel and target but I tried with different port numbers with the same result.  Any ideas?

Error is returned by Read Meta Data.vi (options are left to default). Thanks!

[ryank]

I've used STM on the 903x controllers so I can assure you there is nothing systematically wrong there.  A timeout in that case just means that the host can't connect to the RT VI for some reason, some possibilities might be:

1.  You've got a firewall on your host PC that is blocking the ports in quesiton.

2.  Your host PC has multiple NICs (wireless, etc) and the communication is trying  to use the wrong one.  This usually isn't an issue because the TCP primitives default to trying on all NICs, but I have seen cases where it helps to specify the NIC you are using (disabling the others is an easy way to check this).

3.  The IP address that you're connecting to doesn't match the IP address of the target.  Use ping to check the one you're connecting to, etc.

[LucianM]

It seems that it was a firewall issue. Still not clear for me why it was working when RT application is built in exe. I have another application with the same cRIO which uses network streams where I don't have this problem.

Anyway, thanks @ryank!

[Ecosse1]

I am currently looking at STM to implement a LabVIEW Client to C++ Server application. I am not a LabVIEW person so I am currently looking at the C++ end of things. I'm having difficulty understanding exactly what the Write Meta Data command will look like at the Server end. I have two data items, frequency and power, that I wish to be able to control on the Server side.

1. What does the STM Meta Data packet look like at the Server end for two variables?

2. How do I determine that this is an STM Write Meta Data versus an STM Write Message?

3. What does the STM Write Data packet looks like when I wish to change one of these variables?

Your understanding and help is greatly appreciated.