Strange Speed Issue with FTV SE

arkansascontrols

Lifetime Supporting Member
Join Date
Jan 2008
Location
Arkansas
Posts
112
Ok, I'm stumped. Here's the scenario

I'm trying to isolate a performance issue with one particular Display that reads 14 Float tags. So in order to narrow this down I created a test display that does nothing except read the same tags and just pops the values into a listbox.

When I reboot my PC and load FactoryTalk View Studio, I can run the Single Test Display in test mode (No Client loaded) with RSLinx Active, and it takes about .2 seconds to read the 14 tags and put them in the listbox.

When I load the Client and launch the Test Display it takes about 28 seconds. No there is not a TYPO there! 200 ms before the client load, 28 Seconds after it loads.

Here's where it gets interesting. If I shut down the client and go back to Studio and run the display in test mode again, this time it takes about 28 seconds. If I reboot and run before loading the Client, I'm back to .2 secs.

BTW, this is not a network issue, I'm running PLC's in a emulator on the local machine during development. And it's not a RSLinx Issue, I can run a Test Client on the same tags and it updates the entire taggroup in around .2 sec before and after the Client Loads.

There are no tags loading and no processes running in the Client when the main display loads, so my Test Display isn't fighting for resources.

Any help would be appreciated.
 
What version is SE? What is the tag update rate on the screen? If your populating a listbox, what does your VBA code look like?
 
Listbox? Does that mean you have a VBA application running on the display? If so, I'd start by getting rid of that.

Are you using "Direct Tag Addressing"? Or are you using tag database tags?

Are you running ONLY RSLinx? or RSLinx AND RSLinx Enterprise?

Welcome to FTView SE... your problems have only just begun.
 
What version is SE? What is the tag update rate on the screen? If your populating a listbox, what does your VBA code look like?


V5.1.00. Tag Update Rate is default, 1 sec. There are no tags referenced on the screen and no controls with assigned tags. Only the list box, populated via VBA, I'm not updating the Tag values it's just a 'One Time' Read.

The VBA code is just a simple For-Next Loop, and it works extremely fast unless I've previously launched my Live Client Application. (This is just a test app to find a problem in the main Live Client Application)

Whatever is causing this is related to a component of my Live Application that loads when the Client Starts and doesn't unload when the Client terminates because it affects the Test App's ability to read tags at a reasonable rate.
 
Listbox? Does that mean you have a VBA application running on the display? If so, I'd start by getting rid of that.

Are you using "Direct Tag Addressing"? Or are you using tag database tags?

Are you running ONLY RSLinx? or RSLinx AND RSLinx Enterprise?

Welcome to FTView SE... your problems have only just begun.

RD,

Don't I know it, seems like the old RSV32 Issues flowed to RSV SE and RSV SE to FTV SE.

Yes I do have VBA running, but getting rid of it isn't an option, with the clients HMI specifications. However, the VBA code isn't the problem, I've begun to narrow this down a little bit through a Process of Elimination and some Test Applications. But to answer your questions, I've tried both methods of Tag Retrieval, Direct and Tag Database Tags, there is a speed difference, but it's somewhere on the order of about 8% tested on a series of 100 reads of a 14 tag Group, which frankly is negligible compared to the issues I'm seeing. I'm literally going from reading 1400 tags in 3 seconds to reading 3 tags in 3 seconds (exact same code), but only after my Main SE application has been loaded. The speed issue remains even after terminating the main app, until the machine has been rebooted.

It is definitely not VBA 'Code' related, I've confirmed this through a series of Tests in my test application. Although I haven't ruled out the possibility that it is something in SE's VBA 'Engine'. Like a massive Memory Leak or something.

As for Linx, I'm presently running only RSLinx (Not Lite), and I'm not running Enterprise, although I have tested with Only Enterprise, Only Classic and with both.
 
Tag group... Okay, are you building a local tag group in the VBA and refreshing it all at once? That shouldn't have very much delay unless ANY tag in the tag group is malformed.

What is your timeout value for the tag reads?

