Michiel,

It's always good to start by understanding the expected behavior of an action when getting an exception.

I assume you are executing the following method from your automation script:

myElement.SetParameter(...);

where myElement is of type Element

This will try to set the value in a parameter with a specific value. In order to verify if this set was done correctly, DataMiner will check if that value is reflected in the corresponding read param.

When this could not be done after 50 retries with a 10s delay in between, the exception will be thrown.

Before we blame the check, we need to verify the use case: what are we trying to achieve with the set?

Imagine you want to configure an equipment:

1. Automation sets a param on the Element representing the equipment
2. This set will trigger a logical flow defined in the driver used by the Element to configure the Equipment
3. The equipment itself might even take some time to have everything applied and e.g. send an "DONE" event back to the element
4. This event might then in turn update the displayed values (the "read" params) with the new configuration values as they exist in the equipment.

So this means that, just like Jorge mentioned, the delay between the actual set and the update in the read param is caused by the logical flow in the driver. And this delay could be perfectly normal: it could just take a longer time to e.g. reconfigure the entire equipment. (Imagine a restart command)

Solution:

1. Disable the automatic check and create your own in the automation script for the items that apply.
   1. This will give you the freedom to define your own timeout / retry system based on the use-case.
2. Verify the logical flow of the driver
   1. does it make sense that it takes so long to update the read or is something wrong (an error, a design mistake ...)