Automatically request control from a remote panel

[boris]

Hello,

we are using development environment or applications build with LV 7.1.1 and we are using remote panels over a local intranet.

One request from our customer is that he don't want to right-click and request control but to get the control automatically at first (and every) startup of the remote panel. Is this possible and how?

Second question is again what is loaded to a remote client? Only the front panel or the complete program incl. block diagramm? I understand that the loading time depends on the "deep" of the used front panel objects. And I understand the lvrteng.exe as preload of common objects. So the question is if we use lots of customized objects it makes the loading slower? Is it then possible to integrate also customized objects in the Runtime Engine so that the loading becomes faster?

BR

Boris

[Aitor Solar]

Oops, I haven't seen this until now, sorry

One request from our customer is that he don't want to right-click and request control but to get the control automatically at first (and every) startup of the remote panel. Is this possible and how?

Yes, it's possible. The easiest solution is just to embed the first remote panel in a html file. In the object call, include the request parameter:

<PARAM name="REQCTRL" value=true>

Or, if you are using embed,

<EMBED (...) REQCTRL=true>

From that point on, the client will have control of all the remote panels the first one launches.

Now, if you don't want to use html files, I think (this memory of mine...) you can use the "Remote Panel Client Request Control" Application method from the LV instance in the client machine.

Second question is again what is loaded to a remote client?

That's a difficult question. From my tests, it seems it transmits all but the block diagram objects. That is: the front panel, the code and the data. Because of that, is imperative to check the default values objects have, because they go in the data part; I had a big bad problem caused by an array which default value had thounsands of values; incidentally I developed a VI that checks memory usage of all VIs to avoid this kind of mistakes.

I understand that the loading time depends on the "deep" of the used front panel objects.

