From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Components

cancel
Showing results for 
Search instead for 
Did you mean: 

Simple TCP Messaging (STM)

Hi Ecosse1 ,

please have a look at this link to learn more about STM theory of operation: http://www.ni.com/white-paper/4095/en/
Write meta data function will have to send to the client the commands that the server will be able to execute. In your case: "frequency" and "power". In order to be properly decoded on the client side, you have to send the array of commands in the same way LabVIEW stores an array of strings in memory: first 4 bytes specifies the length of the array - in your case is 2. Then another 4 bytes for the length of each element followed by the strings. So you will have: 0x0000 0002 (length of the array) 0x0000 0009 (length of the first element - 'frequency') 0x6672 65717 5656E 6379 (first element - 'frequency' in hex) 0x0000 0005 (length of the second element) 0x706F 7765 72 (second element - 'power' in hex). As all messages on TCP must contain the data size specified on 4 bytes in the beginning of the message, you will have to add this before sending. So for the previously calculated command, the size is 26 (decimal) = 0x0000 001A(hex). Your complete data packet will then be:
0000 001A 0000 0002 0000 0009 6672 6571 7565 6E63 7900 0000 0570 6F77 6572.
If this message is successfully sent, the client will now know that the server supports 2 commands that will be encoded as meta data as 0x0000 for frequency and 0x0001 for power so each time a command is received by the server, you will have to check the 5th and 6th byte in the packet to see if it is a 'frequency' or a 'power' command.
I hope this helps!

Lucian
CLA
0 Kudos
Message 141 of 174
(3,675 Views)

It's also worth noting that there are some existing examples for implementing STM from C.  The object-oriented one is only a client and it's pretty specific to the MSVC++ network stack, but the CVI one is a bit more general.

 

http://www.ni.com/example/31208/en/

http://www.ni.com/example/31227/en/

0 Kudos
Message 142 of 174
(3,666 Views)

Thanks, LucianM, for the good example. It makes amore sense to me now.

0 Kudos
Message 143 of 174
(3,656 Views)

Hi STM Community,

 

A point of feedback about the STM API:

 

In the Simple Messaging Reference library, the STM Get Connection VI always requires an index to establish a desired connection. However, this mechanism does not lend itself well if the program needs to add/delete connections on-the-fly. Specifically, it takes some work to determine the next correct index. As a work around, the user can use a property node and set a connection "Name" to search on. What I would like to see is a name/index polymorphic input instead, as well as a distinct VI to 'Get Properties'.  This would enable the program to retrieve properties necessary for the Get Connection VI to be used on-the-fly without explicit knowledge of the name/index.

0 Kudos
Message 144 of 174
(3,633 Views)

We are using the STM in a multiple client/single server type application. The design of our system will be to interface with external applications running under C#. In order to interface with these other programming languages their code must  be written such that the TCP data both to and from the STM server is properly formatted. I am looking for any information detailing the data format for the TCP protocol pertaining to the STM. (I.E. if we hookup a packet sniffer, such as wireshark, what data would we expect to see if properly formatted) We need  to specify the requirements for the developers to code their application to int4erface with out LabVIEw program.

0 Kudos
Message 145 of 174
(3,488 Views)

Information about the STM packet format is provided in http://www.ni.com/white-paper/4095/en/

 

 

In short, each packet is made up of a 6 byte header, containing a 4-byte length field, and 2-byte data ID, followed by the data payload. The structure of the data payload is not defined by STM.

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


  
Message 146 of 174
(3,480 Views)

Christian is entirely right, however there might be some confusion caused by the STM examples, which often transfer LabVIEW flattened data as the payload of the message.  If what you're really looking for is the description of LabVIEW flattened data you can find that in the LabVIEW help or here:

http://zone.ni.com/reference/en-XX/help/371361N-01/lvconcepts/flattened_data/

If you haven't already, it's also worth checking out this example:

http://www.ni.com/example/31208/en/

It already has C++ implementations of a number of the flattened data type conversions, converting that to C# should be a easier than starting from scratch.

Message 147 of 174
(3,460 Views)

Hello,

I am trying to make communication between Two LabVIEW(Version 10 & Version 14) application through TCP\IP(Using STM)

I am sending cluster(Inc.Variant and String Control) from  LabVIEW14 To LabVIEW 10 over TCP\IP. In this case everything work fine but when I include German Char Ex. Ü or Ö. there is error like 'Error 74 occurred at Unflatten from String.' at Client Side

Additional, As my opinion  it is because  NI STM.ivlib:Write Message(TCP)  API use flatten to string instead of VariantFlattenExp.vi (http://digital.ni.com/public.nsf/allkb/45E2D7BE36CE3E8B86257CCF0074D89B).

Anyone has idea what to do with it ?

NOTE: Same Communication between LabVIEW10 and LabVIEW 11 work fine even If I send (Ü, Ö,)

Kuddo welcomed
CLAD-CTD
0 Kudos
Message 148 of 174
(3,389 Views)

Hello Gab008,

 

can you show me your code , to how you did this ?

 

or just the beginning of how i am gonna be  start ..

0 Kudos
Message 149 of 174
(3,003 Views)

its solved and reason is upgradation of the STM library.

Kuddo welcomed
CLAD-CTD
0 Kudos
Message 150 of 174
(2,969 Views)