Applies To:
  • CitectSCADA 4.10

Citect version 4.10 provides more multithreading support over version 4.00. This extra multithreading support may cause problems with specialised protocol drivers. If you find that your driver worked OK with version 4.00 and does not startup with version 4.10 you may have to disable some of these features. 

Two new CITECT.INI options have been added in version 4.10 to allow you to control some of the multithreading in Citect. The option [kernel]Win32Threads=0 will disable most of the multithreading support. When you set this option to 0, most of Citect will run under a single Win32 thread. Various low level protocol services will still run under their own threads, however these threads should not effect your driver. You should avoid if possible disabling this feature as it will degrade the performance of Citect.

The second option [kernel]Win32Idle=0 controls the thread which monitor Citect during idle processing. This thread is the one which is most likely to cause your driver problems. This is as it may cause Citect to call your driver while Citect is processing a SendMessage(). Various functions in the Windows API will fail if called when processing a SendMessage(). See the Window API documentation for full details. This problem has been seen from calling the CoCreateInstance() function returning the error code RPC_E_CANTCALLOUT_ININPUTSYNCCALL (0X8001010D). If you get this error you should disable this feature. Try the Win32Idle=0 option first to solve the problem as it has as less degrading effect on Citect performance. When you set Win32Threads=0 it will also have the effect of setting Win32Idle=0.

This problem has also reported by special protocols using Windows Sockets (TCP/IP). If you are developing a driver you can verify this is the problem by calling the function InSendMessage() to see if you code is being called from a send message. If this is the case you should set the [kernel]Win32Idle=0 option to disable this effect.