SystemLink

cancel
Showing results for 
Search instead for 
Did you mean: 

Transmitting Binary Data via SystemLink

Solved!
Go to solution
Highlighted

Hello,

 

I am trying to send some binary data via systemlink from an NXG 3.1 application to Labview 2018 SP1 Application (32 bit). I attempt to send the data using a method similar to that shown in the Systemlink Snippet file. The data does transmit successfully (as in neither Systemlink  nor NXG report any errors), but when trying to read it on the Labview side, I receive an empty string. The code does execute, but the string is empty. I have confirmed that the string has a length of zero and it is not a case of not being able to show characters.

 

I know the transmission method works because I have been able transmit other strings successfully. I have only seen this issue when trying to transmit a binary array converted to  a string. Does anyone have any idea why this does not work? I have included the Labview snipped for reference.

0 Kudos
Message 1 of 14
(282 Views)

In LabVIEW NXG, strings are for text only, not for binary data. The "Byte Array to String" node interprets your byte array as a text string; when it encounters the first null byte (0x00), it considers that to be the end of the string and discards the rest of your data.

 

 

Certified LabVIEW Developer

0 Kudos
Message 2 of 14
(144 Views)

Hi JSKH, thank you for your answer!

 

That would make sense, but I'm a little confused as the to why my example I have attached works. Here I read from the license file as a binary file, and successfully output it's string data. The byte array to string does need the extended ascii parameter to work however.  It only seems to lose the data when I try and pass it over Systemlink. 

 

 

0 Kudos
Message 3 of 14
(130 Views)

For comparison, here is what happens when I try to use Systemlink with my localhost set up as a Systemlink server. The string is read successfully in NXG but when I search for the License tag in the Labview Tag Query file it shows up as a blank string. 

0 Kudos
Message 4 of 14
(122 Views)

Hi, it's a binary file.

 

I have modified your gvi (attached "4.0") to convert the byte array read from file to a hex formatted string, this string can be sent to CG through SystemLink. In CG you can then convert the string back to the original byte array (attached snippet). 

Regards,
André (CLA, CLED)
Message 5 of 14
(114 Views)

Hi Andre,

 

Thank you for your answer. Your suggestion does work, and we did try that already. But we were hoping we would be able to send the string as is, without having to do any conversion on the Labview side. For business reasons, this would not be a trivial thing to add so we would like to avoid any extra code on the Labview side if possible.

 

Sending this string was possible in previous versions of Labview/Skyline so I was hoping that there was some way I could do the same thing in NXG, or at least understand why Systemlink is not able to send the raw string. 

0 Kudos
Message 6 of 14
(109 Views)

Hi,

 

I wouldn't know why it could've worked before.

Someone from the SystemLink team might be able to shed more light on this.

 

It would help them if you could post version details of when it seemed to work like you describe.

Regards,
André (CLA, CLED)
0 Kudos
Message 7 of 14
(105 Views)

This worked in Labview 2018 32-bit version. I am in contact with NI support about this as well so hopefully their Systemlink team will be able to explain it. 

0 Kudos
Message 8 of 14
(103 Views)

@VMDC wrote:

For business reasons, this would not be a trivial thing to add so we would like to avoid any extra code on the Labview side if possible.


As a workaround, you could use write a classic LabVIEW VI to read the binary file and upload the binary string to SystemLink, then use the VI Interop node to call that VI from LabVIEW NXG.

 


@VMDC wrote:

Sending this string was possible in previous versions of Labview/Skyline so I was hoping that there was some way I could do the same thing in NXG, or at least understand why Systemlink is not able to send the raw string. 


Classic LabVIEW did not distinguish between text strings and binary strings, but LabVIEW NXG does.

 

In classic LabVIEW, a string is just a byte array represented as a pink wire.

 

In LabVIEW NXG, strings are for text only. Furthermore, all strings in LabVIEW NXG are converted to the UTF-8 encoding.

 


@VMDC wrote:

For comparison, here is what happens when I try to use Systemlink with my localhost set up as a Systemlink server. The string is read successfully in NXG...


It actually wasn't read the way you expect.

 

First, I must apologize: My previous explanation was incorrect. In your GVI, "Byte Array to String" does not discard data after the first null byte.

 

It actually does something worse: "Byte Array to String" converts your bytes into a UTF-8 string. In other words, it corrupts your binary data! So, even if your GVI successfully uploads the data to SystemLink, the client will download a corrupted/invalid license file.

 

You can examine the effects for yourself:

 

NXG String Conversion.png

 

In your License File Example.lic, your 14th byte is 0x9E. This is interpreted as the 'ž' character in Extended ASCII^ and then LabVIEW NXG converts it into the UTF-8 representation of 'ž' which is 0xC5BE. (See http://i18nqa.com/debug/utf8-debug.html for more possible corruptions)

 

So your license file data is 368 bytes, but after passing through "Byte Array to String" it becomes 395 bytes.

 

^The term "extended ASCII" is ambiguous because there are many different versions of extended ASCII. NI does not document which version is chosen here, and whether a different version is chosen if the PC's locale is set to a different country.

Certified LabVIEW Developer

Message 9 of 14
(82 Views)
Solution
Accepted by topic author VMDC

Hi

 

I just thought of something important.

 

SystemLink sends messages to the server using an https/http restful interface with JSON as body.

 

Your file content is added in a cluster that is flattened to JSON to be send to the server. The string you try to send might violate JSON rules.

 

Easy test would be to capture the actual string that goes into the body of the http request and validate it through an online JSOn validator (https://jsonlint.com/). In case it's not valid JSON the server will not be able to interpret the data and not update the value.

Regards,
André (CLA, CLED)
Message 10 of 14
(60 Views)