LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Ethernet data processing

Hello,

 

I am using TCP/IP protocol to communicate with our customized FPGA board. "TCP Read" function is used to read the data and the input parameters are Mode: Immediate, No. of Bytes to read: 1460, Time out: 100ms. In this mode, the TCP read will capture the available data in buffer at that time.

 

For example the captured data is:

0704800000000000000004030004000000000108070480000000000000000403000400000000000807048402000000000000000000180000DC0101010003C000230006E0000506086601DC0000000008

 

The captured data consists of 3 packets and it may vary. Each packet consists of Start Frame Identifier (SFI) "07", Body and End Frame Identifier (EFI) "08". In each packet first 32 characters are part of message header. There is one field called message length (2 bytes) in the message header shown in green colour. This length consists of Message Body + EFI.

 

Every time I'll receive the data as shown in example. Kindly help me and suggest which method to follow to implement this kind of applications.

 

For more clarity please find the enclosed algorithm.

 

Regards,

S Nagaraju.

0 Kudos
Message 1 of 7
(3,154 Views)

Hi Sonti,

 

suggest which method to follow to implement this kind of applications.

What "kind of application" do you need?

There are NO questions in your post!

All you do is describing a data message from your device - and it seems to me you already are able to receive this message…

 

So what exactly is your problem? Where are you stuck? Please attach your current VI with same example data set as default value!

 

0004000000000108 There is one field called message length (2 bytes) in the message header shown in green colour. This length consists of Message Body + EFI.

So you get a message length of "4" bytes (?). Then you receive "00 00 00 00" and an additional "01", followed by EFI "08". This does NOT suit to your protocol description!

Please review your data message format and check for any inconsistencies!

 

 

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 7
(3,119 Views)

Hello GerdW,

The first 32 characters are part of message header. 0704800000000000000004030004000000000108

Blue colour characters are Message header, Orange colour characters are Message Body and Black colour characters are Message Footer/EFI. The length "0004" means 4 bytes i.e. 00000108.

 

I implemented this operation. But my question is, If I receive the data as shown in below example what i have to do?

 

For Example, I'm receiving continuous data i.e.

Data-1: 07048000000000000000040300040000000001080704800000000000000004030004

Data-2: 00000000000807048402000000000000000000180000DC0101010003C000230006E0000506086601DC0000000008

 

Data-1 contains the uncompleted packet and the continuation is in Data-2. In this situation how i have to handle the data.

 

Please find the enclosed VI which I developed.

 

Regards,

S Nagaraju

0 Kudos
Message 3 of 7
(3,110 Views)

Hi Sonti,

 

I implemented this operation

To get the message content could be much easier:

check.png

 

If I receive the data as shown in below example what i have to do?

You should append new data at the end of the current string buffer. When you have received a full message you remove it from the start of your string buffer.

Once you synchronized to the data source your string buffer should always start with the start of a new message frame and you only need to check for EFI mark…

(Before synchronization you need to throw away the first bytes of the partly received message.)

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 4 of 7
(3,101 Views)

Hello GerdW,

The approach is good, but if you are matching the string with "0807" there is a chance to trigger those characters in message body. That’s the reason I’m following as per defined message format.

 

You should append new data at the end of the current string buffer.

Actually one of my colleague is developed same logic in "QT Software" and they are having direct class called "QByteArray" which will take care the appending the data to buffer. They are using the "readAll" function to read the socket data after that they are putting the data buffer using "QByteArray".

 

Is there any direct function is available in LabVIEW to append the new data to current data?

What about FIFO concept for this ethernet data handling and how to implement here??

 

Regards,

S Nagaraju

0 Kudos
Message 5 of 7
(3,091 Views)

Hi Sonti,

 

to append strings you should use ConcatenateStrings function…

 

The approach is good, but if you are matching the string with "0807" there is a chance to trigger those characters in message body. That’s the reason I’m following as per defined message format.

When the start/end markers can occur in the message the whole data format is bad…

Anyway: you only need to sync once with your data stream. Then you know your buffer always starts with the beginning of the next message and you only need to wait until you receveive the next EFI…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 6 of 7
(3,079 Views)

Hi GerdW,

 

Yes, I need to wait for next EFI.

What about FIFO concept for this ethernet data handling and how to implement here??

 

Regards,

S Nagaraju

0 Kudos
Message 7 of 7
(3,073 Views)