Hello,
we have a control manager that runs multiple dpConnect() functions for several devices.
All devices are same type.
All dpConnect() are connecting to 3 dataPoints. One dp is timer from timedFunction, other two are dp changed by ModBus.
If there were some kind of Modbus connection problem, we should have had same issue on other dpConnect() functions since they connect same group of dp, in som case to same dp
In our case, one of those several dpConnect() functions lost connection (stopped working).
I was not aware of dpDisconnect for 2 days.
This control manager was not restarted prior to dpConnect() disconnect.
dpConnect was working fine prior to that issue.
dpDisconnect() was not sent from control manager - not that i know.
I have no logs from that period.
What can cause dpConnect() to disconnect?
Is there a way to be aware of dpDisconnect?
Is there a way to automatically reestablish dpConnect() if dpDisconnect happen for any reason, unless manager stop?
Best regards,
Vedad Ramovic
dpConnect lost connection
- leoknipp
- Posts:2928
- Joined: Tue Aug 24, 2010 7:28 pm
Re: dpConnect lost connection
An automatic dpDisconnect is made if the dp element (used at the connect) is changed/deleted.
It is also made if the conifg used at the connect is changed, e.g. when configuring an _alert_hdl config while a scipt is connected to this config.
If an automatic disconnect is made you get a log message, see the given example
WCCOAui (1), 2016.11.18 13:00:18.107, PARAM,WARNING, 107, Automatic disconnect of attributes due to config type change, DP: System1:Exa_Int_Discrete.:_alert_hdl, MAN: (SYS: 1 Event -num 0 CONN: 1)
An automatic reconnect for dpConnect is not possible without doing it on your own in the script.
With the following work around you could check if the work function was executed in the expected period of time.
Everytime when the work function is started a global "time" variable is set. In a loop a check is made when the variable was set for the last time. If a defined time range is exceeded you could start an action, e.g. check if the dpConnect is still valid by reading the attributes for the _connect config.
Best Regards
Leopold Knipp
Senior Support Specialist
It is also made if the conifg used at the connect is changed, e.g. when configuring an _alert_hdl config while a scipt is connected to this config.
If an automatic disconnect is made you get a log message, see the given example
WCCOAui (1), 2016.11.18 13:00:18.107, PARAM,WARNING, 107, Automatic disconnect of attributes due to config type change, DP: System1:Exa_Int_Discrete.:_alert_hdl, MAN: (SYS: 1 Event -num 0 CONN: 1)
An automatic reconnect for dpConnect is not possible without doing it on your own in the script.
With the following work around you could check if the work function was executed in the expected period of time.
Everytime when the work function is started a global "time" variable is set. In a loop a check is made when the variable was set for the last time. If a defined time range is exceeded you could start an action, e.g. check if the dpConnect is still valid by reading the attributes for the _connect config.
Best Regards
Leopold Knipp
Senior Support Specialist
- vedadramovic
- Posts:121
- Joined: Mon Apr 07, 2014 10:36 am
Re: dpConnect lost connection
Thank you very much Leopold for precise answers.
Best Regards,
Vedad Ramovic
Best Regards,
Vedad Ramovic
- Gertjan van Schijndel
- Posts:634
- Joined: Mon Aug 02, 2010 10:37 am
Re: dpConnect lost connection
There are also a few cases, where the dpConnect() function stops working temporary.
When only connected to remote datapoint(s) and the remote system is not available anymore. Continues to work when the connection with the remote system is reestablished.
When the callback function execution takes too much time to handle a burst of new values. Continues to work when all pending callbacks have been executed. Depending on how many pending runs are allowed and the duration of the callback function, it could take a while before it continues to work again.
When the callback function contains an endless loop. Since the callback function never ends, the callback function will never be called again.
In the last 2 cases you will get a log message like this:
WCCOAui (1), 2017.07.24 00:00:00.000, CTRL,SEVERE, 114, Values were discarded, function has 200 pending runs -> DISCARDING!
When only connected to remote datapoint(s) and the remote system is not available anymore. Continues to work when the connection with the remote system is reestablished.
When the callback function execution takes too much time to handle a burst of new values. Continues to work when all pending callbacks have been executed. Depending on how many pending runs are allowed and the duration of the callback function, it could take a while before it continues to work again.
When the callback function contains an endless loop. Since the callback function never ends, the callback function will never be called again.
In the last 2 cases you will get a log message like this:
WCCOAui (1), 2017.07.24 00:00:00.000, CTRL,SEVERE, 114, Values were discarded, function has 200 pending runs -> DISCARDING!