Hi Dojo,
I'm working on a serial connector and have some questions about unstuffing.
The protocol I'm implementing(Pro-Bel SW-P-08) defines start of message(0x10 0x02) and end of message(0x10 0x03) control characters and defines a rule for cases where 0x10 appears in the data segment. The rule is simple, if the 0x10 appears in the data segment double it.
I'm receiving the following stuffed message:
0x10 0x02 0x0B 0x00 0x03 0x10 0x10 0x03 0x00 0x06 0xD9 0x10 0x03
Original implementation:
Initially I was removing stuffing from inside of the QAction, after reading the response, which works if the 0x10 is not followed by 0x03.
First attempt:
I added advanced tag to remove stuffing from the response.
As result the stream viewer was showing expected unstuffed message:
>> 16:40:10 - Incoming raw data
000000 1002 0B 00 00 10 03 00 06 DC 1003
However, this was still failing in the matching step and the data that was being passed to the QAction was 0x0B 0x00 0x00 which means that response reading was still interpreting 0x10 0x03(in the data segment) as end of message.
My response is defined like so:
Second attempt:
I added replace data action, instead of advanced tag.
Stream Viewer:
After increasing the log levels I was left with the following log:
Here we see that data is replaced properly, however the message is still cut short on the stream viewer level, and matching fails because 0x10 0x03 no longer exists(although it does actually come in).
Third attempt:
I added advanced tag, replace data action and stuffing removal in the QAction.
The advanced tag is the same as in the 1st attempt and replace data action is as follows:
The idea here is that odd number of 0x10 bytes is not possible because of doubling rule, so if I see odd number of bytes in the QAction, I can guarantee that the only source of them is my custom stuffing so I can safely replace them with 0x10 0x02 or 0x10 0x03 in the QAction. This only works if data is actually stuffed so I have to add back the stuffing as well, thus the first replacement rule 0x10 -> 0x10 0x10
All of this seems like a very weird way to achieve a common functionality of the serial communication, something I would expect to be available out of the box.
Is there a better, more straight forward way of achieving this?
Cheers
Hi,
-Using the stuffing attribute in the Advanced tag will not work with a "serial" TCP connection.
-The response will need to consist of 3 parameters:
- Header parameter (0x10 0x02)
- Read parameter of Interprete LengthType "last next param"
- Fixed parameter (0x10 0x03). Important to note that this is not a "trailer" type
By not defining the trailer type, we avoid that SLPort would forward the data to SLProtocol as soon as it would find the first occurrence of 0x10 0x03. The downside is that SLPort will wait until the defined timeout time of the command before forwarding the data to SLProtocol.
Once data enters in SLProtocol, it first needs to remove the stuffing bytes. This can be done by adding a trigger that goes off before the response and executes an action on the response of type "read stuffing" and inside the Type has the attributes value="0x10" startoffset="2" endoffset="2"
Then the data can be filled in the different parameters, which is done by executing the action to read the response.
As the read parameter in the response is of type "last next param", we avoid that the data would be cut off with the first occurrence that SLProtocol would find of 0x10 0x03.
Regards,
Thank you for your help Laurens. I will add another comment with conclusion on the topic for this specific case in another comment since I can't add images here. For anyone who might run in to this problem in the future make sure to read that comment as well for the full picture.
Cheers