Giter Site home page Giter Site logo

grpc-labview's Introduction

gRPC Support for LabVIEW

Image Image

This repo contains necessary C++ code and support VIs to implement a gRPC server and client in LabVIEW. You can either use the service as defined to implement a generic server via gRPC or use the implementation as a pattern to implement a gRPC service of your design.

The project supports Windows, Linux, and Linux RT.

Minimum Compatible LabVIEW Version

LabVIEW source is saved with LabVIEW 2019.

Note: This project is not yet complete

  • Not all .proto data types are supported
  • The VI generated has not been fully implemented when updating the generated code with the .proto - VIs need to be implemented by hand to match the .proto file in certain cases
  • Extensive testing is not complete
  • The names of the various generated methods, events, and VIs are subject to change until the 1.0 release
  • This project is not supported by NI Technical Support

User Guide

If you would like to use LabVIEW gRPC in your project and want to where to start: Quick Start and Basic Tutorial is a great place to start. This covers step by step guide on,

  • how to create a simple proto
  • generate the server code
  • generate the client code
  • make modification to the generated code
  • run the server and client program

Examples

Example servers are located in the examples foldes in the releases.

  • helloworld - Example server and client program which implements a simple Unary method. You can run this LabVIEW program along with Python server or client as well
  • route_guide - Example server and client program which implement unary, server streaming, client streaming and bidirectional functions

SSL/TLS Support

The connection to the server can be secured using TLS (Server provided certificates) or Multual TLS (Client and Server provided certificates). See Certificates for more information.

Building the server binaries

To build the binaries for the scripting tool or the gRPC server see Building for instructions.

Contributing

Contributions to grpc-labview are welcome from all. See Contributing for instructions.

grpc-labview's People

Contributors

abahetik avatar bshermanator avatar ccifra avatar chadallee avatar chethanravindranath avatar chrisb2244 avatar cpattar-ni avatar csjall avatar dstavilani avatar gaoruhao avatar jimkring avatar jovianarts avatar jyamada avatar karthikabiram avatar kt-jplotzke avatar navinsubramani avatar ni-sujain avatar nibbuchanan avatar niphilj avatar nithan314 avatar njkirchner avatar nprorekhin avatar pakdev avatar pbirkhol-ni avatar pratheekshasn avatar shivaprasad-basavaraj avatar wesleytangnationalinstruments avatar xhuff avatar yaqian256 avatar yash-ni avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

grpc-labview's Issues

"Scripting Tool" source to be relinked to "grpc-labview-support" source for dev purpose

Currently, "grpc-labview-support" source is built and deployed under the vi.lib as "grpc-labview-support-release" , and the "scripting tool" is dependent on the released version of "grpc-labview-support-release". So, when the "scripting tool" is deployed into vi.lib as "scripting tool release", it will maintain the dependency from the vi.lib for "grpc-labview-support-release".

This might make the release process simple. But the development process needs clear documentation so the developers know to treat the source as two different projects and make sure the "grpc-labview-support" changes are installed before making changes to the "scripting tool" source.

During the last discussion with @ccifra , the decision was to make the "scripting tool" source dependent on the "grpc-labview-support" source, so that the development process is easier, and cifra will take careful action during the release in his end.

LabVIEW crash or hang | LabVIEW service didn't implement the required event case

When a LabVIEW client API is called to LabVIEW service which doesn't have the required event structure implemented. Then,

  1. The LabVIEW client gets hung and waits infinitely for the LabVIEW service to respond.

So, I notice that's the mistake in the LabVIEW service for missing the implementation of the event. Maybe should it timeout at client's end? Either way, I go to the server and click Stop to stop the service.

  1. LabVIEW service gets hung in the "Stop Server" VI. and client also was hung on the method.

  2. So, I abort client VI and it aborts properly. But the server VI couldn't be aborted.

  3. So, I had to close the project to escape and I get stuck with this.

  4. Kill LabVIEW from task manager.

Server Template and scripting Improvement

Need:

  • No breakage or smooth update of existing code during proto update
  • Less boilerplate code should be part of the template and user code
  • Ways to abstract the user code and template code

Servicer build failed. @

@gaoruhao 在最新的版本中,在build servicer时失败了。

  1. 打开 LabVIEW gRPC Servicer.vipb 生成 vip文件出现以下问题,提示错误信息如下;想咨询一下,是哪里的配置有问题吗?
    image

Operate grpc-labview - DLL missing

Hi,

Where can I find the DLLs? Are they generated by gRPC Code Generator or do I have to download them (not found in GitHub) ?
Capture
Capture

