Windows NT can use the Task Manager and Performance Monitor to view CPU usage. Astute customers may observe that the Com6srvr process can consume 100% of the CPU. Originally when the VBScript Panel performance was slow, people started looking at the CPU usage and observed that the Com6svr used 100% of the CPU. They therefore complained that VBSCript performance was poor because the Com6srvr was stealing all CPU power. That was not a correct assumption.
The Com6srvr has a thread that continuously polls for data on the communications ports. The thread is active whenever the Com6srvr is active. When the computer is idle, you would normally expect to see the idle process consuming the majority of the CPU power. But when the Com6srvr is active, the idle process consumes a very small amount, while the Com6srvr consumes nearly 100%. Should another process come along that requires use of the CPU, the Com6srvr will relinquish control to the Operating System and thus the new process. The polling thread has a normal priority level and as such will share the CPU with whatever other tasks are using the CPU.
So while the CPU usage can be alarming, it is not really an issue.
The poor performance of the VBScript panels has been resolved with the Motion Planner 2.1 release. The VBScripting Engine was slow and there's not a lot we can do about that. The VBScript language does not support User Defined Types or data structures, which meant that each data element, such as Motor position of Axis 3 had to be polled individually. Also, updating a grid from within the VBScript environment was very slow. To overcome the poor performance concern and still maintain the VBScripting tool, we generated an Active X control.
The FSVariables.ocx (ActiveX control) was developed to show grids of data. The polling rate and display rate are programmable. The sample FastActiveXPanel.pnl uses the FSVariables OCX.