06-01-2012 06:31 AM
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
06-04-2012 02:57 PM
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!
10-04-2012 08:17 AM
@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?
10-05-2012 09:22 AM
01-19-2013 11:03 AM
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
01-20-2013 08:45 AM
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.
11-25-2013 09:35 AM
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/
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....
11-25-2013 10:03 AM
Summary of my thoughts on the topic:
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!
11-25-2013 10:04 AM
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).
01-29-2014 04:30 PM
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