TCP/IP Receive block: Use message length defined in message header to receive variable message length

Hi,

I am trying to send and receive messages from a remote tcp/ip device in real time. Both, the messages I send and the messages I receive are of variable length, where the header of each message defines it's length (the first two bytes define the length of the whole message in bytes).

While this is no problem for the send block, since it simply sends what enters it within the time of the fixed step size, the receive block uses a FIFO buffer of fixed length: I can either define the specific length of the message which will cause errors if I receive less than what I have defined within the timeout time I or can simply put out each byte by byte.

I am expecting new messages with a frequency of 500Hz (each 2ms) and will be sending in the same frequency.

The messages I am working with each have a header with 2 bytes that describe the length of the message. E.g. 0x00 0x05 0x56 0x00 0x02, where the 0x05 defines the message to be of length 5 byte.

Usually the message that I receive are of same length except for 5 initial messages and error messages.

Is there some way to add variable lengths using the knowledge withing the message's header, or are there other suggestions how to use the knowledge about the message length to find them inside of the data stream?

I came across a similar problem without a real solution here: https://de.mathworks.com/matlabcentral/answers/374200-simulink-tcp-ip-receive-with-variable-data-size

The TCP/IP Receive block can be found here: https://de.mathworks.com/help/instrument/tcpipreceive.html

Thank you in advance.

EDIT: Is it possible to reset the FIFO buffer in each time step the status for receiving messages (in non-blocking mode) is = 0? When using a resettable subsystem I get an error message saying saying "Direct feedback connections involving nonvirtual subsystem 'untitled/Resettable Subsystem' are not allowed." because the reset for the subsystem come out of the subsystem and is therefore part of the loop.

[Maximilian Becker]

I have been trying the TCP-Client, TCP-Receive and TCP-Send block, but the simulation ends after an instant instead of the defined 10 seconds.

Any ideas how to fix this, because in 20 attempts, I received the correct response once, otherwise I don't receive anything.

I am trying to alternate the send and receive with a pulse generator, but it does not work.

I feel that the block terminates the simulation as soon as a message is received/sent.

EDIT: setting the simulation time to "inf" stopped the program from terminating and depending if the desired TCP port is availavle or not, I even get the correct message from the server

[Maximilian Becker]

I noticed, that the simulation is getting executed on a very high level of speed. I would really like Simulink to run in real-time mode, where in each iteration step the TCP buffer will be loaded, cleared and a message be sent. Is this somehow possible?

The problem with simulink in normal desktop mode is, that the blocks designed for the synchronization with the CPU-clock are not designed for the TCP real time set.

So is the only way to solve my problem to run the exact same simulink code on an external remote computer and use external mode to get access?

Answer 1

[Maximilian Becker]

Variable Message lengths:

The TCP Receive and TCP Send blocks of the Simulink Real-Time / IP library have a "Length" port that contains the actual length of the received message. This allows to define the expected message to be longer than the actually received message by simply adding zeros to the actual message (eg: [message, 0 0 0]). Using the knowledge about the length of the message then allows to simply cut out the actual message without violating the buffer.

It seems like the Buffer is reseted in each iteration step not causing a problem for finding the message.

I was not able to use the TCP/IP blocks due to the variable message size.

Neither TCP nor TCP/IP blocks are included in code generation.

Stopping of the Simulation

The actual Simulink simulation runs in a much higher speed than real-time, so even setting the simulation time to inf does not fix the problem.

For this purpose both the Real-Time and the Desktop Real-Time environments have been introduced. Keep in mind, that the actual Real-Time environment requires an external machine that can be remote controlled through Simulink but has to have the code running inside (C-code generation must be valid).

On the other hand there is Desktop Real-Time environment. For more information about the three modes and the working principle, please check this: https://de.mathworks.com/matlabcentral/answers/536647-what-is-the-difference-between-normal-accelerator-and-external-mode-when-using-simulink-desktop-rea

I am still trying to establish the TCP/IP communication in Desktop Real-Time External. For further updates (if they exist) check here: https://de.mathworks.com/matlabcentral/answers/864025-simulink-for-real-time-control-of-a-robot-via-tcp-ip