cRIO w/remote panel

[orko]

Hi there,

I know I've been gone for a while, but now I'm settling into the new projects here and should be more available

I had a question about deplying cRIO applications on the network using the built-in web publishing tool. I have an application that currently runs on a cRIO (9102) that I would like to start controling with PCs on the network. One idea is to scrap the UI and develop a new one for a Windows target that uses TCP communications to pass commands to/from the cRIO. But if I'm particularly fond of the UI I have already, what would be the harm in just publishing the front panel to the network and accessing it via a browser?

Does anyone have any advice as to what some of the caveats/concerns would be in doing this (or perhaps there are no significant caveats to using the existing web publishing tool?)

Thanks!

[Ton Plomp]

+:

You don't need to write a client app and a lot of connection stuff, NI has done that.

-:

No tabs

No events (I think)

But I would go the web-server way :thumbup:

Ton

[viSci]

I have found that network shared variables also make it very easy to connect your PC GUI with your cRIO app. This route gives you tighter control over cpu and network bandwidth. Shared variables can also be customized to be any LV data type or custom control.

Mike Sachs

Intelligent Systems

[Neville D]

Joe,

I prefer just accessing the remote panel using VI Server & tabs work. The browser just adds another layer in-between, looks uglier, and sometimes with past versions of LV, special types of controls or indicators did not show up correctly on your browser (IMAQ Image display? Subpanels?).

I am not sure if you had subpanels on your VI if they would show up in the browser.

On the other hand, you need to write some code and install the LV runtime on each machine that you plan on accessing your application with.

The code is quite simple actually:

1 enable webserver on the remote target; allow access

2 Invoke Application property RemotePanel:Open Connection To Server

3 Supply the remote VI's name

and your ready to go.

You might also need to consider at what rate your panel indicators are updating and what sort of response you need.

In case performance isn't up to snuff with the browser approach or using remote panels, you will have to use shared variables or your own TCP based client-server application.

PS I am not sure that tabs DON'T work with the web browser approach.. its been a while since I went that route.

Neville.

[orko]

QUOTE(tcplomp @ Oct 17 2007, 09:28 PM)

-:No tabs

There is a tab control on the FP of the existing app... so this doesn't work correctly in LV8.2+?QUOTE(tcplomp @ Oct 17 2007, 09:28 PM)

No events (I think)

Hmm... there aren't any events in the existing app currently, but I was planning on bringing them in to the picture later...QUOTE(sachsm @ Oct 18 2007, 04:55 AM)

I have found that network shared variables also make it very easy to connect your PC GUI with your cRIO app. This route gives you tighter control over cpu and network bandwidth. Shared variables can also be customized to be any

LV

data type or custom control.

That is definitely something to consider. So basically build an app for the PC that sends values to the cRIO shared variables, kind of like a dummy front panel?

[Neville D]

QUOTE(orko @ Oct 18 2007, 08:48 AM)

Wait...so now there's four ways of doing this.

1) Straight up using the existing app and controlling it via web publishing

2) Designing an app that controls the cRIO VI via VI server

3) Designing an app that controls the cRIO VI via shared variables

4) Implementing a TCP server communication layer between the cRIO and client VIs.

So... the first one works well, if the FP is simple (no tabs/events), I believe I could do #2 without changing the existing cRIO VI either, and it requires just a little bit of configuration/setup to enable, #3 requires changes to the existing code to implement using shared variables in all the places I want to control, and #4 is...well, it is doable but I'm not seeing the benefits of it yet over the others in this application.

I have a question about using the VI server remote panels as you described. Looking through the RemotePanelMethods examples from NI, it looks like I could leave the existing cRIO VI alone, and implement a "VI server" daemon (almost exactly as they have on the RemotePanelMethods-Server.vi example, except it would have to loop continuously) on the cRIO. This daemon waits for remote connections and runs the cRIO main VI when it gets a client connected. The client would be seeing the front panel of the cRIO main VI at that point?

Looking through the cRIO code, it looks like there are simple indicators updating at 50Hz, but the graphs are at 1Hz update rate. That seems pretty slow to me...what would be considered too fast?

Thanks for the help! :thumbup:

The advantage of the remote panel method is that you don't need anything additional on the Server (remote system) side.. just enable the webserver on the cRIO, and allow users to connect to front panel and control it, thats it. These can be set programmatically in your cRIO code, or else access the remote target in your project and change its properties from there.

(Now I have never used to cRIO platform, but I am assuming it is similar to other NI LV-RT based platforms).

Then write the client-side code on a PC from where you want to access the remote panel, and you should see the remote panel exactly like the cRIO stuff was running on that PC. However, that VI must be running on the cRIO for you to be able to access it.

About update rates.. 50Hz seems pretty high, and you will probably miss updates in-between, but as a human, you are not going to be able to eyeball that much data anyway. So you should be OK.

The advantage of the other two methods is that you can enable buffering if you desire, plus the responsiveness of the application will be much higher.

For example if your cRIO is busy running something and you press a button on a remote panel or web browser, it might ignore that command until it gets round to servicing its lower level browser task. If using shared variables or TCP, the response can be built in to your application to any degree of sensitivity you desire.

Neville.

[orko]

Talking with the client, it looks like they are more comfortable with a remote application that is controlling the cRIO VI via TCP. There goes that idea (for now) until I get more time to test this out fully that is.

Thanks again for the help. I'm sure I'll be referring back to this thread in the future!