Problem with slow execution on a cFP-2120

[Rodnebb]

I have an application that runs on a cFP-2120, using web interface for the user to interact with the program.

I have noticed that in order to get the web interface to get updated I have to use property nodes and write to the value property, see this article:

http://digital.ni.com/public.nsf/allkb/FC5024A5DD6344C886256C8C0054689B?OpenDocument

However, this seems to give me a serious performance hit, as described here:

http://forums.ni.com/ni/board/message?board.id=170&thread.id=153531&view=by_date_ascending&page=1

I have tested with this code, and with my LV 8.2 a loop that uses 277ms to complete when writing directly to a indicator will use 203159ms when using a property node.

So, I need to update several front panel objects using the value property, but can't afford the cpu time. Does anyone have a suggestion how to do this as efficiently as possible? The problem is apparantly that using the value property requires the front panel to be loaded - can I for instance avoid doing this once for each variable?

[Rodnebb]

By the way - this seems to be a real timesink - are there any others that I should consider?

[Wayne.C]

In the past I have always written directly to the indicator when using remote panels.  Your post seems to imply that method is not working on your target.  Is that correct?

[Rodnebb]

Yes, that is correct - at least most of the time 🙂

Seems like it works like this:

- Local variables and shift registers can be used to store data, but updating a local variable
will NOT update its front panel on web interface.
- Writing to property value will update front panel on web interface, but if web interface is not present
then you CANNOT read this value back into the program.

[Wayne.C]

My usual approach is to use no local variables or property nodes when building an RT Target vi for a cFP.  Since all my stuff is state machine based I use shift registers to pass info around inside the vi.  You could also use an action engine for this.  I have had no problem writing directly to the indicator when using remote panels. 

Starting to wonder if something else about your app is causing the problem.  As part of your benchmark, did you try deploying a cut down vi?  How big/complex is your target vi?

[Rodnebb]

I've changed the vi now so it only writes to value property when a value has changed. This has cut execution time in half, from 500ms to 250ms. I still think this is quite a lot...

To give you an indication of "size", the executeable is 1210kb with 2 dll's of 872 and 168kb.

I've not tried deploying a smaller (cut down?) version - what exactly do you mean?

With regards to writing to value instead of locals or directly - I've had problems with the values not updating - but not always - and the first link does suggest a bugfix. I'd like to know why wiring to value property is sometimes needed and sometimes not.

[Wayne.C]

By cut-down I meant a fairly simple target vi that just updates a front panel that is identical or similar to that of your actual vi.  The idea being to try and isolate what is causing the problem with updating the front panel.  Is the problem just trying to update the front panel or is something else in your application creating a lot of overhead and causing the problems with the front panel update.

[Rodnebb]

Well, I've tried some test vi's, which show that updating the front panel via value property takes a long time.

I'm not sure what else I should try - principally I'm just reading the front panel objects, do a couple of tests then write a bit of data to the front panel, at least when "idle" - and it's this "idle time" that is 500ms. When I'm doing something it can take 2-4s to finish one round.

[Wayne.C]

Did you try writing directly to the indicator in your test vi's?

[Rodnebb]

Yes, that's a lot faster, and we used to do that earlier.

However... then sometimes the web interface doesn't update at all... The whole point is to be able to read the web interface, so...

But, now I've changed the vi so that it only updates the web interface when a change has occurred. Still, the "idle" execution time is too high at 200-500ms, so I'm wondering if I have some other problems as well.