Simulink - TCP/IP Receive with variable Data Size

In Simulink (2016a) I'm using TCP/IP Receive block (from Instrument Control Toolbox) to receive some a ASCII string from remote server, every 0.5 seconds. The bytes are passing through fine and Server-Simulink Client are chatting with no problem.

However, every time remote server sends string, it's of different length and with that the received stream doesn't have fixed byte length. For example, this is what server sends at different timestamps:

0.5 seconds: "value=1.345" (size = 11 bytes)

1.0 seconds: "value=10.345" (size = 12 bytes)

1.5 seconds: "value=-105.345" (size = 14 bytes)

.

.

.

The problem is that in TCP/IP Receive block you have to specify Data Size as constant and so if I specify it to be let's say 1 byte I won't get all bytes of string on block's Data port but rather byte-per-byte, which is not good since I need to parse entire string, and if I specify the Data size to some big number let's say 50 (my strings are never longer than 20 bytes) the TCP/IP receive block waits for the buffer to fill with 50 bytes, before it releases the bytes to Data port and that's also not good since than my string sentences can get cut off in the middle.

The similar implementation works OK in MATLAB, where I use:

tcpip(ip, port, 'InputBufferSize', 50)

and that's it, whether the buffer gets filled with 50 bytes or less I can read the entire string.

Is there a way to achieve similar behavior in Simulink's TCP/IP Receive?

[ALPER YALMAN]

I have the same problem. Did you find any solution?

[Leon M]

Hi.

Not really, Mathworks still hasn't fixed this... but I did a workaround, setting bytes size to 1 on Simulink client and sending string char by char from the server. When I sent first string I timestamped the time and I was sending chars at 5ms rate (my string never exceeded 50 bytes, so I got them all before 0.5 s), when last string was sent from server I timestamped again, calculated the necessary delay I have to wait to get to 0.5 s and waited for that long.

I think today I would maybe do it the otherway, embedding tcpip function into Simulink m-func block. It's not perfect since you would have to initialize tcpip object everytime you call the block, but I think it should work.