Hello,

thank you very much for the information.

We set the parameter to a smaller value (5 seconds) and the notifications are actually received after a smaller amount of time (even if, regardless of the value set, we observed a constant delay of 5 seconds , so the notifications are received after a time of 5 s + TopicRetrialDelay. Maybe it is related to the ServerStatusCheckPeriod parameter set to 5 seconds?).

Thanks and best regards.

Hello,

Thank you for your prompt reply.

In the document “Data Access Automation Interface Standard” Version 2.01, paragraph “4.1.4.8 ServerState”, the server states are described. In particular, for the OPC_STATUS_NOCONFIG, “The server is running but has no configuration information loaded and thus cannot function normally. Note this state implies that the server needs configuration information in order to function. Servers which do not require configuration information should not return this state.”

This is not actually an OPC specification and does not require that a client must mandatorily wait for the server to be in OPC_STATUS_RUNNING before subscribing tags, but we think it implicitly implies that trying to subscribe tags while server is in OPC_STATUS_NOCONFIG is pointless.

After some further testing, we noticed that the notifications after the server has switched to OPC_STATUS_RUNNING are actually received (even if no further write is performed through a different client) but about 60-70 seconds after the server has switched to running.

We are using the following overrides for the Opc DA configuration parameters related to timings:

All the remaining parameters are left to their default value.

Since, as we understood, it is not possible to prevent the tags subscriptions while the server state is OPC_STATUS_NOCONFIG, is there a way to shorten the delay between the status switch (i.e. server becomes ready to publish) and the reception of the notifications?

Thanks and best regards.

Hello,

we are evaluating OpcLabs.QuickOpc package (version 5.56.1073) for Visual Studio 2017 and we experienced some problems in using the EasyDAClient class to connect to an Opc server using DA protocol.

In case the Opc server is automatically started by the DCOM mechanism at the first client connection, it seems that the EasyDAClient does not wait for the server to be in OPC_STATUS_RUNNING before subscribing items: our server takes some time (1-2 seconds) to switch from the OPC_STATUS_NOCONFIG to the OPC_STATUS_RUNNING: in this in this time interval the server loads the tags configuration.

In this situation, the EasyDAClient behaves as follows:
- When the first call to SubscribeMultipleItems() is performed, the server is started and the connection is established.
- The notification related to the subscribed items are received (through the ItemChanged event) but the e.Succeeded flag is set to false and the ErrorMessageBrief field is set to 'This ItemID is not known'.
- The server finishes the initialization and switches to the OPC_STATUS_RUNNING state.
- No further notifications are received in the ItemChanged event until some tags are changed (by writing them using a different client). After the change of some (4-5) tags, all the missing notifications are received having the e. Succeeded set to true and the situation recovers.

We experienced the same situation in case the server is gracefully shutdown:
- After the server is shutdown, the notifications related to the subscribed items are received with an error (The RPC server is not available)
- The server is re-started by the DCOM mechanism at the first call to SubscribeMultipleItems().
- The notification related to the tags are received with the 'This ItemID is not known' error message
- No further notifications are received from the server even if some tags are written using a different client.
Is there some configuration parameter useful for preventing the tags subscriptions until the server has switched to OPC_STATUS_RUNNING state?

Thanks and best regards

Jacopo