Jump to content

Wait for front panel activity and remote panels


MarkCG

Recommended Posts

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 :wacko: .

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?

Link to comment

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 by Sergeant Manners
Link to comment

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.
Link to comment

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.

Link to comment

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.

Link to comment
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).

Link to comment

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 :lol:.

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!

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.