FactoryTalk memory tags vs PLC% bits

I am upgrading a legacy HMI that was originally in Control View, then upgraded to RSView.

There are a couple of dozen PLC bits being set by the HMI as status flags. This seems like it would be slower than simply using a memory tag in FactoryTalk, but when I converted some of them over there seemed to be a delay. Does anyone know what is going on?

I'm working with PLC5/20, FactoryTalk 5.1. This work is in preperation to convert to FactoryTalk 7.0 running on Win7 in the very near future. I've got a bunch of these to do, so any insight would be appriciated.

How much delay are we talking about ? What objects or functions of FactoryTalk are setting these Tags ?

FactoryTalk View doesn't really have 'scan classes' like RSView or PanelView did, outside the Update Rate for each Display or the Update Rate for a data log model.

I recall being told once that the HMI Tag Database itself is only evaluated once per second.

I have some process parameters that occassionally need to be adjusted. I'm using the flags to make the parameter entry fields visible only when they are needed. I'm toggling the tag using touch on valve icon, when the tag is "on" the feild becomes visible. I've got a small button on the parameter screen which sets the tag to 0 to hide the field again.

The delay is strange, it's been up to 20 seconds the first time I activate the feild, thereafter it's usually a second or less.

I didn't know that they project was using the PLC bits as flags until yesterday. I looked at the logic and the bits aren't used for anything else or even labeled. I think the reason I'm even questioning it is because it feels wrong to do the same thing two different ways on a single project.

Also, this may have something to do with FactoryTalk 5.2. We had similar delay issues at some feild locations when connected to the PLC using an Ethernet connection. We were able to solve the problem by going to DH+. I've set FT 7.0 up on a Win7 machine and didn't see the problem, maybe this will go away, too.