I get error code 7 when I execute Run Service.vi.

Regards

New Modular Service Template

Some of the current limitations of the previous templates are,

  1. Template combines RPC messages and RPC methods into a single class (but proto can have many services per message)
  2. The server creation and close is coupled with the service methods and messages functions
  3. Only one service can run on a port number

The requirement for the new template is to,

  1. Modularize RPC messages, RPC service(s) and gRPC server/servicer functionality
  2. Enable user to add more than one service class to the library and run them on same port
  3. Create API and parent classes and abstract the common functionality out of the specific library

Some design note:
image

image

image

image

image

Client LabVIEW VIM Hangs

The generated client code needs updated error handling logic. The ClientUnaryCall in grpc_client.cc has 3 error conditions that return -1, -2, and -3. If any of those cases are met, the occurrence is never sent to the LabVIEW code.

Possible update (I can look into trying to making these changes as well to contribute to this repo).

  • Do not wait on occurrence if a non zero value is returned. Then either return an error or flag that says the call timed out (or something along those lines).

image

Not all data types are supported

We should complete the support for the remaining gRPC datatypes. This includes:
FIXED64
FIXED32
SFIXED32
SFIXED64
SINT32
SINT64

Add first class support for enums. Currently enums are just ints. We should create proper rings for them in LabVIEW. Enums can be sparse and have repeated values so we will have to create rings to support all possible enums.

labview grpc as client?

i want python grpc as server, labview program as client,i can't find labview support client.

Importing other proto definitions inside proto file

Hello there,

It seems to me that the import keyword is not supported yet for the proto file parsing. Is this something which is already considered to be done or I just have to create one big proto file from the linked proto files? I was trying to import the proto file for Opentelemetry and as it is separated into multiple proto file so it did not work.

Thank you in advance!

-Imre

Bug in Dependency for LabVIEW packages

  • Version numbers should be updated to the least supported version of dependent packages.
  • New Server & Client package should be dependent on the grpc servicer.

Send error details from service to client in LabVIEW

When the business logic of the service has an error (say an instrument error), then this should be propagated to the client. Looks like the service by default has the capability to send status for each call. If the best practice is to use that, then in LabVIEW we need a capability to send the error wire details to the client using status information.

It will be good to handle this in the service/client gRPC API layer like how LabVIEW does normally.

Note:
https://github.com/googleapis/googleapis/blob/master/google/rpc/status.proto

Improve New templates & Script Tool

  • New client template for multiple services
  • Script tool for the new client template
  • Streaming capability for Server and client : script tool update
  • Fix KnownIssue in script tool (bookmarked in LabVIEW)

Generate Appropriate Server DLL Path for Executable Support

The path for the server DLL is generated in the below VI:
labview source\Servers\Template Server\gRPC lvSupport\Server API\Server\Get Server DLL Path.vi

image

The path is stripped from current VI's path, which would work in LabVIEW source code but not with EXE.

Missing DLLs in gRPC Scripting Tools Project

Hi Team,

Greetings!!!

The DLL 'labview_grpc_generator.dll' is not available in the repo for all platforms (Win32, Win64, Linux, LinuxRT)
image

Kindly assist in uploading them to the repo in the earliest.

Thanks

Only first element of a gRPC server stream is transmitted in QueryServer_Event_Fire.vi

Hi,

I've discovered one thing when working with the example.

It seems like example\VIs\QueryServer_Event_Fire.vi transmits only the first element, however it is a gRPC stream and we should see different messages arriving to the client.

Steps to reproduce:

  1. Modify the shipping example ExampleQueryServer.vi. Open Timeout case and add some dynamic information to the "Hear Beat" message. I did it with server uptime.
    gRPC-stream
  2. Start example_client.exe
  3. We do receive 10 stream messages but they are the same:
Server uptime: 15.393039
Server Event: Heart Beat, uptime 16.397 seconds
Server Event: Heart Beat, uptime 16.397 seconds
Server Event: Heart Beat, uptime 16.397 seconds
Server Event: Heart Beat, uptime 16.397 seconds
Server Event: Heart Beat, uptime 16.397 seconds
Server Event: Heart Beat, uptime 16.397 seconds
Server Event: Heart Beat, uptime 16.397 seconds
Server Event: Heart Beat, uptime 16.397 seconds
Server Event: Heart Beat, uptime 16.397 seconds
Server Event: Heart Beat, uptime 16.397 seconds
Server notifications complete

Am I missing something or is gRPC server streaming is not yet fully implemented?

