"Front Panel Binding Mass Configuration" Issues

[xlAutomation]

Hello;

I have a project with around 200 data points that I need to bind to front panel variables. I previously have dropped the shared variable onto the block diagram and simply wired the shared variable node to the front panel icon. However, amoung the various problems I am having with 8.2 are extremely slow block diagram editing (it may take 5-10 seconds to move a single wire), and extremely slow run-time performance. To try to rectify this, I am trying to replace all of the shared variable nodes with front panel items directly bound to the shared variable.

Doing this binding item by item will take literally all day or more due to the responsiveness of the block diagram, so I would like to use the "Front Panel Binding Mass Configuration" utility. However, when I run it, I see nothing but the tab control, and not my front panel objects within the tab control.

It the only way to execute the binding going to be to move all of my front panel objects out of the tab control, and then return them when the binding is complete?

Thanks for the response!

Michael Hampson

[DuffmanSays]

Michael,

I am very sorry to hear about your difficulties when using LabVIEW 8.2. There is no reason why simple block diagram edits should take as long as you have mentioned. Was this code upgraded from a previous version? Does this behavior repeat when starting a new VI? Also, you seem to feel that this is related to your use of shared variables. Do you notice different behavior when these shared variables are not present? Please post back if you'd like to try to work on this aspect of your difficulties.

In regard to the front panel mass binding, unfortunately there is no way to select the controls within a tab control. As you mentioned, you would want to move those controls out of the tabs, create their bindings, and then move them back into the tab control. I understand that this is not really the ideal solution for this functionality; this fact is currently being addressed for a future release of LabVIEW. Thank you very much for your time, and I apologize again for this difficulty.

Mike D.
National Instruments
Applications Engineer

[xlAutomation]

Mike,

Thanks for the response. It would indeed be convenient to be able to run the mass configuration utility on objects in a tab, since moving everything out of a tab and back into it kills the front-to-back orientation of all of the controls, i.e. objects that were in the background might now be in front of objects, obscuring other objects, etc.

However, this is not the main problem I am having, as you have surmised.

The project is indeed upgraded from a previous LabVIEW 7.1 project utilizing DSC As part of the upgrade, I replaced all of the legacy DSC reads and writes to utilize shared variables, and removed a large chunk of code that handled the FieldPoint I/O (using the FP open/create tag/etc) to now utilize shared variables bound to I/O via the Fieldpoint OPC server. I also obviously am using the LabVIEW project approach now to support all of the changes.

Because of the way the application works (I can attach source code it it helps), I am using a lot of individual datasocket reads and writes to access tags that are bound to the FP OPC Server. I am just using the datasocket read and write VIs and am directly attaching the shared variable tag name to it, without DS open/close VIs. I have a hundred or more of these in the program. Prior to 8.2, I was using DSC reads and writes to perform the same functionality.

The slowdown problem I am experiencing is actually twofold: first, editing the block diagram has become unacceptably slow, and just moving a wire might take 5 seconds. You can imagine how frustrating this can be. The second slowdown that I am experiencing is that the performance of the running program is degraded, I think due to the datasocket reads and writes. For example,  the fastest I can get the main loop to update now is about .25 seconds, while before I was getting update times in the low tens of milliseconds. Because many PID loops and other controls in the program require fast update times, .25 seonds is not good. Additionally, it might take 30 seconds or more for the initial program pass to perform the first read/write to the tags and intialize everything in the program.

To answer your other questions:
1)  This behavior does not exhibit itself when creating a new vi. As a test, I created a blank vi in the same project and dropped 50 or so shared variables on the front panel and block diagram, with no noticeable slowdown.
2) I somehow assumed that the problem was related to the shared variables in the diagram. I don't know why this assumtion was reached. Perhaps 8.2 has a different method of error checking that is causing the problem... I really don't know.
3) As a final note, the slowdown problem is significantly improved when the VI is opened alone (without the project being open). However, this does not help much, as I need the ability to work with the shared variables.

I would appreciate any help you can give. I have not yet opened a service ticket for this, but can do this if you think it will help. I attached the program (with some proprietary information removed per my customer's request).

Thanks,
Michael Hampson
XL Automation, Inc.

[DuffmanSays]

Hi Michael,

Thank you very much for posting back about this strange behavior. I do think that this issue would be best addressed by opening a service request with an engineer here in Applications Engineering. However, I can provide some general insights into some of these concerns.

First of all, I believe you are correct that the application performance slowdown is a result of the DataSocket operations. As you mentioned you have several DataSocket operations all which must perform the open and close operation within the loop. This might be made more efficient by opening the connection once and then performing your reads and writes.

As far as the slowed editing and execution, we would want to determine if this is an upgrade issue. A few things you might try would be to copy the code to a new VI to see if get the same behavior. I might also suggest opening the code on another machine to see if the behavior follows the VI. Also, if there is anything specific that you can cut out that would eliminate the lag, we would want to try to locate that component. I am also quite surprised that the behavior changes when opening the VI outside of the project. Again, we would like to narrow down the code to the source of the problem. Aside from these suggestions, we would most likely want to dig a bit deeper into what might be going on which would best be done with a support request. I hope this information is useful for you. Please let me know if I can help further. Thanks,

Mike D.
National Instruments
Applications Engineer