Data stream from OEM device, TCP/IP "not enough memory"

[acfkt]

Hi Everyone,

I'm trying to catch a data stream from an OEM device over a TCP/IP link.  I can start the data stream, or pause/resume it, but the OEM device determines when the data stream has ended.  The data stream begins, and within 20 seconds, I get the famed "not enough memory" error.  Once this happens, data is lost from the stream, and quite often the final message indicating completion is missed.  I see two solutions to this.  1) Watch how many bytes are backed up on my TCP/IP port, and issue a pause command until I can process the backed up bytes at which point a resume will be issued.  ...or 2) Use my application's memory usage in the same manner.  Does anyone know how to do either of these things?

Thanks much

[Toader Mihai]

Hello,

Could you please attach a screenshot of your project and more details so I can get a better understanding of your problem.

From what I understand of your problem you either store all the data(using shift registers for example) and running out of memory at some point, or you can't process all the data as fast as you receive them.

From what I see you have a few options:

1)Try to lower the amount of data you are sending

2)Try to optimize your code to process data faster

3)Reconsider the amount of data aquisition/data trasmision/data processing you are doing in regards to the hardware you are using

Regards,

Toader Mihai

[acfkt]

Hi Toader,

Thanks for your response.

1) I'm not sending any data.  I'm trying to consume an incoming data stream which is being driven by an OEM device.  This device basically has an FPGA hooked up to a 100Mbit/s hose.  You can start it, pause it and resume it.  Those are the available operations related to consuming the data stream.  I think the crux of the problem is deciding when to pause the OEM device to give the LabView app a chance to process and store the accumulated portion of the data stream.

2) Sure, but it's not my program and is large and complicated.  I guess I could write my own program within a program, but I would rather use the existing architecture.  I might write my own micro app, but I doubt it will keep up with the FPGA driven hose.  If I could detect the condition leading up to the "not enough memory" error, which it seems many LV developers have encountered, but not really solved, then I could issue a pause to the OEM device.

3) Well using a LabView application under a 2Ghz Windows box may not be sufficient hardware.  But I really think it's the Windows operating system that I'm having trouble with, not the hardware platform.

I've tried several counters in the LabView application, watched task manager before/during/after the "not enough memory" error, and downloaded an interesting app called taskmanager.vi in an attempt to get something to correlate with the error message.  I've not succeeded yet.  Here's what I think is happening.  The Windows OS is managing my wireless hardware, when it receives a TCP/IP packet, it puts it in the Windows Message que of my LabView application.  I think the "not enough memory" error relates to a Windows OS allocation for my message que which is being exceeded.  Any Windows programmers out there who would know how to look at the application's message que during runtime?

Thanks for your classic suggestions Toader, I may try a micro app which is spawned by the main app when its time to grab the data.  My intuition is that no software limited by the Windows OS is going to keep up with single minded FPGA hardware.

I thought this very interesting discussion was the answer and it may still be, but after trying 30+ various counters under Memory, System, Process, TCP, and Server, none correlated to the error.

http://forums.ni.com/t5/LabVIEW/System-monitor-counter/m-p/1653448/message-uid/1653448/highlight/tru...

I also tried a taskmanager.vi, but none of the various flavors of memory tracked by that little gem correlated with the error either.  At this point, I started to wonder "what memory was there not enough of?".

Terry