Components

cancel
Showing results for 
Search instead for 
Did you mean: 

Simple TCP Messaging (STM)

I'm doing SBRIO9632 data collection system, communication is the Example, the requirement of STM Command Based Example-Client. Vi and STM Command Based Example-Server (RT). Vi. The server directly download SBRIO9632 inside RT system, however,can't communication

0 Kudos
Message 81 of 174
(7,739 Views)

All, I'm very new to using STM.  The context is the CVT and CCC libraries.  I am trying to start the CCC server and then initialize the CCC client using some example code as a reference.  However, I keep getting a timeout error (error 56) from the STM Read Meta Data (TCP Ref) VI.  Can someone explain what exactly the meta data contains and where it gets written? 

 

I've attached my VIs.  They are very simple, as I'm just trying to get a better understanding of the CVT and what it does. 

 

Had to attach the XML tag file as a text file since xml isn't accepted.

 

Any help would be appreciated.  Much thanks!

Download All
0 Kudos
Message 82 of 174
(7,721 Views)

@crossrulz wrote:

Is there any plan to put the STM into a package so I can install using VIPM?  It would be a great add on to the LabVIEW Tools Network.


I really like using the STM.  But it would be a lot easier to sell to coworkers if it was on the LTN.  Is there any plan to add STM to it?

 


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 83 of 174
(7,584 Views)

crossrulz,

 

Thank you for the feedback. In fact we are in the process of adding several of the popular reference designs including STM to the LVTN.  Please look for it there in a couple of weeks.

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


  
Message 84 of 174
(7,572 Views)

I have an application in which I'm streaming data from a PXI RT target back to a host PC at roughly 0.5Hz.  The data that I'm sending back is typically an array of clusters (some elements are strings), from my benchmarking the data sizes are around 22kbyte for a single packet that gets sent.  The issue I'm running into is that over time, I seem to eventually get a 'Not Enough Memory to complete this operation" error popup in LabVIEW.  And the error popup coincides with the following errors in my code:

 

Timestamp

Source

Code

2013 01 19 05h 57m 40.840s GMT

TCP Get, DataPackets.  STM Read Message (TCP).vi<ERR>Header information was received but the complete message was not received before the specified timeout period.  This generally indicates a poor or broken connection.

Code:  537650

2013 01 19 05h 57m 40.940s GMT

Consumer Loop, Get Pkts.  STM Read Message (TCP).vi<ERR>Header information was received but the complete message was not received before the specified timeout period.  This generally indicates a poor or broken connection.

Code:  537650

2013 01 19 05h 57m 41.596s GMT

TCP Get, DataPackets.  Unflatten From String in STM Read Message (TCP).vi:1->TCP Send Receive - PC.vi->PXI Data Receiver.vi->CSC-205 - Display.vi

Code:  74

2013 01 19 05h 57m 41.696s GMT

Consumer Loop, Get Pkts.  Unflatten From String in STM Read Message (TCP).vi:1->TCP Send Receive - PC.vi->PXI Data Receiver.vi->CSC-205 - Display.vi

Code:  74

2013 01 19 05h 57m 41.897s GMT

TCP Get, DataPackets.  Unflatten From String in STM Read Message (TCP).vi:1->TCP Send Receive - PC.vi->PXI Data Receiver.vi->CSC-205 - Display.vi

Code:  74

2013 01 19 05h 57m 41.997s GMT

Consumer Loop, Get Pkts.  Unflatten From String in STM Read Message (TCP).vi:1->TCP Send Receive - PC.vi->PXI Data Receiver.vi->CSC-205 - Display.vi

Code:  74

2013 01 19 05h 57m 42.697s GMT

TCP Get, DataPackets.  STM Read Message (TCP).vi<ERR>Header information was received but the complete message was not received before the specified timeout period.  This generally indicates a poor or broken connection.

Code:  537650

2013 01 19 05h 57m 42.797s GMT

Consumer Loop, Get Pkts.  STM Read Message (TCP).vi<ERR>Header information was received but the complete message was not received before the specified timeout period.  This generally indicates a poor or broken connection.

Code:  537650

2013 01 19 05h 57m 42.998s GMT

TCP Get, DataPackets.  TCP Read in STM Read Message (TCP).vi:1->TCP Send Receive - PC.vi->PXI Data Receiver.vi->CSC-205 - Display.vi

Code:  2

 

I'm wondering what is causing the partial header and corresponding corrupted data that causes the not enough memory issue to occur.  Am I sending to large of chunks of data?  Are data packets that are being sent from my PXI building up at the PC and then my PC code is trying to convert to large a block of data?  My timeout for the TCP Read that the error 537650 refer to is set to 500ms.  I haven't tried increasing that yet to see if that makes a difference.

 

Any thoughts or insight in appreciated.

Quintin

0 Kudos
Message 85 of 174
(7,450 Views)

The out of memory could be caused if you get an offset in your data stream that causes the STM library to use a random byte for the size (which often results in trying to read a really big message size).  If you roughly know the size of your data it's a good idea to modify the library and put in an upper bound on the message size that throws an error if it get's the wrong size.

 

Of course that begs the question of what is causing you to get that offset in the first place.  It could be a few things, but I think given your situation it's likely you are overflowing one of the buffers at some point, most likely the write buffer on the RT target.  Different targets behave differently when that happens, I know that VxWorks throws an error and that Windows doesn't.  I'm not sure if I ever tested it for Pharlap, but my guess would be that it behaves more like Windows.

 

