Compress string on LV RT

[vgravel]

Hello,

I would like to know if there is any VI to compress stings on LabVIEW RT?

I need to send quite a bit of data from a cRIO using a TCP/IP connection. There is to much data for the TCP/IP to handle, so I'm looking for a viable option.

Any Ideas?

Thanks!

Vincent

[Samuel_S]

vgravel,

Depending on where you are trying to pass data to there are a number of options: FIFO, Network Streams, Shared Variables etc.

Here is a good over view of Real-Time communication methods: http://zone.ni.com/devzone/cda/tut/p/id/3105 

And here are some other articles which may help:

https://www.ni.com/en/support/documentation/supplemental/18/real-time-fifo-frequently-asked-question...

https://www.ni.com/en/shop/labview/lossless-communication-with-network-streams--components--archite....

I hope this gets you going 🙂

[vgravel]

Hello Samuel,

I'm trying to pass data to a laptop/desktop computer for saving and display purpose.

The amount of data is 1920000 I16 per seconds... I'm able to pass this amount of data but I will have to be able to at least double that amount in a near future.

From what I've read, casting to string and sending by TCP/IP is the best way to do that. I cannont lose any of these data (so UDP is not an option).

This is way i'm wondering if there is a way to compress those string to get a better throughput.

Thanks!

Vincent

[Samuel_S]

Hi,

I cant think of an explicit way to compress strings for TCP/IP for Real-Time systems, but one of the links above may be helpful in determining the best way to pass the amount of data your requesting. Here is also an article on Optimizing TCP/IP in Real-Time:

http://digital.ni.com/public.nsf/allkb/DA6777E0180003D0862569900059C048?OpenDocument 

🙂

[CoastalMaineBird]

The amount of data is 1920000 I16 per seconds

Thats 4 MBytes or 32 Mbits per sec. You obviously need at least a 100 Mbps net to handle that.

Keep in mind that random data does not compress as well as ASCII text. If you need lossless compression, your savings are likely to be 20% at best.  Is the CPU overhead for compressing and decompressing that amount of data worth the savings?