02-27-2023 03:32 AM
ahh i see thats was a mistake i made at the beginning and i correct it . but it does not still seem to work. i write 3 commands to my werver and i only read back 2 .the first command isnt read.
concerning the data transfer do you mean using and FGV?
02-27-2023 03:33 AM
02-27-2023 03:43 AM
I seem to have misunderstood what you mean: "I need to constantly read and write that why i used only one VI"
If it's a different project, TCP would be the right choice.
Post your VI here, not images. I'm using the LV 2020 version. And fill the input data array with something useful (set the array control default value).
02-28-2023 08:29 AM
Hi diman27,
sorry for my late reponse i cannot post my code because of security issues and it is a code that was written by some collegues and i only work on a part.
i could found a solution to my past questions and it works fine. but i have a new question and please can you help me out if possible.
as i lately said i use my client to write data to my server and then read back data from my server to my client. (client and server VIs are found in different Labview projects)
the number of bytes writen varies from the data, and when i attache a 4bytes on my TCP Read the data i receive is not exact.
please How can i determine the number of bytes to be read form my server VIand then pass it to my TCP read in my client VI.
attached is an image of the part where i write and read my data.
thanks for your help and sorry for not sending a proper code
03-01-2023 01:41 AM
Hi Knight Of NI,
i use my client to write data to my server and then read back data from my server to my client. (client and server VIs are found in different Labview projects)
the number of bytes writen varies from the data, and when i attache a 4bytes on my TCP Read the data i receive is not exact.
please How can i determine the number of bytes to be read form my server VI and then pass it to my TCP read in my client VI.
-can i use a queues on two Vis in two diffeerent projects? if not please how can i transfer data from two different Vi on two projects
attached is an image of the part where i write and read my data.
thanks for your help and sorry for not sending a proper code
03-01-2023 02:26 AM
There is several ways for the receiver to know how many bytes will come when working asynchronous, one of them is to tell the receiver. Send the length as number first, in a separate packet. Requires two reads, one with a fixed length and the second can vary.
This can, of course, only work if the other side also works this way and wouldn't send any intermediate packets.
The other is to let the TCP Read VI run into a timeout but this ensure that the full data has been received.
03-01-2023 07:12 AM - edited 03-01-2023 07:13 AM
Hi Natacha_Kam,
What do you mean by "not exact"?
The number of received and sent bytes does not match? Or the data itself does not match?
If the data does not match, then you may be receiving data that was stored in the receive buffer from a previous exchange with the server
(it assumes that you have not reconnected to the server and there is unread data in the buffer).
It is necessary to see the full cycle of client-server data exchange in order to understand what is wrong. The images you have attached are not enough.
To determine the number of received bytes, use the approach you took earlier - "typecast" the size of transmitted data into first 4 bytes of the frame and read them first on the client side.
03-01-2023 01:29 PM
Hi diman27,
attached is a code i wrote to illustrate what i want to do. Thanks for your support
03-01-2023 01:32 PM
Hi matsa,
attached is a code i wrote to illustrate what i want to do.i donot really know the number of bytes to be read by the Read TCP in the server VI
Thanks for your support
03-01-2023 03:31 PM - edited 03-01-2023 03:36 PM
You asked variations of this questions multiple times. What is missing from the answers you got so far? Regarding this question I'll paste the help on TCP Read, which has a section on message protocols:
bytes to read is the number of bytes to read. You must wire a value greater than 0 in order to read data from a network connection. The default is 0. Use one of the following techniques to handle messages that might vary in size:
- Send messages that are preceded by a fixed size header that describes the message. For example, it might contain a command integer that identifies what kind of message follows and a length integer that identifies how much more data is in the message. Both the server and client receive messages by issuing a read function of eight bytes (assuming each is a four byte integer), converting them into the two integers, and using the length integer to determine the number of bytes to pass to a second read function for the remainder of the message. Once this second read is complete, each side loops back to the read function of the eight byte header. This technique is the most flexible, but it requires two reads to receive each message. In practice, the second read usually completes immediately if the message is written with a single write function.
- Make each message a fixed size. When the content of a message is smaller than the fixed size you specify, pad the message to the fixed size. This technique is marginally more efficient because only a single read is required to receive a message at the expense of sending unnecessary data sometimes.
- Send messages that are strictly ASCII in content, where each message is terminated by a carriage return and linefeed pair of characters. The read function has a mode input that, when passed CRLF, causes it to read until seeing a carriage return and linefeed sequence. This technique becomes more complicated when message data can possibly contain CRLF sequences, but it is quite common among many internet protocols, including POP3, FTP, and HTTP.
In one of your previous posts, you chose the first option: prepending your message with a fixed size header (consisting only of the number of bytes to follow). An easy way to do that is getting the length of your message (in string form) and typecasting that to a string. Send the length, send the message, done.
The output of "string length" is a signed 32 bit integer. 32 bit is 4 bytes. So on the receiving end, you read 4 bytes, convert (typecast) them to an i32, and read that many bytes to get your message. Done.
Wrap sending and receiving in Sub VIs. Copy them to your projects if necessary.