Siemens TI-545, internet, value toggle at random

* Indusoft version 6.1 SP5
* Windows 7 64-bit
* Siemens Simatic TI-545 w/CTI-100 ethernet module
* Indusoft driver: TI500 (version 1.09)

Indusoft is running on a PC which connects to a PLC, at another location, via internet. For the most part this works without problems. But then there is this:

If we remove the connection, and then bring it back - i.e. (un)plug a patch cable - then very briefly random values will toggle on the PC. This is especially unfortunate with alarms, which are 0 (no alarm) but toggle to 1 (alarm), and then back to 0 once the communication is properly established.

Furthemore this issue was discovered as it has occured "by itself" - as in nobody were removing any cables. Has happened more than once. The internet connection may be unstable?

So far the solution has been to add a delay to the alarms, but that only resolves the issue and not the cause of the problem.

We have tested with Indusoft version 7, but the problem was there still. We have also screened the PLC program, and the problem is almost certainly not here.

So anybody experienced anything similar? At the moment we guess that it may be a bug in the TI500 driver. As mentioned initially, the problem can be forced by cutting the connection and then bringing it back. And only at very first moment that the connection is active again, do the various values toggle. What gives? Help!
  • Running same setup on our TI system but have never had this problem. BUT, ours is not over the Internet.

    Mike
  • Okay, found a "solution"; we increased the timeout value in the driver setup. At the moment we raised the default 1000 ms to 20000 ms.

    As mentioned the in original post, we were able to reproduce this error by quickly removing the LAN/patch-cable and plug it back in. This will cause the driver to "tilt" and values will get random values until it finally "calms down". Not entirely sure what is happening, but it looks like there is some conflict between the driver itself causing an error and the driver sheets failing.
  • Unfortunately increasing the timeout didn't make the problem go away.

    It appears the Ti500 driver has a problem when an already established TCP/IP connection fails/is removed for a short amount of time - and upon being reconnected, somehow produces "ghost values", until new data are being read from the PLC.

    Wondering if there is something to be done on our end, or it is a bug in the software...


    Operating System: Windows NT Workstation v5.1, Build 2600, Service Pack 3
    (Windows 7 Professional, Service Pack 1)

    InduSoft Web Studio (Control Room) v6.1+SP5
    InduSoft Web Studio Path: C:\Program Files (x86)\InduSoft Web Studio v6.1
    Execution Mode: Engineering + Runtime
    Internal Database: 46 elements
    Application database (initial): 3979 elements
    Alarms (initial): 266 elements and 266 messages

    Driver: Ti500 version 1.9

    PLC's from Control Technology Inc. (having replaced old TI545 PLCs):
    2x CTI 2500-C200
    3x CTI 2500-C100


    Our setup is 5 PLC's each at their own location, and each with their own internet connection.

    Indusoft is running on a PC at one of the locations, and reading/writing data to all PLC's via the Ti500 v1.9 driver using TCP/IP. We have copied the Ti500 driver files to create new ones called Ti501, Ti502 and so forth.

    If there is a fault with internet connection, then Indusoft will register various alarms e.a. - that is to say that Indusoft/the driver will generate false data by itself. This is easily tested by unplugging the patch cable for 1-2 seconds and plug it back in again. Tags may briefly toggle in value, which in return gives us false alarms (amongst other things).

    We have had Indusoft running on another PC besides the original one - at a different location as well - and when we remove the connection at one of PCs, the errors will pop up at that location. So it does not appear to be a problem at the PLCs, as errors were not registered at the other PC running Indusoft.

    We have "fixed" the problem by increasing the Timeout values in the driver setup advanced section. From the default 1,000 ms to 20,000 ms - which have removed most occurences of this error. Sadly not all though, as there are still some problems from time to time.

    The solution may very well be to just keep increasing the Timeout values until we do no longer experience the problem - which would be when though? But the main problem - as we see it - is that the driver can generate values by itself. Which should never be the case obviously.