LabVIEW
UDP read function reads only strings with even numbered characters, that is, it reads 11, 1111, 111111, aa, aaaa but not 1, 111, a, aaa ...
I am connecting my PC (DELL PRECISION T1600 which has Intel Xeon and Labview 2014 with SP1 (32 bit) installed on it) to a test device via UDP 64 protocol. The code for that is in the attachment or the screenshot image of VI.
When I run this code on the PC, it doen't send the data string with odd number of characters, but it does send the ones with even numbers., that is, it reads 11, 1111, 111111, aa, aaaa but not 1, 111, a, aaa ...
The same program runs fine on my laptop where I have intalled 64 bit labVIEW.
Could it be the 64 and 32 bit be reason for this problem ?
Thanks,
Gunn
@nathand wrote:While it's probably not the source of your problem, the use of Decimal String to Number is incorrect for the Net Address input to UDP Open.
Well, it depends if the string contains a valid port number in decimal representation (U16 range). Stiill, one should wire the correct default representation so there is no coercion dot. (I have no idea why the string is called "device secondary address" when you wire it (with some detours) to the local port input. very confusing). Just wire a zero diagram constant to the local port so the program can select a free ephemeral port, since it is only used for return traffic, the source port does not matter.
@khatri wrote:
When I run this code on the PC, it doen't send the data string with odd number of characters, but it does send the ones with even numbers., that is, it reads 11, 1111, 111111, aa, aaaa but not 1, 111, a, aaa ...
So you have enabled the echo server on port 7 on the test device. Are you testing the same device with both PCs? Are the NICs the same, drivers updated?
Can you use wireshark to inspect the outgoing and incoming packets down to the last bit to determine if the outgoing or incoming packets are to blame for the difference in payload? So far we don't know!
