FTViewSE inherent 3-4 second latency

I have recently completed an RSView32 to FTViewSE migration. The View32 application consistently provided sub-second response for any action on the displays. ViewSE is consistently lagging in screen updates by 3-4 seconds. In a system that is directly controlling a large machine this latency is unacceptable. The only suggested experimental work around has been to increase the screen refresh rates by decreasing the refresh time from the default 1 second setting to 250mS. I fail to see the logic in requesting a screen refresh 9-10 times more frequently in an application that already has a 3-4 second latency. Rockewell Support has recognized this issue and can only offer this as a possible solution. Has anyone else encountered this issue? If so, what was the solution?

Are you using the tag database or going direct to the PLC?
This thread might help: http://www.plctalk.net/qanda/showthread.php?t=95090

Tag Database was the only option via the Legacy DB conversion utility. This was a Paid for Service where a Rockwell FSE that came on site and executed the Migration.

Latency like that seems very odd.
What communication driver are you using?
What is your network like?
What is the PLC?

RSLinx E
Small dedicated unmanned switch.
SLC-5/04

same as with the View32 App. Nothing else changed.

Did you mean a SLC 5/05 on Ethernet?
The 5/04 is DH+ which does have other comm settings. You could still use RSLinx Classic to talk to the SLC, same as before.

HMI tags will add a delay of 2x the update rate. If your displays are set at 1 second update rate then HMI tags will actually see an update of 2 seconds.
Changing to direct reference tags will cut out 1 second in that case.

There is a conversion tool on the knowledgebase to change from HMI tags to Direct Reference tags.

The proc is a SLC5/04. E-net comm is facilitated via a ProSoft card. Same as with the View32 solution.

But if that Tag is alarmed, what then? Other posts indicate that the FT alarm server can't access direct ref Tags.

And it seems the Conversion tool is limited to FT-ME.

Direct reference tags are a quick and dirty shortcut in some cases. Lots of people seem to like them, but they have many more negatives than positives associated with them.

Are you using Linx Classic or Enterprise? If Enterprise, make a screen (there is a default one somewhere) to monitor the communications server.

It was my belief that FTViewSE came with and installed with RSLinx Enterprise. I wish I had the time and skills to perform Trouble Shooting steps like that. This is now a production machine, experimenting or monitoring in a live environment is not an option. Especially with a 3200 ton extrusion press... I need to setup a separate station to develop a fix (Whatever it may be...) in a mirrored environment. That is basically how we implemented the Migration off of View32. However ,the View32 machine is now dead. So, no options there.

Setting the displays to "cache after displaying" might improve performance after the screen is loaded the first time.

If you make any changes to the screens after it's been cached, it won't show up until the cache if flushed though (KB# 38216)

How is that going to help? The issue is a 3-4 second Tag read latency or. slow updates/reads. The display values are changing, they are just dog-slow.

Thanks for the input but it doesn't seem to fit.

38216 - Display client will not display changes made to the display or screen
Access Level: TechConnect
Date Created: 02/08/2007 03:36 PM
Last Updated: 01/14/2015 11:47 AM
Problem:
The Display client is not displaying any changes that are being made to the display or it only displays these changes once then needs to be shutdown and started again to view the changes.
Solution:
On the Display Settings of the display if the Cache After Displaying option is set to Yes, then once the display is loaded it gets cached in memory. If any changes are made to the display after that, the client will not reflect these changes unless the cache for that screen is removed from memory by either using the Flushcache command on the client or shutting down the client and starting it up again.

Three + second latency is just not normal, but it isn't something that we can just guess at, you are going to have to investigate some. How much traffic is there over Ethernet? How many tags are continuously on poll? What is the poll transaction time? These are things you can see looking at the canned diagnostics page. You don't have to play live, fire up Studio, create the display, and see what the behavior is locally.

This is a station License. All servers are locally installed on one machine the only E-net traffic generated is for the reads from the PLC and there are no more than 20-25 tags on any given display. Is the procedure for creating this canned diagnostic display in the user manual?(Yes, Ch15, this is going to take a while...) Support has acknowledged the issue as a legitimate problem. Ticket#4004984438 I am working on setting up a test/diagnostic environment now. Given the little I just read, I have some suspicions that I will be looking for.

Thanks

No, you can't use direct reference tags for alarms. But you don't need the speed on alarms; a 3 second delay in receiving an alarm should not be critical. I mean, that's what you have right now anyway.

You could try making the tag update rates faster, but you can hit your serial network limit pretty fast. Especially if using HMI tags.
Does the Prosoft module have a webpage and/or diagnostics for the serial network? Might be good to find out packets per second, data per second, bandwidth %, number of TCP/IP clients connected, etc.
Ethernet to serial converters are handy, but sometimes people forget that it is still an RS232 bottleneck.

Maybe there are new settings in your project that were not there in the RSV32 project:
Ex. more alarms, faster update rates, derived tags, data logging, etc. There are a bunch of background services like that which all have their own tag update rates.

But like rdrast says, you're going to have to investigate and I'd start with your network stats/diagnostics for both serial and Ethernet.

Patch

We had some issues arise with bad latency problems recently and it turned out the fix was to apply the latest FTV patches from Rockwell. Hope this helps, our issue popped up on the fly and drove me nuts for about a week.