Communication established correctly in E3Studio, but fails at run time.

Question:

Why does the communication properly established via E3Studio fail at run time?

Solution:

A few reasons for communication failures at run time are:

1. The hardkey or softkey was not found in the machine, or then it has no license for the driver being used. You can check this at Driver Manager window (E3Admin–Server–Drivers).

You can also check this at the E3Admin’s licenses window, where the products programmed in the security device are listed. To access it, right-click the E3Admin–Licenses icon.

Another possible solution is to identify the device’s number and then contact Elipse Software to check which products are programmed in it.

2. The OPC driver requires some specific DCOM settings, which can cause communication failure at run time. To fix this, there is a sequence of tasks for setting up both firewall and DCOM, which can be seen at DCOM and Firewall Settings in Windows 7 for Elipse applications. 

If you can’t run the OPC server in a certain account (for example, SYSTEM), check KB-39425: OPC communication not working, even after DCOM has been set up.

3. There may be script and/or links errors between screen objects and the driver, which causes the false impression that there is no communication when there actually is. The solution in this case is to check all scripts generating links at run time, and also links and types of links made between screen objects and server objects.

4. The I/O tag’s N parameter could have been edited at run time, which increases the number of objects in the server. This causes communication failure if the number of tags exceeds the number in the license; to check this information, see the licenses window (as seen in item 1 in this article).

5. The driver’s EnableReadGrouping property optimizes driver communication, by grouping sequential address points (that is, by creating an internal block for reading). Some devices don’t support sending/receiving read blocks (either because they don’t read blocks, or because the block’s size is larger than what is suppported), and this causes the incorrect return of values or read errors.

6. The tag’s AdviseType property indicates if tag value must always be updated (0-AlwaysInAdvise), or if it only needs updating when being used in the application (1-AdviseWhenLinked), such as when it’s linked to a display on screen or being referred in a script. To optimize its performance, the default value is 1-AdviseWhenLinked, and this may make it look like there are communication issues in the application when there actually are none.

7. Many devices do not support more than one master driver connected simultaneously. Therefore, you must be careful when running the domain soon after any communication tests via Studio, because in this case there could be two different processes (Domain and Studio) accessing the same device. If this happens, the following window will pop up.

Print Friendly, PDF & Email

Este artigo foi útil? Was this helpful?

Classificação média - Average rating 0 / 5. Count: 0

Leave a Reply

Your email address will not be published.Required fields are marked *