Crash at Server Creation

Hi everyone,

When I try to generate a server with project and proto files from helloworld example, LabVIEW crash every time.

LabVIEW version : 2021
grpc-labview version : 0.4.6.1

I open example project (helloworld.lvproj)
I execute gRPC tool (tools > gRPC > open gRPC Server-Client [2] - Code Generator)

  • First cell of the array, I pick proto file from example (helloworld.proto)
  • Target Project select current and opening project (helloworld.lvproj)
  • No Target Name
  • "hw" as Generated Library Name

First, I generate gRPC Client : it works correctly !
Next, I try to generate gRPC Server : doesn't work.

The first time, LabVIEW crashes with this message :
Capture

The second time, LabVIEW doesn't crash but report an error code (1305)
Capture2

I click on Continue and I search where the program crashes.
CTRL+T on gRPC Code Generator and check step by step each diagram block (and following the path given by the error code)
Found that error 1305 generated by Get Case Structure Frame (by Name).vi
Capture3

So, I tried another version of grpc-labview (v0.4.0). They doesn't work (crash appear in Update Methods Registration.vi with error code 1055).

According to NI Support (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019L75SAE&l=fr-FR), error appear each time where there is Default if Unwired tunnel in structure condition.

Finally, I tried to uninstall gRPC Server and Client Template [2] to install gRPC Server and Client Template.
This time, gRPC Client work again and gRPC Server crash with 1055 error code.
Capture4

Please, let me know if you need more information.

Thanks

LabVIEW crash or hang | When LabVIEW service didn't respond back to the LabVIEW client

When a LabVIEW client API is called to LabVIEW service which doesn't have the response method called. Then,

  1. The LabVIEW client gets hung and waits infinitely for the LabVIEW service to respond.

So, I notice that's the mistake in the LabVIEW service for missing the implementation of the response method. Maybe should it timeout at client's end? Either way, I go to server and click stop to stop the service.

  1. LabVIEW service gets hung in the "Stop Server" VI. and client also was hung on the method.

  2. So, I abort the client VI and it aborts properly. But the server VI couldn't be aborted.

  3. So, I had to close the project to escape and I get stuck with this.
    image

  4. Kill LabVIEW from task manager.

Separate Compiled Code missing for some VIs

Some VIs do not have "Separate compiled code from source file" checked, which leads to the files being modified when opened on a different platform (I guess using 32-bit LabVIEW is not the norm here?).

I could easily change these and mark them all, but that will probably cause merge conflicts since the files might be in various unrelated places and then annoy everyone else trying to work in this repository :/

I'll add the checkbox to any files that I actually modify, but I'm opening the issue in case this repository has a period of time (e.g. releases?) when everyone is likely to not have open branches, in which case perhaps the files could be mass-ticked?

Alternatively, is there some preferred strategy for handling this? (Or are the files intentionally not separated from compiled code?)

Unable to import nirfsa proto from ni-grpc-device-client\proto\nirfsa.proto

When attempting to run the template creation utility on the nirfsa.proto file from ni-grpc-device, it throws an error at the 'proto parser', code 5020 gRPC Template Creation Utility-release.lvlib:Error 5020.vi
Proto file import - get field info
image

Interestingly, it doesn't happen at the same index each time in the image above

gRPC Client Connectivity State

Is there a way to see the Client Connectivity? I can run my Client Code with no active servers and no errors are returned. We create a gRPC Channel but I do not see a way for me to query the state. Therefore, regardless if I have a valid IP address or active server or not, no errors or flags are produced.

For additional context, I am not a gRPC expert by any means.

The only thing I was able to find was information about the gRPC Connectivity API. My end goal is to see if I have an active connection to a server. Am I missing something in the current code base or is this something that could be added?

gRPC Connectivity Semantics and API
https://grpc.github.io/grpc/core/md_doc_connectivity-semantics-and-api.html

Create a Enum RPC message

  • Currently Enums are treated as a number for the gRPC communication which is fine. But it will be good to create atleast the "Enum" from proto file as a "Enum" typedef during the scripting. This will be helpful for the non gRPC communication operations.

Currently, I am creating a Enum typedef based on proto after scripting.

AB#2380350

Oneof support

Oneof is not currently support for reading for writing. For writing we need to define a mechanism which defines which value is set . For reading we need a mechanism to indicate which value is set.

AB#2491163

Server - Run Service.vi run one time

Hi,

