Hi Dojo,
How is possible that a virtual element goes to timeout? There are any ways to investigate the root cause of this behavior? Could it be a driver problem? Note that virtual element has some element connections configured. Could it be related to elements connected?
Hi,
-The driver itself could be causing the problem if the QAction is generating the notify to generate a timeout. This can be seen with if this call is included: protocol.NotifyProtocol(249 /*NT_CHANGE_COMMUNICATION_STATE*/
-Is the Element Connections configured to include the element state?
This can be seen by opening the “Element Connections” module, expanding the parameters of the element, and when scrolling to the right there will be a column displayed “Include element state”:
If that checkbox is checked, then the element will have the same timeout state like the connected element.
Regards,
Hi, in the comment on Bruno’s answer there is written: “to update element state”. What is meant with this? Are parameters being set somewhere in the 65xxx parameter id range? Or is there some other Notify being executed? Just to be clear, this is also not about a DVE that is in timeout?
Hi Laurens,
When I wrote “to update element state” I meant “updating alarm severity of element”.
The highest parameter id is 4000, and highest QAction id is 7000, but it’s true that it has the x0000 parameter value range (x from 1 to 4) plus -1 value.
There isn’t any Notify execution.
This question is only about DVE timeout behavior which it shouldn’t appear.
Ok, so it’s a DVE that is in timeout?
I was assuming that it was a real element, as a virtual element is a real element that does not have ports (snmp, serial,…).
If it’s a DVE that is in timeout, then this is defined by the protocol.xml of the parent element. In there the overrideTimeoutDVE attribute defines if the DVE should have the same timeout state like the parent element (see help: https://docs.dataminer.services/develop/schemadoc/Protocol/Protocol.Type-overrideTimeoutDVE.html ) or the parent element executes a protocol.NotifyDataMiner(249 /*NT_CHANGE_COMMUNICATION_STATE*/ to individually change the timeout state per DVE
Ok Laurens,
I will check it.
Just curious. I have other case where a virtual element (not DVE) also has element connections with some SNMP elements. Could this element go to timeout if “INCLUDE ELEMENT STATE” is blank?
Thanks for your help.
Hi Daniel,
Could be that your virtual element is running a connector that is making use of call in a QAction (NotifyDataMiner 106) that raises a timeout alarm in a specific situation?
If the connector contains code like this, it could be the origin of the alarm.
Hi Bruno,
I’ve checked the driver but it has no NotifyDataMiner call on it and has no code that you share. To update element state, in QActions parameters are passed as “inputParameters” and after its values are checked. Depending if a parameter is different to normal value, a “SetParameter” is done. So I understand that there’s no way to create a timeout state with this code.
Note that same parameters passed are the triggers.
Hi Laurens,
I also checked your points. There’s no NotifyProtocol call on it. I can confirm that all Element Connections have “Include element state” checkboxes in blank. Maybe as I type on Bruno’s answer, is there something wrong in way to handle the parameters?