RSView32 VBA ver6.30.16


Thread Starter


I am using VBA code to write to memory tags in an rsview project. If I only run the vba code, no events, graphics or tag monitors referencing the tags I am writing to, the code will run fine. If I reference any of the tags in the rsview project the code can run for a while but will just stop all of a sudden when it tries to write to one of the memory tags. RSview tech support hasn't been much help. Any suggestions would help. Thanks

Cristian Gliga


I have developed few RSView32 projects in which I extensively used VBA but I never experienced the problem you described. Here are few suggestions:
1. Try to install the latest RSView32 service pack.
2. Make sure that your RAM is errors free (you can run some memory test program).
2. Check your code.
3. Try to log each step the program goes through to a file. This will help in debugging.

Hope this helps.

Cristian Gliga - Systems Integrator

Bruce A. Bancroft

Firstly, make sure you have error trapping in every method. If you have error trapping but are encountering VBA entering a "Not Responding" state without any apparent reason you are where we are at. We have extensive VBA code which is fired on a periodic basis. We have been able to reproduce the "Not Responding" state, have addressed it and have reduced the frequency by taking total control of periodic events. But still go "Not Responding" for reasons we cant figure out, there is probably some kind of deadlocking going on here. We are ripping all VBA code out of the project and running it in a separate VB exe and communicating to RSView by means other than the object model. Our conclusion is VBA is probably OK for one time button controlled actions but to be avoided for extensive processing. There are others who have come to the same conclusion. Good luck.

We have an application that uses VBA extensively as well. The VBA will periodically lock up when we receive an event on a tag that we are
monitoring for alarms. The event fires and we write a value to the RSView tag database to change the alarm description in RSView. The call
never comes back. We verified this by placing logging on the entry and exit of the event handler, as well as every other call, in the VBA.
We have it narrowed down to something the operator might be doing in RSView while the event fires in VBA?? The closest thing to our lockup right now is the Acknowledge call. We don't know if this is related. BTW, we had the same reaction from support personnel at Rockwell and version 6.30.17 didn't make any difference.

John Gunther

We have seen the same behavior, in a VB6 application that calls the RSView object model.

Have also verified that it "goes into the line to set the value of a memory tag, but does not come out" via writing to logfiles.

We have also seen lockups in calls to a method called scanOn (goes in, does not come out). scanon indirectly changes the tags' scanCount property. The tags in question are OPC mapped tags. When we removed this call from the inner loop, along with a companion call to QueryForTags that retrieved the list of OPC tags via a wildcard expression, the lockups appeared to stop.
(We stopped the test after running about 5 times longer than it normally took to lock up).

This is a general strategy that may work for some apps (and seems to be working for ours): "optimize" your application to minimize execution of code lines that change tag properties (and thereby minimize lockup frequency). For example, with the scanOn call it turned out that it didn't have to be done in the inner loop, so we were able to do it at startup instead which reduced (or maybe even eliminated?) lockups for our application.

Another thing that seems to help is always performing operations that modify the tags via the object model in exactly the same order each time (lockup rates appeared to decrease in some tests when we eliminate accessing the object model
via a second timer and restricted all access to go through a single timer).

Faster machines also reduced frequence of lockups (e.g. 400 MHz to 733 MHz cut lockup frequency by more than half).

One thing we have not tried but are considering and would like to know if anyone else has tried this: increasing the size of the Watcom SQL 4.0e cache that Rockwell's object model uses internally to make it's tag database persistant. Even though it is not supposed to hit against the database (RSView is supposed to have its own in-memory copy) there is a Rockwell Knowledgebase
article (number P6798) which describes that there are certain circumstances in which it has to hit against the underlying Watcom database to get the tag info it needs. P6798 gives instructions on how to increase the size of the Watcom cache to fix a problem that arises from such a situation (wildcard expressions used within RSView).

Has anyone tried increasing the cache size as per P6798? Did it eliminate the lockups?


John Gunther

We tried the cache size trick and it didn't help at all.

Rockwell says this might help reduce lockups (they have not admitted officially that there are such things yet):

1) Check tag status before each value setting operation. Don't set it unless it returns OK.

2) Use PendingValue (and a related routine that flushes out all of the pending values in a tags collection instead of setting the value of tags.
This involves really two changes:

a) Keep tag objects around in a collection rather than creating them each time you need them

b) Use PendingValue, "commit pending values" (can't recal the name of the "commit" routine) rather than just setting the value.

Has anyone had any luck with either of these strategies? (we have not had a chance to test them yet, and Rockwell doesn't say clearly that these will fix it, only that they strongly reccommend we try it, even though our output tags are all memory tags).

Rockwell Technote #A4990 provides more info on the PendingValue stuff.