In fact it depends on a lot of things, as IMHO the RP protocol is not as optimized as should be. That way, net acceleration and compression work great when downloading a remote panel and reduce loading times (but strangely, the data like graph plots or signal arrays don't seem to go faster with this kind of systems). For example, in my original tests I saw the amount of data sent was roughly twice the needed. Luckily, NI developed a patch for 7.1.1 that resolved that error (I don't know if it was a public patch or just for us, I tstll have to check this in LV8 to see if it's included ).

I hope you still need the info; if you have any doubt don't hesitate to ask, even if I don't know it (something usual), I'll check it because I have a heavily remote-paneled application and any new info can make it better.

Saludos,

Aitor

[boris]

Hello Aitor,

yes, your hints are still helpfull. Obviously I hav also forgotten to look for the feedback and one of my colleagues has found your request.

BR

Boris

[Aitor Solar]

Now, what I haven't discovered is how to give control programmatically to a specific client that's viewing the VI.

This can be done from the client machine (either right-clicking, or from the local LV through the Request Control method). But if the client just has the runtime and it's viewing the RP through a web browser, you can't give him the control from the server machine, just unlock the panel and wait the human user to ask for it :-(.

Saludos,

Aitor

[brent99]

Now, what I haven't discovered is how to give control programmatically to a specific client that's viewing the VI.

This can be done from the client machine (either right-clicking, or from the local LV through the Request Control method). But if the client just has the runtime and it's viewing the RP through a web browser, you can't give him the control from the server machine, just unlock the panel and wait the human user to ask for it :-(.

Saludos,

Aitor

Exactly, and as I noted earlier -- on 8.0 -- I don't see the lock/unlock property controls working at all, so I can't even force a client to release, let alone dole out to a specific client. The controls to request connection referred to in a previous mention would require a seperate client-only program, which is somewhat self-defeating. There are better ways to implement multi-network apps in labview if you are going to have client-only programs. What I liked about this technology is that you can alter the server code and not have the clients download anything new.

Some of the keys to remember:

1. Enable the webserver in your ini file (I include it in the project so I don't have to keep updating that line)

2. ALL properties that you call need to be set after a new client connects. Otherwise, you get the DEFAULT property showing in the client. I'm not sure if this includes value and whether the value property node differs from local variable "value". I think value properties are retained but there seem to be some exceptions to that.

3. If the server is too busy, it'll respond poorly to connections. Keep your interval loops short or your intervals long.

I implemented a multi-player game that showcases this technology working as well as I can get it to work. All in all, I think it works really great. But it was an uphill battle getting it the clients to have front panels in synch, use pop-out launches, stop dropping clients, have the server be responsive, and rarely blow up browsers (seems to blow up browsers on re-entry without broser restarts), and deal with licensing issues, but I seem to have got these details worked out. Its an adult-targeted college drinking game inspired by Yahtzee: http://www.geocities.com/fsmithgoldberg and you are not allowed to view the game if you think you might have any desire to complain about its existance. While I sometimes wonder conceptually about G and all the little quirks you have with Labview, I can't imagine having implemented such a complicated program in anything else so quickly.

Also, I've been told the MAC version works but is unusably slow. Because I make heavy use of pop-ups and I've read they used to not be supported, I'm partially surprised it works at all.

[Aitor Solar]

I wonder what kind of communication establishes the remote panel with the server machine's LV Web Browser. Obviously, the htm file request is HTTP, but what about the inner remote-panel-to-original-VI part?

I suppose it goes for the same port, but surely follows a NI private protocol. If we could "decieve" it to believe it has recieved a request control from the remote machine... :question:

Saludos,

Aitor

[brent99]

I wonder what kind of communication establishes the remote panel with the server machine's LV Web Browser. Obviously, the htm file request is HTTP, but what about the inner remote-panel-to-original-VI part?

I suppose it goes for the same port, but surely follows a NI private protocol. If we could "decieve" it to believe it has recieved a request control from the remote machine... :question:

Saludos,

Aitor

According to the documentation, it transmits the private protocol over port 3015. I'm not sure about duping it out. I think its a serious limitation when dealing with more than one client using this technology, but since NI doesn't seem to have many people appying this technology with multiple clients, it isn't a high priority for them. Its fine for 1 client because you can auto-connect easily.

My thought on duping it out is that if you could get the html to continually try and auto-connect every 10 seconds or so, then the server could choose a client by disconnecting clients until the desired client grabs the connection.

I'm running my game on a slow server and I noticed last night I have a slow memory leak that tanks the program once it runs out of physical memory. I'm pretty sure the leak is caused by an unclosed reference in a loop that polls for initial connections and can be resolved easily, but that's probably another thing to keep an eye out for.

[Aitor Solar]

My thought on duping it out is that if you could get the html to continually try and auto-connect every 10 seconds or so, then the server could choose a client by disconnecting clients until the desired client grabs the connection.

But you don't know, from the html page, if the remote panel has control or not (or at least I haven't found how). The embedded object doesn't expose any property or method. Well, in fact you can read and change the "reqctrl" attribute, but the remote panel doesn't pay attention to that after startup .

Of course, you could reload the whole page every x seconds, asking for control, but that seems a real bad solution :thumbdown:.

Saludos,

Aitor

[brent99]

But you don't know, from the html page, if the remote panel has control or not (or at least I haven't found how). The embedded object doesn't expose any property or method. Well, in fact you can read and change the "reqctrl" attribute, but the remote panel doesn't pay attention to that after startup .

Of course, you could reload the whole page every x seconds, asking for control, but that seems a real bad solution :thumbdown:.

Saludos,

Aitor

I never claimed it was a GREAT idea, just an idea...

[brent99]

I have a follow up to post. After extensive work trying to get this technology working, I still had a few problems.

1. MAC support lacking, which MAC users didn't seem to appreciate

2. While I was able to get multi-user switching to occur and be largely stable, some users still reported that they were getting kicked off

3. The labview server, running on a 486, was pretty sluggish to respond at times

4. Users didn't like downloading and installing the plugin, and the "right-clicking" was awkward

5. Large graphics in the VIs were causing clients to boot

I actually found a workable solution to ALL of this. Its pretty "out there" but it works great. What I did was connect to my Windows Labview program using a linux browser. So the Labview program sees 1 connection. Then, I serve up the linux browser (disabled in a "bank client" mode) via VNC.

The result?

Works on basically all computers

No right click switching of users

Fast Web Server response

Large Graphics "ok"

Totally stable

Works via internet browser without any special plugin (uses Java wrapper to launch VNC)

No licensing limit on the # of users connected (default of 1 for developers now ok)

Environment can be contained so that the server is "safe" from the users

Anyway, I'm pretty impressed with how this crazy idea worked out, so I thought I'd at least attempt to share it, even though its not the simplest blueprint in the world to follow.