ProtoBuf Serialization in LV

[viSci]

Protobuf is a widely used Google serialization standard. I have an instrument that only communicates via HDLC encoded ProtoBuf messages. Protobuf tools are available for most languages but not LV as far as I know. So was wondering if any crafty folks out there have come up with a way to talk ProtoBuf in LV.   My understanding is that this would require building a Protobuf IDL (Interface Definition Language) compiler that would then guide a LV based encode/decode process.

[lvb]

I recently implemented a Protobuf encoder in LabVIEW.  Using the KISS method, I used clusters to represent "messages" and used the cluster index along with the item name for the ID.  This used the OpenG variant data tools to dynamically parse the contents of the cluster.  The rest of the encoding is done with a VarInt encoding and flatten to string.  Depending on your .proto structure and requirements (if it is acceptable to send optional items), this may or may not be a simple solution.

 

Proto Message <> LabVIEW Cluster

 

The implementations from Google involve auto-code generation of a class and then reading/writing the class data.  For a "complete" tool that allowed optional items, this is a lot more work than simply using clusters.

 

 

If you are looking for a starting point, the encoding is pretty well documented at the following link:

https://developers.google.com/protocol-buffers/docs/encoding

[DarrenJ]

Similarly, we wrote a ProtoBufs encoder to communicate from LabVIEW RT to a .NET application and an Android device.  This was for an internal demo (engineering version here, marketing version here).

 

In this case, LabVIEW natives are used to encode according to the Base 128 Varint and messaging structure in the link above. 

 

It worked really well for our application-- pretty powerful and not very difficult.  Feel free to send me a message for more information.

[nelg87]

I realize this is an old thread but I'm new to protobuf and was looking for some guidance on how to implement them with LabVIEW.  Is there any sample LabVIEW code out there for a protobuf encoder that I could take a look at and will give me a starting point?  Any help is greatly appreciated.  Thanks!

[Elio]

 

I want to communicate from a LabVIEW application (running on a cRIO 9039 Linux RT) to python and c++ applications using Protocol Buffers. (The messages are transferred through ZMQ).

Can anybody share some example code of the Protocol Buffers encoding and decoding in LabVIEW?

In order to take advantage of the auto-code generation, I was thinking of implementing the Protocol Buffer part in c/c++ (running on the cRIO) and then getting the parsed data into LabVIEW from there? Would that make sense? Has someone tried that approach

[MarkCG]

how are protobuffs that different form flattening a LabVIEW cluster ?  It seems like I may be implementing LabVIEW protobufs at my job. I keep checking this thread hoping someone will have done it already, because it really has very little appeal to me as a project, but I may have to. 

[smithd]

Its similar to flattening a cluster, except its cross language. It accomplishes this by having scripts which take a message definition and generate code in that language. This makes it easy to send a protobuf message, which might be represented in labview as a cluster*, to C or java or python or go or wherever. Its primary benefit over something like json is a slightly more extensive type system and speed.

This won't get you any of what I described but if you just need super basic support for generating a valid message manually: https://github.com/smithed/experiments/tree/master/Protocol Buffers

It would need a ton of work to actually support scripting. Doesn't seem like there is enough of an advantage.

 

*I'm pretty sure it always has to be a class actually due to things like optional data values.

[MarkCG]

On 6/5/2019 at 8:06 PM, smithd said:

Its similar to flattening a cluster, except its cross language. It accomplishes this by having scripts which take a message definition and generate code in that language. This makes it easy to send a protobuf message, which might be represented in labview as a cluster*, to C or java or python or go or wherever. Its primary benefit over something like json is a slightly more extensive type system and speed.

This won't get you any of what I described but if you just need super basic support for generating a valid message manually: https://github.com/smithed/experiments/tree/master/Protocol Buffers

It would need a ton of work to actually support scripting. Doesn't seem like there is enough of an advantage.

 

*I'm pretty sure it always has to be a class actually due to things like optional data values.

 

Daniel, thank you so much for sharing this and bringing it to my attention. So what someone would have to do is create a program that reads in a protobuf specification text file, and then uses VI scripting to create a VI that encodes a specific message, using the VIs in the library "protocol buffer encoder".  Seems like the sort of problem that you can break down recursively-- once the protobuff specification is parsed into a tree. you start at the root and recurse down the tree till you get to a leaf node. Generate code for all the leaves, then as you recurse back up wire the leaf code together. 

Easier said than done though...