I try to execute the generated Server vi with default parameters (localhost:50051 / Async) and when I click on run button, the vi execute one time and stop immediately.
I download few grpc-labview version (0.3.3 to 0.4.6) and labview_grpc_server.dll is present only in 0.3.3. Maybe I need to copy this DLL somewhere in my project or generate new library following Building.md.
I attach the vi execution :
Capture

Thanks

Improve User Experience of Creation Utility - Run When Opened

Tried installing the latest release (0.4.7.1?) but the generator application has issues.

  1. It doesn't autorun.
  2. If I run it manually it errors that it doesn't find an owning project. (the project item could not be found)

image

As you can see from the comment below I realised this is because it doesn't work like other dialogs in the editor.

Ideally it should open in a running state and have a "Generate" button which actually starts the process. I'm happy to see if I can get a PR together for this if it is worthwhile.

Cleanup of Existing Examples

The existing examples do not match how the scripting tools generate code these days.
We should update the example by using the scripting tools and filling in the generated code.

Need support for recursive message type

I encountered an error when using the grpc template creation tool like this:
image

I believe this is because in the proto file I have a message type which is recursive, like this:

message ComParam {
string id = 1;
string shortName = 2;
string value = 3;
bool isComplex = 4;
repeated ComParam children = 5;
}

Do we have a way to support this kind of message type?

Need Step by Step examples of Client and Server creation.

Create a step by step example of creating a gRPC server in LabVIEW. We should match the step by step examples used in other languages:
Quick start | Python | gRPC

We should use the same greeter proto file so that our LabVIEW server can easily be called by the clients in other languages in their tutorials.

Naming Convention for Server Name and Generated Files

A low priority request/question:

What would be the recommended naming convention for the server name and generated folders & files? If there are multiple naming conventions that are being followed for various types, it would be helpful to document them as recommended guidelines.

Looking at the folder names in parallel, I had named my server to be in "Normal Case with Spaces". In the recent code base, there is an auto-suffix for server and client which are of the formats - "_server" and "_client", which ends up with mixed naming convention for the generated library.

image
image

Similarly in gRPC lv support,
image
image

If we can choose a specific naming convention throughout, it would be helpful for consistency :)

Unary call to wrapped COM API classes ends in deadlock of the service VI

I have a gRPC server that wraps a COM API. This COM API has a very large feature set with multiple classes.
The generation of the gRPC client worked only by splitting the proto file into several small parts, which were convertible for themselves (memory error for the whole file). Probably there were no handles left, because the project now has over 2000 typedefs and over 1000 service VIs.
Now I have the problem that I can only call services successfully that are in the main class (Application). For all other classes or when trying to get a reference to another class, the unary call goes into a deadlock. When the COM interface returns an object, the gRPC server returns a unique random 64-bit object id for it instead. This is used for communication. But not for static (permanently existing) objects.
What could be the reason for this? And is the error more on the client side or in the server implementation? We are grateful for any advice and help.

Need Timeout in Client Calls

When doing calls to the server, if the function is partially implemented (there is an event handle structure but it doesn't return the value). The client waits forever, hanging the application. We need to specify a timeout for how long we can wait for the query to complete.

More testing on the "Update workflow" for Server and Client generated code with a updated proto

  • New Template:
  • Client Code doesnt support update, the old code have to be deleted and it has to regenerated from scratch again
  • Server Code needs more testing with different proto file updates.

Bugs

  • When a new template is created, the template is in memory of the LabVIEW or Code Generator project instance. This makes the new class in memory of two project instance (Code Generator Project and User project). This creates a issue during some update or delete operation.
  • In service, the template method VIs for service class are not removed when working with proto with two service (its removes for first service and not for the second service). This should be fixed, as it will bring the dependency from Template Server class. Temp fix would be, after code generation, user can delete the template files from the user project manually.

Error attempting to build binaries on Windows

@ccifra Attempting to build binaries on Windows results in error as follows.
When running the command: cmake -A Win32 ..
fatal error C1083: Cannot open include file: 'pthread.h'

Looks like it is trying to include linux specific header file.
Is there any other way to test this on Windows 10?

Limitation with auto code generation when the package name has 'dot'

When the proto file package name has 'dot' in it. For example: Service.V1 where the version of the service is represented as part of the package name, and the script is used to generate the code. Code generated doesnt have any methods in it, and no error are generated.

LV hangs sometimes when trying to start the server

Sometimes when the server is trying to start, LV hangs and I have to kill via task manager.
I've stripped out a lot of the code and have replicated with this piece of code running in a loop.
image
Sometimes it happens on the first run, more often it is after several iterations of running my test code and stopping it, then restarting.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.