Update Equipment Process is Slow using a Custom Equipment Type Created in XML

Hello

We are using Equipment Type "TESYS" that have about 400 elements in XML file.

The XML file are Created by Excel script

For testing, we create 2 instances of this type. The system works however is too slowly. 

Bellow we can find an example for a variable item. 

<output name="VARIABLE.5" file="variable.dbf" filter="'{equipment.type}={type.name}'">
<calculator name="MyAddrcalc1">{equipment.param_list[StartReadAddress]} + 6</calculator>
<field name="NAME" key="true">{equipment.TAGPREFIX}_Segundo</field>
<field name="TYPE">UINT</field>
<field name="UNIT">{equipment.IODEVICE}</field>
<field name="COMMENT">{equipment.COMMENT} - Data do Equipamento - Segundo</field>
<field name="CLUSTER" key="true">{equipment.CLUSTER}</field>
<field name="EQUIP">{equipment.name}</field>
<field name="ADDR">{MyAddrcalc1}</field>
<field name="ITEM">Segundo</field>
<field name="TAGGENLINK" load="true">TESYS.VARIABLE.5</field>
<field name="LINKED">1</field>
<field name="EDITCODE">3939343</field>
</output>

There is something wrong in this output that can be the source of slowness?

  • Unfortunately, the TAGGENLINK fields are necessary for the update equipment process. It uses this field to know which records in the variable.dbf need to be updated and which have to be ignored.

    The mechanism that the Update Equipment tool uses to read/write the dbf files is the main source of the slowliness.
    Therefore I often use project specific third-party tools (written by a customer in Visual Studio) to rebuild the dbfs from scratch.
    This tool updates a project in 3 seconds where Citect would take over 40 minutes.

    The major drawback with such a custom tool is that you cannot modify anything by hand anymore in these dbfs, because these changes will be overwritten the next time you run the tool.
  • Hello Patrick

    I tested the XML created with two instances. Take a long time, more than 30min. Tel me if we use 164 instances (number of equipment s in plant), the update time is proportional!? :(
  • Hi Miguel,

    Yes, I think it will be proportional. You could do a smalll test with 4 instances if you want to know for sure.

    I know the developers are looking for ways to improve this in the future, but I have not seen a roadmap in a while yet.
    You could contact Support and report the issue.
  • Hi Patrick, I hope this request is not out of order, but would there be any chance of sharing such a tool? We have taken the approach that all of the configuration for a piece of equipment must be contained in the parameters or custom fields of the equipment, so the limitation of not being able to edit the result is not a problem for us. There are pros and cons to this approach when it comes to flexibility of course, however I have previously found that there are times when it is good to start again because the equipment update goes a bit wrong.
  • Hi Miguel,
    Someone at AVEVA already asked me the same question, but this tool is not my own software. It is built by a customer and I don't have the source code, nor do I have the permission to share it.

    I can only explain what it does and how it was designed:
    It was developed in Visual Studio VB.Net and it rebuilds dbf files from scratch using the dBaseIII format for which some documentation was found on the Internet. These are the steps the tool take to update project files:
    1. On startup, the tool displays a GUI that allow to select a Citect project from a list. This list is taken from Citect's MASTER.dbf
    2. The tool reads the project's equip.dbf and the XML-definitions in memory of all equipment types it can find in the included projects
    3. The tool deletes and rebuilds the following files (byte-by-byte) from scratch: variable.dbf, digalm.dbf, advalm.dbf
    4. Finally the tool calls Citect's internal Reindex.exe tool to recreate the dbf indexes, otherwise a user has to perform a 'file -> pack' from the Project Editor.