My suggestion would be to try sending smaller chunks of data, perhaps sending each cluster in the array separately rather than sending the entire array at once.  Assuming the clusters are already reasonably large that shouldn't affect your streaming performance much.

 

You may also need to increase the speed of the reader if it turns out you are overflowing the write buffers.  The best way to do this is probably to take a close look at your data structure and decide if it's the best way of streaming the data.  An array of large clusters with variable sized strings is going to be hammering your memory manager on both sides, and you probably end up doing a lot of indexing and unbundling/rebundling, which can be expensive.

Message 86 of 174
(7,439 Views)

I would like to start a discussion regarding trade offs and guidelines for selection between the various communication options (network shared variables, STM, the cRIO Waveform Reference Library, others?) between an NI RT target (in this case cRIO) and a network.  The network will have mutiple PCs all of which will need to receive monitoring data from the cRIO, and at least one of which will need to write.

 

CompactRIO Waveform Reference Library  http://www.ni.com/example/31206/en/

Simple TCP Messaging (STM)

Network Shared Variables  http://www.ni.com/tutorial/14675/en/

 

Thoughts / contributions?  I have an engineer who will be needing to make these decisions soon and community feedback seems beneficial to engage with....

0 Kudos
Message 87 of 174
(6,817 Views)

Summary of my thoughts on the topic:

 

  • Shared variables - good for broadcasting scalar state data ("The current temperature is X", "I am in run mode", "CPU usage is at 30%", etc).  They are inherently lossy, so using a shared variable for lossless or critical data is unwise.  They are effective at allowing the cRIO to update many clients (subscribers to the variables) without modifying the cRIO's code.  They should not be used to transfer waveform data.
  • STM - good for command-type messaging ("Begin acquisition now", "Configure yourself with these options", etc)
    • Consider Network Streams for this use case as well.  They can be quite effective, since they handle the "connection temporarily disconnected then reconnected" problem in the background
  • cRIO Waveform Reference Library - great for getting data from cRIO modules as a waveform with a clear API.  This is completely separate from how you communicate with the cRIO.  We usually see folks using this in conjunction with one or more other components.

A typical combination would be to use a configuration file on the cRIO's local drive for static configuration, STM (or Network Stream) messages for dynamic configuration and action-oriented messages, and shared variables for broadcast state data.

 

Depending on what kind of monitoring data you need the clients to have, the transport mechanism for getting the data to the clients may be different.  

 

If you just need scalars at <10 Hz, shared variables are the easy option.  If you need full waveforms, consider network streams instead.  

 

If you need arbitrarily many clients pulling arbitrarily large waveform data from the cRIO, consider having the cRIO send its waveform data to a server (using FTP, WebDAV, or network streams) in TDMS format and using Datafinder to index the data and make it available to clients.  This will isolate the cRIO from the load of additional client connections and let the system scale further.

 

Hope this helps!

Cheers,

Matt Pollock
National Instruments
Message 88 of 174
(6,808 Views)

Not sure how many people are subscribed to this thread, so you might be better off creating a new thread to ask your question.  I'd also recommend including more information about the data type and rates that you are communicating as it's impossible to suggest the right mechanism without knowing that.

 

Some quick thoughts:

The cRIO Waveform Acquisition library is primarily geared at getting data from the FPGA to the RT target.  I think there may be some TCP communication in one of the examples for it, but in general it's not really a network communication library.

 

One option you left out are Network Streams.  If all of the targets will be running LabVIEW programs, I'd generally suggest Network Streams over STM.  STM is primarily useful when one of the targets is running something other than LabVIEW (or in some other cases that Network Streams don't support such as Mac/Linux targets).

 

Based on your initial description, I'd say that NPSVs are probably going to be the easiest solution as they are the only one-to-many mechanism on your list.  With multiple PCs connecting to the same cRIO you would need to manage the connections yourself with STM or Network Streams, whereas the SVE will do it for you.  There are plenty of drawbacks to working with NPSVs though, most notably performance (particularly since you would need to host them on the cRIO) and deployability (if you're doing this once they are very easy, if you need to set up multiple similar systems there is some additional work required to set up replication and deployment with NPSVs).

0 Kudos
Message 89 of 174
(6,805 Views)

Hi,

 

I use a subset of STM examples: "UDP Broadcast Commands" and "Listen and Acknowledge Commands".

I don't think I modified examples before testinf, I'm under the impression that I receive 2 times each command.

For instance, take "UDP Broadcast Commands" example, hit button "Configure", on the other side, in example "Listen and Acknowledge Commands", I receive 2 times the "Configure" command (I added a counter and a timestamp to check). It's also TRUE in the other direction, when you see number of time we receive an ACK.

I put Wireshark and there is actually (physically) one frame sent only each time, I'm 100 % sure.

 

For my needs, I had different requirements and I use a MultiCast with Write Only on equivalent of "UDP Broadcast Commands" and a MultiCast UDP Read Only UDP Open on equivalent of "Listen and Acknowledge Commands" and I don't see that effect.

 

So, it's more a feedback and to understand where the issue (I might be wrong).

 

Regards

 

 Vincent

0 Kudos
Message 90 of 174
(6,618 Views)