LV and most languages support more than one size of floating point number. In particular, the single precision (4 byte), double precision (8 byte), and extended precision (10 or more) are pretty common. In C/C++ they will usually be called single, double, and long double. Sometimes you will see double doubles and other odd numeric types as well.
Check that the size of all three elements are correct, as misalignment of one of the earlier elements will affect the later elements.
The other factor causing this could be the byte order. Multibyte numbers can have their bytes transmitted either left-to-right, or right-to-left. This is often called little-endian and big-endian. It comes into play with memory architectures as well as transmission. By default, LabVIEW always assumes that data coming in from network and file are big-endian and does the work on little-endian machines like Intel to convert back and forth. If your data is in little endian format, then LV will load the bytes in the wrong order. If you are using the unflatten from string node, try wiring up the other byte-order parameter and see if that fixes it.
If you are still having trouble, try multiplying your double by 1000000, casting it to a long long and sending that over the socket. Then divide by 1000000 on the other side. But beware, if you want to keep decent precision doing this, you need to use long long because a long is only 4 bytes on the robot in c++! I did exactly this for a custom telemetry client I wrote
void writeDouble(std::vector<char>* packet, double value)
{
#ifndef ENABLE_TELEMETRY
return;
#endif
long long adjustedValue = ((long long)(value*1000000)); //send floating point as integer * 1000000
unsigned char *dblPtr = (unsigned char*)&adjustedValue;
for(int i = 0; i < sizeof(long long); i++)
{
packet->push_back(*dblPtr);
dblPtr++;
}
}
If all else fails you can send it as a string. Usually fool-proof.