What is your trigger to start the read? For a test, rather then using any of the "OnOpen" or "OnInitialize" methods to populate the field, how about just using a button trigger, and try that after the display fully opens. The VBA code is all single threaded, and blocks often from client activity.
 
Tag group... Okay, are you building a local tag group in the VBA and refreshing it all at once? That shouldn't have very much delay unless ANY tag in the tag group is malformed.

What is your timeout value for the tag reads?

What is your trigger to start the read? For a test, rather then using any of the "OnOpen" or "OnInitialize" methods to populate the field, how about just using a button trigger, and try that after the display fully opens. The VBA code is all single threaded, and blocks often from client activity.

Timeout is currently 250ms, but I've tried varying the value with no resulting difference, trigger is a button in this test app for the very reason you suggested, I wanted to avoid any other conflicting variables.

Yeah, I checked for malformed tags as my first step, seen that one before. But not the case in this instance.

And your last statement hits the nail on the head. I'm pretty close to having this narrowed down, and have determined that my slow tag reads are only slow when the Client has its TagGroup with the same tags active. If I Stop the Datalog models, and terminate the Trend that reference those same tags, and unload the displays that reference those tags then my speed is blazing again.

I'll post my VBA 'Work Around' in a bit, for posterity sake.

Thanks for your help with this RD!
 
Yep... Sounds like you were getting thread blocked.
For the record, if I have to use data for multiple functions (Display and Datalog, Datalog and Alarm, Either and VBA), I create separate references in the tag dictionary.
 
Yep... Sounds like you were getting thread blocked.
For the record, if I have to use data for multiple functions (Display and Datalog, Datalog and Alarm, Either and VBA), I create separate references in the tag dictionary.

You know what's weird, is that I used to do that with RSView, and I never had this problem. But for some strange reason, with 5.1 even if I create different tags with the same address, or if I directly address the tags via PAR Files, VBA, DataLogs etc, SE Client seems to logically organize identical ref's into the same internal Tag Groups, so creating extra Tag Defs didn't help in this case. I suppose it was done to optimize SE for TagGroup updates.

BTW, what I ended up doing in my VBA code is;

Before I create an instance of a taggroup in VBA I
Unload all Child Displays that ref those tags
then issue an Application.ExecuteCommand "DATALOGOFF XX"
Then Create my taggroup, read my tag values then turn the datalog back on.

This works well for everything except my Trend ActiveX. The only way I found to Enable/Disable the trend (since there isn't an .Enable property) is to set the ChartMode = rstManual/rstAutomatic, which works as long as you running the same Display VBA code. Which doesn't work for me, since I'm running multiple displays in a Client with a Docked Main Display. And I'm sure you know Each display has its own instance of VBA so you can't share variables between VBA Instances (unless of course you read/write memory tags which is horribly slow. (BTW, I have a workaround for this if anyone is interested)

As a workaround to the Trend.Enable issue in separate instances of VBA, I've written a Class that retrieves the WindowHandle for the Trend Object and created a Public Method to enable and disable the Trend by Executing an EnableWindow API call to the WindowHandle. This way I can reference the Class in all my Displays, and when they have finished Reading their tags they can Execute a Class.EnableTrend which fetches the hWnd and turns the Main Display Trend Back on.

I KNOW, it's a KLUDGE, but it works, and it works fast.

Cheers

Eric
 

Similar Topics

Hello all, I am facing an issue with my Commander SK that I cannot solve on my own, I am struggling on it since several days :confused: The...
Replies
9
Views
997
Hi. I'm doing an upgrade of an old 1400e to a new panel view plus 7 standard using ftv studio v 12,which will be communicating to a slc 5/04 via...
Replies
15
Views
2,559
Can someone explain the jumper between the elements? Does it do anything? See attached jpeg.
Replies
4
Views
667
We have an OPC server getting data from a Compactlogix PLC. The PLC also communicates with a Panelview and a couple VFDs via Ethernet/IP...
Replies
3
Views
1,148
I have a small system controlled by a Siemens S7-1200 PLC. I created a totalizer function block (TIA v17), where I'm counting total revolutions...
Replies
16
Views
2,979
Back
Top Bottom