Wait for front panel activity and remote panels

[MarkCG]

Hi all,

As you probably know event structures aren't supported in LV Real-Time. So if you want to take control of the VI in interactive mode or via a Remote you need to go back to the old "read the button" method... maybe you've had to use it if you've had to work with the "base" version of LV ...

The program I inherited actually has somewhere in the range of 50-80 front panel controls, grouped into clusters in a tab control (users want to be able to control stuff!!), and it polls about 20 control every second. I'm beginning to think that this might be a bit much for the pockey old compact FieldPoint-2120 it's running on . Occasionally front panel activity will "freeze" the cFP if it's under heavy load .

This of course is pretty much terrible.

So I'm thinking of using the "wait for front panel activity" to trigger the boolean reads. NI says this might be a good idea:

http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/viewing_fp_remote/

Block diagrams that achieve certain user interface effects by polling properties of a front panel control might experience decreases in performance when you control the VI from a remote computer. You can improve the performance of these VIs by using the Wait for Front Panel Activity function

I was kind of distraught when I learned I couldn't use event structures in LVRT. This definietely make me feel better. Has anyone used this technique with remote panels? Any caveats?

[PaulL]

LabVIEW RT does support event structures, at least in the newer versions of LabVIEW. (We use event structures in RT ourselves!)

Generally one doesn't have front panels with a deployed RT application. (We don't handle front panel events directly. The way we handle this is to run the View as a separate application on a desktop machine. The View handles front panel user events and then sends messages to the RT application. Each time the RT application receives a message it generates a user event that a controller loop, properly speaking, handles.)

[MarkCG]

Ahhhh, if only I could upgrade... That would make things easier. So the remote front panel, the thing where you create an .HTML file from the main /GUI VI and deploy that in addition to the compiled EXE to the target, and then you access the GUI / remote front panel through a web browser. I guess you mean it's generally not done ?

I can see there are the advantages of running a separate viewer application that uses messages to command the embedded / deployed application. Besides the fine-grained control you have over when and how data is transmitted, you can change the viewer UI without redeploying. What other advantages are there?

Edited December 9, 2011 by Sergeant Manners

[Aristos Queue]

Ahhhh, if only I could upgrade... That would make things easier.

According to everything I could find on ni.com, the event structure is supported on RT ever since LV 7.0. I would be surprised if you're still using LV 6.1, which was the only version where it could not deploy to RT. I used to maintain versions of LV on my home machine going back that far, but at this point, I only have as far back as 8.6, so I can't actually check.

[ned]

While the event structure is supported, events on front panel controls on RT are not: "Event structures on RT targets do not support events associated with user interface objects, such as VI panels or controls. For example, associating the Value Change event with a control does not work. RT targets support only user events." http://zone.ni.com/r...unsupportedets/ (LV2011 help) So upgrading isn't going to solve the poster's question.

Edit: I should have read more carefully before replying - missed that Paul was referring specifically to User Events, and it appears the poster may have misunderstood that as well.

[Aristos Queue]

Oh. Gotcha. Since the front panel doesn't even exist on an RT target, I didn't even stop to think that might be what the poster was looking for.

To do a full user interface for RT, you actually have to build a host VI, running on the host, that has communication back to the RT chasis. The remote panel from an RT box is just designed to do debugging and limited control, not be a substitute for a full application.

[PaulL]

I can see there are the advantages of running a separate viewer application that uses messages to command the embedded / deployed application. Besides the fine-grained control you have over when and how data is transmitted, you can change the viewer UI without redeploying. What other advantages are there?

The main point is to separate tasks into separate pieces of code, and in this case, into separate applications. (We actually have separate LabVIEW projects for each of the pieces.) As you pointed out, you can rebuild and redeploy one piece without touching the other(s). With that comes better maintainability (in particular, one doesn't break one thing while fixing another) but I think also better design (we think about what really belongs where). If you want to read more on this, you can search for topics on tight cohesion, loose coupling, encapsulation, open-closed principle, and especially Model-View-Controller (deals directly with this issue, and is super-important, but there are lots of subtleties here).

[MarkCG]

Hi all!

Yes ned thank you for clearing that up. I was pretty sure RT did not support events associated with "user interface objects, such as VI panels or controls" as it says in the 8.6 help or manual. When AQ said that they are supported in more recent versions, I was a bit confused as I hadn't seen anything about that. But I figured AQ knew something I didn't .

I'm definitely on board with writing code with loose coupling in tight cohesion... I modularize as much as possible, still have much to learn however.

I remember looking at some NI example architectures for remote machine control. That sounds like what Paul is talking about. Essentially you use TCP/IP to send little string messages from the desktop UI program /host to the message handler loop running on the RT target.

Good to know that the Remote panel is not meant for a full application. but it IS pretty nice not to have to write all the "glue" code to link the front panel code to the RT code. I know what to do now... Thanks everybody!

[ShaunR]

especially Model-View-Controller

You mean the "Muddled-Verbose-Confuser". Every website is being built on that model and every website built with it requires huge amounts of caching to make it barely usable ... that's why I wrote this.

[EricLarsen]

Essentially you use TCP/IP to send little string messages from the desktop UI program /host to the message handler loop running on the RT target.

You can use network shared variables to do the same thing. A little eaiser than TCP/IP strings. I usually a string variable called Command to send messages to the target, then a string variable called Status to send messages from the RT to the Host.

[JamesMc86]

Another technique for this (but only in 2010 onwards) is network streams. They suit the command model well although the disadvantage is they are 1:1 like TCP so can require an element of connection management.

(null)