Packet Input block Buffer for TCP/IP Communication

Hi,

I am using the Packet Input block of the Simulink Desktop Real-Time [SLDRT] library for a Simulink model running in external mode. https://de.mathworks.com/help/sldrt/ref/packetinput.html

In my set up, I am receiving and sending serial binary messages via TCP/IP in a frquency of 500Hz. My problem is, that there are 5 initial messages of different length before the real communication starts and the messages become constant in terms of length.

With the usage of some enabled subsystems and multiple Packet Output blocks I was able to handle the sending of differen messages, but I don't know how to use the Packet Input block to receive messages of different lengths.

Functionality of the Package Input block

It offers a slot for the message length to be received which somehow looks like a buffer, but behaves a little strange.

In the picture below you see the result of the initial messages. I set the Packet Input block to 100 uint8 bytes. In black, there is message 1 (the oldest) in green there is message 2 and in blue is the latest message. I would have expected 115 Bytes in total, but the block simply filled the array and cut off as soon as it got 100 bytes.

For when I am setting the block to more bytes than it will receive, the array shows no bytes at all.

Conclusion: This block waits for a certain amount of bytes to be captured and stores them inside of an array. If the array is filled, it waits again for the same amount of bytes and overwrites the previous array then completely.

Question: is there some way to receive messages of different length when I know, that the first two bytes of each message determine the length of the message??

The messages I am going to receive have the following lengths in byte: 4,19,27,65,3 and then constantly 104 (atleast for now)

Answer 1

[Jan Houska]

Hi Maxmilian,

your understanding of the functionality of the Packet Input block is almost correct. The only difference is that the block does not wait (you cannot wait in a real-time model), but signals the availability of new data by its Data Ready port. If Data Ready is false, the block outputs the same data as in the previous time step. When Data Ready becomes true, it means that a new message has been received in this time step. You are also correct that the block only returns new message when it is complete. That is, if you set message length to 100, the block does not set Data Ready until 100 bytes are received.

The above suggests how to handle the variable-size messages. You need several Packet Input ports for this purpose. First, you read a two-byte message containing the size. Then, according to the size read, you read the rest of the message by other Packet Input blocks set to read the appropriate number of bytes. And because you only want to read a message if it has newly arrived, you use the Data Ready port to drive an Enable subsystem and only enable message reading if there is a new one ready.

Please see the attachment for an example.

Good Luck, Jan

[Maximilian Becker]

Hi Jan,

thank you very much for your great help!

First of all, I liked your explanation since I now know that I at least understood the blocks correctly. I just wasn't clear about the "waiting for packages" part since of course there is no waiting in real-time.

And secondly, thanks a lot for sharing your approach and even submitting a short example. That was very helpful, because the way I tried to implement the idea of using multiple read blocks did not work out (I ended up in algebraic loops using state charts and enabled sub systems), but your approach of reading a message through two blocks and passing them into a switch-case block is simply smart.

Have a nice day and see you around!

Best regards,

Max