LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why does receive CLFN only return the first data in the buffer, but not the second?

Solved!
Go to solution

I have two separate loops in LabVIEW. The IPv6 server loop is running at 50 Hz and the IPv6 client loop is running double the rate at 25 Hz. This means that on average, the client calls my send subVI twice, every time the server calls the receive subVI.

 

When I run my program, the server always only receives the first message that the client sends and not the second message. However, what I do not understand is that the server's receive subVI then says that it has received a total number of bytes equal to Client message 1 + Client message 2.

 

For example:

Client sends message 1 = Hi

Client sends message 2 = Bye

Server receives message = Hi

Server number of bytes received = 7

 

What's going on here? I'd like to just receive the string 'HiBye' so that I can parse out separate messages with EOL characters.

 

Thanks.

 

Here are some screenshots of my LabVIEW program and C shared object library. Let me know if any other screenshots may help.

 

C Library Code:

 

 

Main VI (Server top loop, Client bottom loop):

 

 Receive subVI:

 

 

 

 

 

0 Kudos
Message 1 of 5
(1,180 Views)

I don't see any screenshots here.  You've stated that your 25 Hz loop runs at double the rate of your 50 Hz loop.  It's actually half the rate.

 

Maybe that was just careless wording, but if it's an actual misunderstanding, it's possible that your code is built around such a misunderstanding.  The misunderstanding would think the client iterates twice for every time the server iterates once.  The reality is opposite.  The server iterates twice for every time the client iterates once.

 

I can't draw a straight line between that and the behavior you're reporting, but I also can't rule it out as a possible contributor.

 

 

-Kevin P

 

 

0 Kudos
Message 2 of 5
(1,151 Views)

Kevin already pointed out some obvious things. Another thing I don't understand is why your server needs to spin the loop at all at such a high rate? Shouldn't it just wait for a connection, respond to the client request, and then wait again for the next request?


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
0 Kudos
Message 3 of 5
(1,145 Views)

Sorry. I don't know why it didn't upload the screenshots. I swear they were there when I clicked post.

 

Kevin, yeah that was a typo. I meant Server = 50 ms delay and Client = 25 ms delay. So the actual rate would be Server = 20 Hz and Client = 40 Hz.

 

Altenbach, the reason I am having the server spin the loop at such a high rate is because the client needs to send response strings with its status back to the server. Right now, I'm just trying to get the framework to work properly. Then, I plan to put in all the specialized functions and checks etc.

 

My problem right now, is that if the loops are running at different rates, I get the weird behavior stated in my original post. FYI, I get the same behavior if I run it straight from my C compiler without the loops i.e. if I call the send function twice and then the receive function once.

 

 

Screen shot of my main VI (server loop top, client loop bottom):

 

p1.PNG

 

 

 

Screen shot of part of my shared object library C code for my sbRIO Linux system:

 

p2.PNG

 

 

 

 

 

0 Kudos
Message 4 of 5
(1,136 Views)
Solution
Accepted by JHugh

Your problem is likely that you configured the CLN to pass the buffer as C string pointer, while the number of bytes returned is the actual bytes the recv() function filled into the buffer. On return from the CLN LabVIEW does a scanning of the buffer in the C string pointer and terminates the string at the first 0 byte it sees.

If you want to avoid this termination on NULL characters you either need to pass the data as LabVIEW string handle (and make sure to resize it on the C side accordingly through the call to the NumericArrayResize() function). This also would make the return value for the byte count unneccessary since the LabVIEW handle already contains the length of the buffer internally (which you have to set in your C code explicitly too).

Or you pass a byte array instead and configure the CLN paramter as C array pointer and resize the returned array excitedly to the number of bytes that your function returned.

Rolf Kalbermatter
Averna BV
Message 5 of 5
(1,124 Views)