How does the "Flatten to string" function actually work?

[rolfk]

That string part unflattened would give 19.901!

[TesterTest]

Now you can indeed stone me 😄
Failure was my hardcoded value and you are right with 901.
Thank you for picking that up - the dll works!

Next problem is that the RT-Controller does not accept my messages though 😞
There is a TCP Read block that is polled? every second but somehow does not get activated when I send the byte array via C# (I see error code 2 every second when I attach a probe and that loop stops when I send a C# message) but gets activated when the original Labview app is used. No idea what that is about and just too inexperienced with LabView to really troubleshoot this unfortunately. So i guess I am done with this project :'(
 

[rolfk]

Standard error code 2 is out of memory. This can happen if the actual data stream that is received does not contain the bytes it should.

My uninformed guess (I haven't seen your code) is that you do something wrong with encoding on the C# side of things. The data that you receive from the DLL is a binary bytestream and needs to be send over the link 100% unaltered. So your TCPClient.GetStream.Write() or whatever you use should not interpret that bytestream as a string that needs to be encoded in UTF8 or whatever but simply send it completely unaltered off.

Something like this:

    TcpClient client = new TcpClient(server, port);
  
    // Translate the data into a LabVIEW bytestream
    Byte[] data = LabVIEWDLL.GotoXY(14.901, 10.901, Abs);   
 
    // Send the message to the connected TcpServer. 
    client.GetStream().Write(data, 0, data.Length);

If you already do this you may want to use Wireshark to verify what your C# client is actually sending over the wire.

If that all doesn't help you should show the actual part of the LabVIEW code that receives and decodes the data. It may be something different than what we assumed so far based on the information you provided.

[TesterTest]

You were right - I needed to send two messages via TCP Client - one with the length of the second and then it worked.
My commands are now interpreted correctly by the machine - Yeah!

Right now I am trying to go the other way around and read status messages from the machine. Did the same thing with a vi to dll but somehow some of the doubles get displayed wrong in my C# app. Even tried to convert them into a string but that shows the same digits.
 As an example:

When I should get 10.101(...) as a return value I do get 10.101(...)

 When I should get 10.305(...) as a return value I do get 10.123(...)
When I should get 10.401(...) as a return value I do get 10.123(...)

When I should get 10.500(...) as a return value I do get 10.500(...)

So only some of the decimal places get displayed wrong. Is that a conversion thing again?
I know this is getting way offtopic now but I probably shouldn't open threads just for these type of questions.
Thanks everyone - you have been a massive help!

[rolfk]

You could obviously modify the VI in the DLL by wiring the resulting bytestream string through an additional Flatten to String with the "Prepend array or string size" Boolean set to true.

An alternative though not really recommendable would be to use a modification of my proposed code:

    TcpClient client = new TcpClient(server, port);
  
    // Translate the data into a LabVIEW bytestream
    Byte[] data = LabVIEWDLL.GotoXY(14.901, 10.901, Abs);   
 
    // Send the length of the data payload as BigEndian int32 to the connected TcpServer. 
    Byte[] length = BitConverter.GetBytes((int)data.Length);
    if (BitConverter.IsLittleEndian)
           Array.Reverse(length);
    client.GetStream().Write(length, 0, 4);

    // Send the actual data payload to the connected TcpServer. 
    client.GetStream().Write(data, 0, data.Length);

[MaheshAB100]

Hi,

I am facing the same issue

I read this whole thread but able to get the solution

may i know how to solve it

thanks

[Yamaeda]

Check two messages above yours.

Re: How does the "Flatten to string" function actually work? - Page 4 - NI Community

[altenbach]

---

@MaheshAB100 wrote:

I am facing the same issue

I read this whole thread but able to get the solution

may i know how to solve it

---

This is a very long and very old thread and we have no idea which post you are replying to or what "same" actually is.

Please start a new thread and explain in detail what "it" is you are trying to solve. Attach a simple VI containing a typical input value as diagram constant and explain exactly what result you expect.

[MaheshAB100]

Dear Yamaeda,

We were not able to get the GotoXY.vi running - got error unable to locate ctl files

even if we were to get that working, this solution would require some for labview installation on client side

we do not  want to install any labview component on client , we are tying to use a VC++ client to send data to server

we are able to send data from LabVIEW client(writeClient.vi) to a labview server that uses STM  Files attached), but unable to communicate  from a VC++ client (enclosed) -get Data format is corrupted on server after tcp connection is established

VC++ code )src.zip)needs a few changes but we are not sure what needs to be done

any help is appreciated

[altenbach]

---

@MaheshAB100 wrote:

we do not  want to install any labview component on client , we are tying to use a VC++ client to send data to server

we are able to send data from LabVIEW client(writeClient.vi) to a labview server that uses STM  Files attached), but unable to communicate  from a VC++ client (enclosed) -get Data format is corrupted on server after tcp connection is established

VC++ code )src.zip)needs a few changes but we are not sure what needs to be done

any help is appreciated

---

... so the problem is on the VC++ side, and has nothing to do with LabVIEW. It seems you are posting in the wrong forum. 😄