Investigate Port Discovery Options about g-cli HOT 12 CLOSED

It is definitely worth exploring, especially if build process contains multiple small lv tools, then waiting for lv to launch before each execution is very inefficient.

We could use NI Service Locator to register CLI, then in Start CLI Interface you could just use service name to open proper tcp connection, however this will only work for single instance.

from g-cli.

One idea I had is if you could use something like service discovery but based on the VI name. That way you probably wont launch multiple instances of the same VI (or if you do it doesn't matter which instance of the CLI they connect to).

This is something I would need to investigate the technology though as I'm not too familiar with it at the minute.

from g-cli.

NI service Locator could be used for that also, just register with VI as service name. I am only not sure how this could be done from C# app but I probably also via TCP. NI service locator

from g-cli.

this is the publish get request for VI name "test1 test2" on port 5007
http://localhost:3580/publish?test1%20test2=HTTP%2f1.0%20200%20OK%0d%0aServer%3a%20Service%20Locator%0d%0aPragma%3a%20no-cache%0d%0aConnection%3a%20Close%0d%0aContent-Length%3a%2011%0d%0aContent-Type%3a%20text%2fhtml%0d%0a%0d%0aPort%3d5007%0d%0a

you can check if this is registered properly on:
http://localhost:3580/dumpinfo?

and for unregister:
http://localhost:3580/delete?test1%20test2

so C# app should be extended to send proper web request if labview is already running, then in Start CLI Interface.vi you could use Open TCP connection with VI name as service name.

from g-cli.

This looks great! thanks for the notes. We would still have to deal with name collisions as a potential but I think an approach like this could work.

from g-cli.

By name collisions you mean same multiple instances of the same VI or different VI but with the same name?
In case of multiple instances whole launching process should be changed. Probably we need to use VI server to run VI as clone.
In case of different VI but with the same name it should be easier, just use path or md5 with VI name.

from g-cli.

The first case was my concern although I hadn't considered of course LabVIEW had to handle that as well. That could be worked around for now with a simple wait and retry on the c# side. Since it is only during launch it shouldn't block for long.

In fact you could simplify further by causing it to wait if any other launch is in progress. This way we don't need the VI name in there which will hugely simplify the client library

from g-cli.

I can see one drawback with your solution that it won't work if someone really want to use it in prarallel. However since CLI in majority is used for triggering builds it should not be the case. We can stick with simple solution and in case of new change request for parallel execution this could be further developed.

from g-cli.

@JamesMc86 are you planing to implement that wait and retry feature in C# code? Do you need help with that?

from g-cli.

I'm pretty swamped on another project for a couple of weeks but I hope to look at it then.

I've realised one other minor problem with this scheme is actually getting the name of the launched VI from the LabVIEW library since it could be several layers deep in the application potentially, but I guess it could just be the top level? Would need to experiment with how it could be done robustly.

from g-cli.

OK So I'm going to try and tackle this at last. My current concept is:

VIs
Of course you are right - we can't get VI collisions in one environment since I don't believe there is an option to launch as a clone directly. However there could be collisions since they will all be running in the top level application name space.

In this case we can add an entry in the following format "cli/lvver/lvbits/viname" i.e. "cli/2011/x86/run%20builder" (I think drop the VI extension).

To lower the bar, lets not worry about collisions so we get this step done and then we can look at collisions once this is working (still target for release version though). If the service locator allows it just putting the full (escaped) path would solve the issue for now.

EXEs

Since EXEs don't have the same issue I'm tempted to continue with the current method. Although I don't like splitting it, this method is likely to be so much simpler and faster I think that is worthwhile.

from g-cli.

Got this working now in version-2 branch. Needs some build automation and tidying up before release as version 2.0

from g-cli.